Transações adiadas (SQL Server)

No SQL Server Enterprise, uma transação corrompida pode ser adiada se os dados exigidos pela reversão (desfazer) estiverem offline durante a inicialização do banco de dados. Uma transação adiada é uma transação que não é confirmada quando a fase de roll forward é concluída e que encontrou um erro que impede que ela seja revertida. Como a transação não pode ser revertida, ela é adiada.

Geralmente, uma transação adiada ocorre porque, enquanto o banco de dados estava sendo revertido, um erro de E/S impedia a leitura de uma página que era necessária para a transação. No entanto, um erro no nível do arquivo também pode causar transações adiadas. Uma transação adiada também pode ocorrer quando uma sequência de restauração parcial é interrompida em um ponto em que a reversão da transação é necessária e uma transação requer dados offline.

As transações de usuário que estão revertendo e atingem um erro de E/S fazem com que todo o banco de dados fique offline. Quando o banco de dados é colocado online novamente, o refazer requisita todos os bloqueios que ele tinha e tenta reverter todas as transações não confirmadas. Todos os dados modificados por uma transação permanecem devidamente bloqueados até que a transação possa reverter. As transações que não podem ser revertidas desistirão de seus bloqueios quando a corrupção for corrigida e o banco de dados reiniciado ou, após uma restauração online, quando as transações adiadas forem resolvidas enquanto o banco de dados permanecer online. Até esse ponto, uma transação adiada pode conter bloqueios que impedem determinadas operações no banco de dados como um todo. Por exemplo, se uma transação adiada contiver uma instrução CREATE TABLE, nenhum usuário poderá criar uma tabela até que a transação adiada seja resolvida.

A transação adiada também pode ocorrer porque uma restauração por etapas recupera um banco de dados para um ponto em que uma ou mais transações ativas estão afetando um grupo de arquivos que ainda não foi restaurado e está offline. Como as transações não podem ser revertidas, elas são adiadas.

A tabela a seguir lista as ações que fazem com que um banco de dados execute a recuperação e o resultado se ocorrer um problema de E/S.

Movendo uma transação para fora do estado ADIADO

Para mover a transação para fora do estado adiado, o banco de dados deve começar de forma limpa sem erros de E/S. Se houver transações adiadas, você deverá corrigir a origem dos erros de E/S. As soluções disponíveis, listadas na ordem em que normalmente são testadas, são as seguintes:

• Reinicie o banco de dados. Se o problema for transitório, o banco de dados deverá iniciar sem transações adiadas.

• Se as transações foram adiadas porque um grupo de arquivos estava offline, retome o grupo de arquivos.

  Para colocar um grupo de arquivos offline novamente online, use a seguinte instrução Transact-SQL:

  RESTORE DATABASE database_name FILEGROUP=<filegroup_name>  
  

• Restaure o banco de dados. Após uma restauração online, todas as transações adiadas são resolvidas.

  No modelo de recuperação completo ou bulk-logged, se as transações adiadas forem causadas por apenas algumas páginas corrompidas, uma restauração de página online poderá resolver os erros (quando houver suporte).

• Se você não precisar mais de um grupo de arquivos cujo status offline está causando transações adiadas, torne o grupo de arquivos offline desativado. As transações que foram adiadas porque o grupo de arquivos estava offline são movidas para fora do estado adiado depois que o grupo de arquivos é desativado.

  Importante

  Um grupo de arquivos extinto nunca pode ser recuperado.

  Para obter mais informações, consulte Remove Defunct Filegroups (SQL Server).

• Se as transações foram adiadas devido a uma página inválida e se um bom backup do banco de dados não existir, use o seguinte processo para reparar o banco de dados:

  • Primeiro coloque o banco de dados no modo de emergência executando a seguinte instrução Transact-SQL:

    ALTER DATABASE <database_name> SET EMERGENCY  
    

    Para obter informações sobre o modo de emergência, consulte Estados de Banco de Dados.

  • Em seguida, repare o banco de dados usando a opção DBCC REPAIR_ALLOW_DATA_LOSS em uma das seguintes instruções DBCC: DBCC CHECKDB, DBCC CHECKALLOC ou DBCC CHECKTABLE.

    Quando o DBCC encontra a página inválida, o DBCC a desaloca e repara quaisquer erros relacionados. Essa abordagem permite que o banco de dados seja colocado online novamente em um estado fisicamente consistente. No entanto, dados adicionais também podem ser perdidos; portanto, essa abordagem deve ser usada como último recurso.

Consulte Também

Visão geral da restauração e recuperação (SQL Server)
Remover grupos de arquivos extintos (SQL Server)
Restaurações de arquivo (modelo de recuperação completa)
Restaurações de arquivo (modelo de recuperação simples)
Restaurar Páginas (SQL Server)
Restaurações por etapas (SQL Server)
ALTERAR BASE DE DADOS (Transact-SQL)
RESTORE (Transact-SQL)