MSSQLSERVER_3414

Aplica-se a: SQL Server

Details

Explanation

A base de dados especificada foi recuperada, mas não arrancou, porque ocorreram erros durante a recuperação. Este erro colocou a base de dados no estado SUSPEITO. O grupo de ficheiros principal, e possivelmente outros grupos de ficheiros, são suspeitos e podem estar danificados. A base de dados não pode ser recuperada durante o arranque do SQL Server e, por isso, está indisponível. É necessária uma ação do utilizador para resolver o problema. Verá o estado SUSPEITO tanto no SQL Server Management Studio (ao lado do ícone da base de dados) como quando olhar para a coluna sys.databases.state_desc. Qualquer tentativa de usar uma base de dados neste estado resultará no seguinte erro:

Msg 926, Level 14, State 1, Line 1 
Database 'mydb' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information

Note que quando este erro ocorre no tempdb, a instância do SQL Server desliga-se.

Motivo

Este erro pode ser causado por uma condição transitória que existiu no sistema durante uma dada tentativa de iniciar a instância do servidor ou de recuperar uma base de dados. Este erro também pode ser causado por uma falha permanente que ocorre sempre que tenta iniciar a base de dados. A causa da falha de recuperação é normalmente encontrada em erro(s) que precedem o Erro 3414 no ERRORLOG ou Registo de Eventos. O erro anterior no ficheiro de registo contém o mesmo valor spid<n> . Por exemplo, a falha de recuperação seguinte deve-se a um erro de soma de verificação ao tentar ler um bloco de log. Note que spid15s está presente em todas as linhas:

2020-03-31 17:33:13.00 spid15s     Error: 824, Severity: 24, State: 4.  
2020-03-31 17:33:13.00 spid15s     SQL Server detected a logical consistency-based I/O error: (bad checksum). It occurred during a read of page (0:-1) in database ID 13 at offset 0x0000000000b800 in file 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\mydb_log.LDF'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.   
2020-03-31 17:33:13.16 spid15s     Error: 3414, Severity: 21, State: 1.  
2020-03-31 17:33:13.16 spid15s     An error occurred during recovery, preventing the database 'mydb' (database ID 13) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support

Existe uma grande variedade de erros que podem causar falhas na recuperação da base de dados. Embora deva avaliar cada erro caso a caso, a resolução para uma falha na recuperação da base de dados é tipicamente a mesma descrita na secção de Ação do Utilizador abaixo.

Ação do usuário

Para informações sobre a causa desta ocorrência do erro 3414, consulte o Registo de Eventos do Windows ou ERRORLOG para um erro anterior que indique a falha específica. A ação adequada do utilizador depende de a informação no Registo de Eventos do Windows indicar que o erro do SQL Server foi causado por uma condição transitória ou por uma falha permanente. A mensagem de erro indica para "diagnosticar erros de recuperação e corrigi-los, ou restaurar a partir de um backup conhecido como bom". Assim, pode tentar corrigir o erro que encontrar para permitir a conclusão da recuperação (ver Erros corrigíveis e transações diferidas).

Se os erros não puderem ser corrigidos, a primeira e melhor opção para resolver este problema é restaurar a partir de um bom backup. No entanto, se não conseguir recuperar a partir de um backup, tem duas opções adicionais, que não garantem a recuperação total dos dados: usar reparação de emergência com DBCC CHECKDB ou tentar copiar o máximo possível de dados para outra base de dados.

1. Restaurar a partir do último bom backup de base de dados conhecido
2. Utilize o método de reparação de emergência fornecido pelo DBCC CHECKDB
3. Tente copiar o máximo possível de dados para outra base de dados.

O primeiro método para restaurar uma boa cópia de segurança de base de dados é a melhor escolha para trazer uma base de dados a um estado consistente conhecido.

A segunda melhor opção, se não houver backup disponível, é disponibilizar a base de dados online e acessível. No entanto, deve perceber que a consistência transacional não pode ser garantida, uma vez que a recuperação falhou. Não há forma de saber que transações deveriam ter sido revertidas ou avançadas, mas não foram permitidas devido à falha da recuperação. Os passos para avançar com a reparação de emergência estão descritos na secção intitulada Resolver Erros de Base de Dados em Modo de Emergência na documentação DBCC CHECKDB.

Se a reparação de emergência não funcionar e quiser tentar recuperar alguns dados para outra base de dados, a forma de aceder à base de dados é colocando-a em modo de emergência através do ALTER DATABASE<comando dbname>SET EMERGENCY. Depois podes tentar copiar dados das tabelas.

Erros corrigíveis e transações diferidas

Nem todos os erros encontrados durante a recuperação da base de dados resultarão numa falha de recuperação e numa base de dados suspeita:

Erros ao abrir a base de dados e/ou os ficheiros de registo de transações pela primeira vez ocorrem antes da recuperação. Exemplos desses erros são 17204 e 17207. Uma vez corrigidos estes erros, a recuperação pode ser autorizada a prosseguir (mas não é garantida a sua conclusão caso ocorram outros erros de recuperação). Erros como 17204 e 17207 não resultam numa base de dados SUSPECT. Na verdade, o estado da base de dados é RECOVERY_PENDING quando estes problemas ocorrem.

O SQL Server permite que a recuperação seja concluída mesmo quando ocorre um erro ao nível da página e mantém a consistência transacional. Este processo reduziu o número de cenários que resultam numa base de dados SUSPECT. Este conceito é referido como transações diferidas.

Se o erro encontrado durante a recuperação indicar um problema numa página de base de dados, por exemplo como um erro de soma de verificação ou o Msg 824, a recuperação pode ser permitida concluir com erros pendentes. No caso de uma transação não ser comprometida, um erro numa página pode resultar numa transação diferida , permitindo a conclusão da recuperação.

As seguintes entradas ERRORLOG mostram um exemplo de erro Msg 824 encontrado durante a recuperação, mas a recuperação foi permitida concluir com uma transação diferida. Note a ausência do Erro 3414 nesta situação e a mensagem de que a recuperação foi concluída para a base de dados:

2010-03-31 19:17:18.45 spid7s      SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xb2c87a0a; actual: 0xb6c0a5e2). It occurred during a read of page (1:153) in database ID 13 at offset 0x00000000132000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\mydb.mdf'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.   
2010-03-31 19:17:18.45 spid7s      Error: 3314, Severity: 21, State: 1.   
2010-03-31 19:17:18.45 spid7s      During undoing of a logged operation in database 'mydb', an error occurred at log record ID (25:100:19). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.
2010-03-31 19:17:18.45 spid7s      Errors occurred during recovery while rolling back a transaction. The transaction was deferred. Restore the bad page or file, and re-run recovery.   
2010-03-31 19:17:18.45 spid7s      Recovery completed for database mydb (database ID 13) in 2 second(s) (analysis 204 ms, redo 25 ms, undo 1832 ms.) This is an informational message only. No user action is required.   

Se uma transação comprometida for encaminhada, a página pode ser marcada como inacessível (quaisquer tentativas futuras de aceder à página resultam no Msg 829) e a recuperação pode ser concluída. Nesta situação, o erro deve ser corrigido restaurando a página a partir de uma cópia de segurança ou desalocando a página usando DBCC CHECKDB com reparação.

Consulte também

ALTER DATABASE (Transact-SQL)
DBCC CHECKDB (Transact-SQL)
Restaurações completas de banco de dados (modelo de recuperação simples)
Transações Diferidas
MSSQLSERVER_824
sys.databases (Transact-SQL)