Transações adiadas (SQL Server)

Aplica-se a: SQL Server

No SQL Server Enterprise, uma transação corrompida pode ser adiada se os dados necessários na reversão (desfazer) estiverem offline durante a inicialização do banco de dados. Uma transação adiada é uma transação que não está confirmada no término da fase de roll forward e que encontrou um erro que impede a reversão. Como a transação não pode ser revertida, é adiada.

Geralmente, uma transação adiada ocorre porque, enquanto o roll forward do banco de dados estava sendo efetuado, um erro de E/S impediu a leitura de uma página exigida pela transação. Porém, um erro no arquivo também pode causar transações adiadas. Uma transação adiada também pode ocorrer quando uma sequência de restauração parcial para em um ponto em que a reversão de transação é necessária e uma transação requer dados que estão offline.

Transações de usuário que estão sendo revertidas e encontram um erro de E/S fazem com que todo o banco de dados fique offline. Quando o banco de dados volta a ficar online, essa ação faz com que ele readquira todos os bloqueios que tinha e tente reverter todas as transações não confirmadas. Todos os dados modificados por uma transação permanecem adequadamente bloqueados até que a transação possa ser revertida. Transações que não podem ser revertidas perderão seus bloqueios quando o dano for reparado e o banco de dados reinicializado ou, após uma restauração online, quando as transações adiadas são resolvidas enquanto o banco de dados permanece online. Até esse ponto, uma transação adiada pode manter bloqueios que impedem certas 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 tenha sido resolvida.

Uma transação adiada também pode ocorrer quando uma restauração por etapas recupera um banco de dados em um ponto no qual uma ou mais transações ativas estejam afetando um grupo de arquivos que ainda não tenha sido restaurado e está offline. Como as transações não podem ser revertidas, são adiadas.

A tabela a seguir lista as ações que fazem com que um banco de dados execute uma recuperação e o resultado da ocorrência de um problema de E/S.

Requisitos e limitações

• O banco de dados deve usar o modelo de recuperação FULL ou BULK-LOGGED.
• Pelo menos um backup de banco de dados e de log devem ter sido concluídos para o banco de dados
• As transações adiadas não se aplicam a erros encontrados durante a reversão de uma transação depois que o banco de dados está online (por exemplo, um erro de runtime)
• As transações não podem ser adiadas para falhas de recuperação ocorridas durante a anexação de um banco de dados
• Algumas transações, como transações do sistema (ex. alocação de páginas) não podem ser adiadas

Removendo uma transação do estado DEFERRED

Para remover a transação do estado adiado, o banco de dados deve ser inicializado de forma limpa sem qualquer erro de E/S. Se houver transações adiadas, será necessário reparar a origem dos erros de E/S. As soluções disponíveis, listadas na ordem em que são geralmente usadas, são as seguintes:

• Reinicialize o banco de dados. Se o problema foi temporário, o banco de dados deverá reinicializar sem transações adiadas.

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

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

  RESTORE DATABASE database_name FILEGROUP=<filegroup_name>  
  

• Restaure o banco de dados. Após a restauração online, qualquer transação adiada estará resolvida.

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

• Se você não precisar mais de um grupo de arquivos cujo status offline esteja causando transações adiadas, exclua o grupo de arquivos offline. Transações que foram adiadas porque o grupo de arquivos estava offline são removidas desse estado depois que o grupo de arquivos é considerado extinto.

  Importante

  Um grupo de arquivos extinto nunca pode ser recuperado.

  Para obter mais informações, consulte Remover grupos de arquivos expirados (SQL Server).

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

  • Primeiro, coloque o banco de dados em 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 Database States.

  • 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 CHECKALLOCou DBCC CHECKTABLE.

    Quando a DBCC encontra a página corrompida, anula sua alocação e repara qualquer erro relacionado. Essa abordagem permite que o banco de dados seja colocado novamente online, em um estado fisicamente consistente. Porém, dados adicionais também podem ser perdidos; portanto essa abordagem deve ser usada como último recurso.

Confira também

Visão geral da restauração e recuperação (SQL Server)
Remover grupos de arquivos expirados (SQL Server)
Restaurações de arquivo (modelo de recuperação completa)
Restaurações de arquivos (modelo de recuperação simples)
Restaurar páginas (SQL Server)
Restaurações por etapas (SQL Server)
ALTER DATABASE (Transact-SQL)
RESTORE (Transact-SQL)