Transações adiadas

No SQL Server 2005 Enterprise Edition e em versões posteriores, uma transação corrompida poderá ser adiada se os dados s necessários na reversão 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.

ObservaçãoObservação

Transações corrompidas só são adiadas no SQL Server 2005 Enterprise Edition e em versões posteriores. Em outras edições do SQL Server, uma transação corrompida causa falha na inicialização.

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 seqüência de restauração parcial pára 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.

Ação

Resolução (se ocorrerem problemas de E/S ou se os dados exigidos estiverem offline)

Inicialização do servidor

Transações adiadas

Restauração

Transações adiadas

Anexar

Falha ao anexar

Reinicialização automática

Transações adiadas

Criar banco de dados ou instantâneo do banco de dados

Falha ao criar

Refazer espelhamento de banco de dados

Transações adiadas

O grupo de arquivos está offline

Transações adiadas

Removendo uma transação do estado DEFERRED

Observação importanteImportante

As transações adiadas mantêm o log de transações ativo. Um arquivo de log virtual que contém qualquer transação adiada não pode ser truncado até que essas transações sejam removidas do estado adiado. Para obter mais informações sobre truncamento de log, consulte Truncamento de log de transações.

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 um grupo de arquivos offline online, 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.

    Observação importanteImportante

    Um grupo de arquivos extinto nunca pode ser recuperado.

    Para obter mais informações, consulte Grupo de arquivos expirados.

  • 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 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 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.