Colaboração : Cisco ICM Logger

Database has been Marked as Suspect

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento descreve porque o Microsoft SQL server marca um base de dados como o suspeito quando o server é incapaz de alcançar o base de dados, e fornece soluções a este problema.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

  • Versões 6.5 e 7.0 do Microsoft SQL server

  • Utilitários de consulta do Microsoft SQL server (ISQL_w para a versão 6.5, ou analisador de consulta para a versão 7.0)

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

  • Versão 6.5 ou 7.0 running do Microsoft SQL server de Cisco Intelligent Contact Management (ICM)

  • Todas as plataformas de hardware que executam os produtos ICM de Cisco com Microsoft SQL server instalados

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Problema

O Microsoft SQL server marca um base de dados porque suspeito se é incapaz de alcançar esse base de dados. Isto significa que o Microsoft SQL server ajustou um dos bit no campo de estado na tabela de bases de dados de sistema. Quando o base de dados foi suspeito marcado, você deve restaurar o estado.

Solução 1

Refira a base de conhecimento microsoft para obter informações sobre de como restaurar o estado suspeito. Tente o sp_resetstatus suplementar do procedimento armazenado restaurar o estado de um base de dados suspeito. Se você já não fez assim, execute o script instsupl.sql a fim criar este procedimento. Este script reside no Mssql \ instala o diretório.

Nota: Para obter mais informações sobre do sp_resetstatus, refira “restaurando o assunto do estado suspeito” nos livros do Microsoft SQL server em linha.

Primeira opção

Uma maneira de resolver este problema é executar o sp_resetstatus no base de dados mestre para o base de dados suspeito. Conclua estes passos:

  1. Clique o começo > o grupo de programas do servidor SQL.

  2. Selecione o ISQL_w, se você usa a versão 6.5 do servidor SQL. Alternativamente, analisador de consulta seleto, se você usa a versão 7.0 do servidor SQL.

  3. Conecte ao registador.

  4. No indicador da pergunta, escreva e execute:

    • Use o mestre

    • <db_name> do sp_resetstatus

  5. Retire o ISQL_w ou o analisador de consulta.

  6. Clique o começo > o grupo de programas do servidor SQL.

  7. Pare e reinicie serviços relacionados do Microsoft SQL server.

  8. Verifique se o base de dados está disponível.

Segunda opção

Se a primeira solução não resolve seu problema, você deve restaurar o bit manualmente no campo de estado. Conclua estes passos:

  1. Clique o começo > o grupo de programas do servidor SQL.

  2. Selecione o ISQL_w, para a versão 6.5 do Microsoft SQL server ou o analisador de consulta para a versão 7.0 do servidor SQL.

  3. Conecte ao registador.

  4. No indicador da pergunta, escreva e execute:

    • o sp_configure “permite atualizações”, 1

    • reconfigure com ultrapassagem

    • atualize o estado = o ^ ajustados sysdatabases 256 do estado onde o "" do name=

    • o sp_configure “permite atualizações”, 0

    • reconfigure com ultrapassagem

  5. Retire o ISQL_w ou o analisador de consulta.

O base de dados deve agora reagir do modo de recuperação com o Microsoft SQL server. Se você interrompe este processo, o base de dados torna-se marcado como o suspeito outra vez. Você deve esperar até que o processo esteja completo antes que você sincronize registadores com ICMDBA (o ICRDBA velho). Se você continua a experimentar o problema, deixe cair e crie o base de dados outra vez.

Nota: Esta solução trabalha bem com versão 7.0 do Microsoft SQL server. Contudo, esta solução não trabalha sempre com versão 6.5 do servidor SQL.

Solução 2

Siga estas etapas para resolver o problema:

  1. Suprima manualmente dos CDR usando o procedimento no CallManager da Cisco: Manualmente suprimindo dos registros dos destalhes da chamada (CDR) sem a ferramenta de relatório administrativo (ART).

  2. Vão ao SQL enterprise manager, as ferramentas seletas > o analisador de consulta do servidor SQL.

    Nota: Certifique-se que você está executando o analisador de consulta do servidor de base de dados direito.

  3. Do indicador do analisador de consulta, vá ao indicador principal do analisador de consulta SQL e selecione o arquivo >Open.

  4. Abra C:\Program Files\Cisco\Bin\CDR.sql e selecione a pergunta > executam para executar a pergunta. Você pode igualmente clicar a seta verde na barra de ferramentas ou na imprensa F5 para executar a pergunta.

    Isto cria o base de dados de CDR.

  5. Vá ao SQL enterprise manager e selecione o Microsoft SQL servers > o grupo > o local > os bases de dados > o CDR > os usuários de servidor SQL. Então clicar com o botão direito e selecione o usuário novo do base de dados.

  6. Do menu de destruição do nome do início de uma sessão, selecione o CiscoCCMCDR (somente se CiscoCCMCDR não já lá) e certifique-se de que o público e o db_owner estão verificados.

  7. Vá ao Iniciar > Programas > Microsoft SQL Server > Enterprise Manager > ao EDITOR > aos bases de dados. Clicar com o botão direito em CDR > todas as tarefas > destacam o base de dados e clicam a APROVAÇÃO.

  8. Vá ao Iniciar > Programas > Microsoft SQL Server > Enterprise Manager > ao EDITOR. Clicar com o botão direito em bases de dados > todas as tarefas > base de dados do anexo > servidor SQL de C:\Program Files\Microsoft \ MSSQL \ servidor SQL de C:\Program Files\Microsoft do == do log <>Transaction dos dados \ CDR.mdf \ MSSQL \ EDITOR \ administrador do == do proprietário do base de dados <> dos dados \ CDR_log.mdf.

  9. Reiniciar o servidor.


Informações Relacionadas


Document ID: 26780