INF: Modo Ignorar (emergência) e DUMP TRANSACTION WITH NO_LOG

Traduções deste artigo Traduções deste artigo
ID do artigo: 165918 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Sumário

Em casos raros, um banco de dados pode estar marcado SUSPECT devido a falha de recuperação no momento da inicialização. Normalmente, isso impede que qualquer pessoa acesse os dados. No entanto, é possível definir o status de um banco de dados suspeito para "Ignorar modo" (também chamado de "modo de emergência") e SELECT manualmente ou usar o programa de cópia em massa (BCP) para copiar os dados. Enquanto você não pode fazer as modificações de dados regular em ignoram modo, é possível executar DUMP TRANSACTION WITH NO_LOG. Observe que fazer esta operação Ignorar modo não é suportada e é uma operação potencialmente perigoso.

Por motivos semelhantes, se a recuperação de inicialização estiver demorando muito tempo, você deve não anulá-lo, definir o banco de dados no modo Ignorar e siga DUMP TRANSACTION WITH NO_LOG.

Mais Informações

Todas as ações tomadas por DUMP TRANSACTION geralmente são registradas, portanto, é recuperável e abortable. No entanto, espaço de log é consumido pelo próprio comando DUMP. Se o log de transações for tão completo que existe espaço suficiente para fazer uma TRANSACTION DUMP conectado, a opção WITH NO_LOG pode truncar o log de transações com nenhum log.

DUMP TRANSACTION WITH NO_LOG é relativamente seguro em condições normais. O servidor leva medidas para garantir que a recuperação terá êxito mesmo se o servidor falhar durante esta operação.

Em casos raros recuperação automática (também chamada de recuperação de inicialização) pode falhar, a marcação de um banco de dados SUSPECT. Recuperação de falha para uma razão específica. É muito importante observar a mensagem de log de erros que provocou inicialmente recuperação falha, porque ele pode ajudar a diagnosticar a causa.

"Recuperação" é o processo de tornar o banco de dados consistentes por refazer ou desfazer todas as transações que foram iniciadas depois ou não confirmados no momento do último ponto de verificação. Esse processo depende da natureza gravação-ahead do log de transações (todas as páginas modificadas são gravadas no log antes de serem gravadas para o banco de dados). Recuperação consiste na leitura de cada registro de log, comparando o carimbo de hora para o carimbo de hora da correspondente banco de dados de página e ou desfazer a alteração (no caso de uma transação não confirmada) ou refazer a alteração (no caso de uma transação confirmada). Depois de observar a mensagem de log de erros que está causando a recuperação de falha, tente definir o status do banco de dados NORMAL e reinicie o SQL Server para ver se a recuperação tiver êxito na segunda vez. Você pode alterar o status do banco de dados por meio do procedimento armazenado sp_resetstatus. Isso é um procedimento armazenado complementar que você pode instalar a partir o script Instsupl.sql na pasta Mssql\Install. Para obter mais informações, consulte "Reconfigurando o status de suspeito" na documentação on-line.

Se a recuperação ainda falhar, observe a mensagem de erro e entre em contato com seu provedor de suporte primário. Você também deve verificar a disponibilidade de seu último backup bom banco de dados, porque ele pode ser necessário. No entanto, grande parte os dados no seu banco de dados com freqüência ainda está disponível, embora inconsistente transacional (e fisicamente). Você pode acessar esses dados definindo o status de banco de dados para ignorar ou modo de emergência. Isso é feito por configuração sysdatabases.status-32768 para um banco de dados SQL 6.5 e 32768 para um banco de dados SQL 7.0, depois de ligar o "Permitir atualizações". Por exemplo, use o seguinte comando para um banco de dados SQL 6.5:
   UPDATE SYSDATABASES SET STATUS=-32768 WHERE NAME='DBNAME'
				

Depois de fazer isso, você pode inserir o banco de dados e SELECT os dados ou use BCP para obtê-lo. Você pode encontrar erros ao fazer isso, mas na maioria dos casos muita os dados pode ser recuperada.

Propriedades

ID do artigo: 165918 - Última revisão: terça-feira, 22 de fevereiro de 2005 - Revisão: 3.1
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Palavras-chave: 
kbmt kbinfo kbusage KB165918 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 165918
Aviso de Isenção de Responsabilidade sobre Conteúdo do KB Aposentado
Este artigo trata de produtos para os quais a Microsoft não mais oferece suporte. Por esta razão, este artigo é oferecido "como está" e não será mais atualizado.

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com