INF: Modo ignorar (emergência) e informações de estado TRANSACTION com NO_LOG

Traduções de Artigos Traduções de Artigos
Artigo: 165918 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Sumário

Esporádicas situações, uma base de dados pode ser marcado SUSPEITA devido a falha de recuperação no momento do arranque. Normalmente, esta situação impede anybody aceder aos dados. No entanto, é possível definir o estado de uma base de dados SUSPEITO "modo ignorar" (também denominado "modo de emergência") e SELECT manualmente ou utilizar o programa de cópia em massa (BCP) para copiar os dados. Enquanto não pode efectuar quaisquer modificações de dados normal no modo de ignorar, é possível executar copiar TRANSACTION WITH NO_LOG. Nota que efectuar esta operação modo ignorar não é suportada e é uma operação potencialmente perigosa.

Por motivos semelhantes, se recuperação de arranque estiver a demorar muito tempo, deve não abortar-, definir a base de dados no modo ignorar e, em seguida, fazer copiar TRANSACTION WITH NO_LOG.

Mais Informação

Todas as acções executadas pelo copiar TRANSACTION normalmente são registadas, por isso é recuperável e abortable. No entanto, o espaço de registo consumido pelo próprio comando DUMP. Se assim completo que existe espaço suficiente para efectuar uma TRANSACTION registados copiar o registo de transacções, a opção WITH NO_LOG pode truncar o registo de transacções com nenhum registo.

Copiar TRANSACTION WITH NO_LOG é relativamente seguro em condições normais. O servidor demorar medidas para assegurar que a recuperação terá êxito mesmo se o servidor falha durante esta operação.

Em circunstâncias especiais a recuperação automática (também denominada recuperação de arranque) poderão falhar, marcar uma base de dados SUSPEITA. Recuperação falha por um motivo específico. É muito importante ter em conta a mensagem errorlog inicialmente causado recuperação falhar, uma vez que poderá ser útil para diagnosticar a causa.

"Recuperação" é o processo de tornar a base de dados consistente Refazer ou anular todas as transacções que foram iniciadas após ou não consolidados no momento do último ponto de verificação. Este processo depende da natureza escrita antecipada do registo de transacções (todas as páginas modificadas são escritas no registo antes de serem escritos na base de dados). Recuperação consiste na leitura de cada registo, comparar a hora a hora da página de base de dados correspondente e anular a alteração (no caso de uma transacção não consolidada) ou refazer a alteração (no caso de uma transacção consolidada). Depois de anotar a mensagem errorlog que está a causar recuperação falhar, tente definir o estado da base de dados até NORMAL e reinicie o SQL Server para ver se a recuperação com êxito pela segunda vez. Pode alterar o estado da base de dados através do procedimento sp_resetstatus armazenados. Este é um procedimento armazenado suplementar que pode instalar a partir o script Instsupl.sql no directório Mssql\Install. Para mais informações, consulte "Repor o estado de sendo suspeito" na documentação online do.

Se a recuperação continuar a falhar, anote a mensagem de erro e contacte o fornecedor de suporte principal. Também deve verificar a disponibilidade da última cópia de bom da base de dados segurança, uma vez que pode ser necessário. No entanto, apenas os dados na base de dados frequentemente ainda está disponível, albeit forma transaccional (e fisicamente) inconsistente. Pode aceder a estes dados, definindo o estado de base de dados para ignorar ou modo de emergência. Isto é feito através da definição sysdatabases.status-32768 para uma base de dados SQL 6.5 e 32768 para uma base de dados do SQL 7.0, depois de activar a "Permitir actualizações". Por exemplo, utilize o seguinte comando para uma base de dados SQL 6.5:
   UPDATE SYSDATABASES SET STATUS=-32768 WHERE NAME='DBNAME'
				

Depois de efectuar esta operação, pode introduzir a base de dados e SELECT os dados ou utilizar BCP para obter. Pode encontrar erros ao fazê-lo, mas na maioria dos casos apenas os dados podem ser obtida.

Propriedades

Artigo: 165918 - Última revisão: 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 revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática? erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 165918
Exclusão de Responsabilidade para Conteúdo sem Suporte na KB
Este artigo foi escrito sobre produtos para os quais a Microsoft já não fornece suporte. Por conseguinte, este artigo é oferecido "tal como está" e deixará de ser actualizado.

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