Um registo de transacções aumenta inesperadamente ou fica cheio num computador que está a executar o SQL Server

No SQL Server 7.0, no SQL Server 2000 e no SQL Server 2005, com a definição autogrow, ficheiros de registo de transacções podem expandir automaticamente.

Normalmente, o tamanho do ficheiro log transacções stabilizes quando pode conter o número máximo de transacções que podem ocorrer entre truncations de registo de transacções que accionam a pontos de verificação ou cópias de segurança de registo de transacções.

No entanto, em algumas situações que o registo de transacções poderá tornar-se muito grande e execute espaço ou ficar cheio. Normalmente, recebe a seguinte mensagem de erro quando uma transacção iniciar ficheiro demora mais espaço em disco disponível e não pode expandir mais: Se estiver a utilizar o SQL Server 2005, receberá uma mensagem de erro semelhante à seguinte:Juntamente com esta mensagem de erro, SQL Server pode marcar suspeita de bases de dados devido à falta de espaço para expansão do registo de transacções. Para obter informações adicionais sobre como recuperar nesta situação, consulte o tópico "Espaço insuficiente no disco" no SQL Server Books Online.

Além disso, poderá resultar expansão de registo de transacções nas seguintes situações:

• Um ficheiro de registo de transacções muito grande.
• As transacções poderão falhar e poderão começar a recuperar.
• Transacções poderão demorar muito tempo a concluir.
• Problemas de desempenho poderão ocorrer.
• Bloquear poderá ocorrer.

Faz com que

Expansão de registo de transacções pode ocorrer devido os motivos ou cenários seguintes:

• Uncommitted transactions
• Extremely large transactions
• Operations: DBCC DBREINDEX and CREATE INDEX
• While restoring from transaction log backups
• Client applications do not process all results
• Queries time out before a transaction log completes the expansion and you receive false 'Log full' error messages
• Unreplicated transactions

Nota No SQL Server 2005, pode rever as colunas log_reuse_wait e log_reuse_wait_desc da vista sys.databases catálogo para determinar os seguintes procedimentos:

• O espaço de registo de transacções não está reutilizado
• Por que razão o registo de transacções não pode ser truncado

Transacções não consolidadas

Transacções explícitas permanecem não consolidadas se não emitem um comando COMMIT ou ROLLBACK explícito. Este mais ocorre frequentemente quando uma aplicação emite um ' Cancelar ' ou um comando Transact SQL KILL sem um comando ROLLBACK correspondente. Ocorre o cancelamento de transacção, mas não recuperar; por este motivo, o SQL Server não é possível truncar todas as transacções que ocorre depois porque a transacção abortada ainda está aberta. Pode utilizar a referência DBCC OPENTRAN Transact-SQL para verificar se existe uma transacção activa numa base de dados num determinado momento. Para obter mais informações sobre este cenário específico, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft: Além disso, consulte o tópico "DBCC OPENTRAN" no SQL Server Books Online.

cenários que podem resultar em transacções não consolidadas :

• Concepção de aplicações que parte do princípio que todos os erros provocam anulação de alterações.
• Concepção de aplicações não completamente tem em consideração o comportamento do SQL Server quando-recupera para transacções com o nome ou aninhados para transacções com o nome. Se tentar reverter para uma transacção interna com nome, receberá a seguinte mensagem de erro:
  Servidor: Erro 6401, 16 de nível 1 de estado, 13 de linha não pode recuperar InnerTran. Não foi encontrado nenhuma transacção ou ponto de salvaguarda esse nome.
  Depois do SQL Server gera a mensagem de erro, continua a instrução seguinte. Isto ocorre por predefinição. Para mais informações, consulte o tópico "Transacções aninhado" ou "Inside SQL Server" no SQL Server Books Online.
  
  Quando estrutura a aplicação a Microsoft recomenda o seguinte:
  • Abra apenas uma unidade de transacção (considere a possibilidade de outro processo pode chamar seu).
  • Verificar @@ TRANCOUNT antes de emitir um COMMIT, um ROLLBACK, RETURN, ou um comando semelhante ou instrução.
  • Escreva o código com pressuposto de que outro @@ TRANCOUNT pode "aninhar" seu e planear o @@ TRANCOUNT externa ser distribuído novamente quando ocorre um erro.
  • Reveja o ponto de salvaguarda e marcar opções para as transacções. (Estes não libertar bloqueios!)
  • Execute teste concluído.
• Uma aplicação que permite a interacção do utilizador dentro de transacções. Isto faz com que a transacção permaneçam abertos durante muito tempo, que faz com que o bloqueio e transacção registo crescimento porque a transacção aberta não pode ser truncada e novas transacções são adicionadas ao registo depois de transacção aberta.
• Uma aplicação que não verifica @@ TRANCOUNT para verificar se existe são não existem transacções abertas.
• Rede ou outros erros que fechar a ligação de aplicação de cliente para o SQL Server sem informando-o.
• Agrupamento de ligações. Depois de criadas threads de trabalho, SQL Server reutiliza-los se estes não são atender uma ligação. Se uma ligação de utilizador inicia uma transacção e termina a ligação antes de confirmar ou anular a transacção e uma ligação a partir daí reutiliza o mesmo thread, a transação anterior ainda permanece aberta. Esta situação resulta num bloqueios que ficar abertos da transação anterior e impede a truncagem de transacções consolidadas no registo, que resulta em tamanhos de ficheiro de registo grandes.Para obter mais informações sobre o agrupamento de ligações, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:
  164221  (http://support.microsoft.com/kb/164221/ ) Como activar o agrupamento de ligações numa aplicação de ODBC

Transacções extremamente grandes

Registos nos ficheiros de registo de transacções são truncados numa transacção por transacção. Se o âmbito de transacção for grande, que a transacção e quaisquer transacções iniciado depois de não são removidos do registo de transacções, a menos que termine. Isto pode resultar em ficheiros de registo grande. Se a transacção é suficientemente grande, o ficheiro de registo pode utilizar o espaço em disco disponível e fazer com que tipo de mensagem de erro como erro 9002 "registo de transacções completo". Para obter informações adicionais sobre o que fazer quando receber este tipo de mensagem de erro são fornecidas na secção "Mais informação" deste artigo. Além disso, demora muito tempo e a capacidade do SQL Server para recuperar transacções grandes.

Operações: DBCC DBREINDEX e CREATE INDEX

Devido às alterações no modelo de recuperação no SQL Server 2000, quando utiliza o modo de recuperação total e executar o comando DBCC DBREINDEX, o registo de transacções poderá expandir significativamente mais comparados do SQL Server 7.0 num modo de recuperação equivalente com a utilização de SELECT INTO ou BULK COPY e "truncagem. Terminar chkpt.".

Embora o tamanho do registo de transacções após a operação de DBREINDEX pode ser um problema, esta abordagem fornece melhor desempenho de restauro do registo.

Durante o restauro de cópias de segurança de registo de transacções

Isto é descrito no seguinte artigo de base de dados de conhecimento da Microsoft:
Se definiu o SQL Server 2000 para utilizar o modo Bulk-Logged e emitir uma instrução SELECT INTO ou BULK COPY, cada extensão alterado é marcado e, em seguida, foi cópias quando cria uma cópia do registo de transacções. Apesar de Isto permite a cópia de registos de transacções e recuperar de falhas, mesmo depois de efectuar operações em massa, esta acção adiciona o tamanho dos registos de transacções. SQL Server 7.0 não inclui esta funcionalidade. SQL Server 7.0 só regista as extensões são alteradas, mas não regista extensões reais. Por conseguinte, o registo ocupa significativamente mais espaço no SQL Server 2000 que no SQL Server 7.0 no modo de registo em massa mas não tanto como acontece no modo de ecrã inteiro.

Aplicações de cliente não processam todos os resultados

Se emitir uma consulta para o SQL Server e não processa os resultados imediatamente, poderá ser mantendo bloqueios e reduzir a concorrência no servidor.

Por exemplo, suponha que emitir uma consulta que necessita de linhas de duas páginas para preencher o resultado definido. SQL Server analisa, compila e executa a consulta. Isto significa que bloqueios partilhados são colocados em duas páginas que contêm as linhas que tem de ter para satisfazer a consulta. Além disso, suponha que nem todas as linhas ajustar a um pacote de SQL Server TDS (o método pelo qual o servidor comunica com o cliente). Os pacotes TDS são preenchidos e enviados ao cliente. Se todas as linhas na primeira página se ajustar no pacote TDS, SQL Server liberta o bloqueio partilhado nessa página, mas deixa um bloqueio partilhado na segunda página. SQL Server, em seguida, aguarda que o cliente pedir mais dados (que pode efectuar isto utilizando DBNEXTROW/DBRESULTS, SQLNextRow/SQLResults ou FetchLast/FetchFirst por exemplo).

Isto significa que o bloqueio partilhado é mantido até que o cliente pede o resto dos dados. Outros processos que pedem dados a partir da segunda página podem estar bloqueados.

Consulta o tempo limite antes de um registo de transacções conclui a expansão ou receber mensagens de erro 'Registo completo' falsas

Nesta situação, embora não exista espaço em disco suficiente, ainda recebe uma "fora do espaço de" mensagem de erro.

Esta situação varia para o SQL Server 7.0 e SQL Server 2000.

Uma consulta pode causar o registo transacção expandir automaticamente se o registo de transacções estiver quase cheio. Isto pode demorar mais tempo e uma consulta pode ser parada ou pode exceder o respectivo período de tempo de espera devido a isto. SQL Server 7.0 devolve erro 9002 nesta situação. Este problema não se aplica para o SQL Server 2000.

No SQL Server 2000, se tiver a opção de redução automática activada para uma base de dados, existe um extremamente pequena tempo durante o qual um registo de transacções tenta expandir automaticamente, mas não porque a função de redução automática está em execução em simultâneo. Isto também poderá provocar falsas instâncias do erro 9002.

Normalmente, a expansão automática dos ficheiros de registo de transacções ocorre rapidamente. No entanto, nas seguintes situações, poderá demorar mais tempo do que o habitual:

• São demasiado pequenos incrementos de crescimento.
• Servidor é lento por diversas razões.
• Unidades de disco não são suficientemente rápidas.

Transacções unreplicated

Pode expandir o tamanho registo de transacções da base de dados o publisher se estiver a utilizar a replicação. As transacções que afectam os objectos que são replicados estão marcadas como "Para replicação". Estas transacções, como transações não consolidadas, não são eliminadas após o ponto de verificação ou depois de cópia de segurança do registo de transacções até a tarefa de leitor de registo copia as transacções para a base de dados de distribuição e desmarca os. Se um problema com a tarefa de leitor de registo impede ler estas transacções na base de dados o publisher , o tamanho do registo transacção poderá continuar a expandir como o número de transacções não replicadas aumenta. Pode utilizar a referência DBCC OPENTRAN Transact-SQL para identificar a transacção mais antiga não replicadas.

Para mais informações sobre como resolver transacções unreplicated, consulte os tópicos "sp_replcounters" e "sp_repldone" no SQL Server Books Online.

Para obter mais informações, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft:

O registo de transacções para uma base de dados é gerido como um conjunto de virtual ficheiros de registo (VLF) cujo tamanho do SQL Server internamente determina com base no tamanho total do ficheiro de registo e o incremento de crescimento em utilização quando expande o registo. Um registo expande-se sempre em unidades de VLF todo e só pode comprimir para um limite VLF. Pode existir um VLF das três estados: ACTIVE RECUPERÁVEIS e REUTILIZÁVEIS.

• ACTIVE : A parte do registo activa começa o número de sequência de registo mínimo (LSN) que representa uma transacção activa (não consolidada). Parte do registo activa termina em LSN escritos por último. Qualquer VLF com qualquer parte do registo activo é considerados activa VLF. (espaço não utilizado no registo físico não é parte de qualquer VLF.)
• RECUPERÁVEL : A parte do registo que precede a transacção activa mais antiga é apenas necessária para manter uma sequência de cópias de segurança registo para fins de recuperação.
• REUTILIZÁVEIS : Se não estiver a manter cópias de segurança de registo de transacções ou se já cópias o registo, o SQL Server reutiliza VLF antes da transacção activa mais antiga.

Quando do SQL Server chega ao fim do ficheiro de registo físico, este é iniciado reutilizar esse espaço no ficheiro físico emitindo um ASSINALANDO novamente a operação para o início dos ficheiros. Na realidade, o SQL Server recicla o espaço no ficheiro de registo que já não é necessário para fins de cópia de segurança ou recuperação. Se está a ser mantida uma sequência de cópia de segurança do registo, a parte do registo antes do mínimo LSN não pode ser substituídos até efectuar uma cópia de segurança ou truncar os registos. Depois de efectuar a cópia de segurança registo, SQL Server pode círculo regressar ao início do ficheiro. Depois do SQL Server círculos novamente para começar a escrever registo registos anteriormente no ficheiro de registo, parte do registo de reutilizável, em seguida, entre o fim do registo de lógico e parte activa o registo.

Para obter informações adicionais, consulte o tópico "Transaction Log Physical Architecture" no SQL Server Books Online. Além disso, pode ver um diagrama excelente e debate na página 190 do "No interior SQL Server 7.0" (Soukup, Ron. Interior Microsoft SQL Server 7.0, Microsoft Press, 1999) e também nas páginas 182 através de 186 de "No interior SQL Server 2000" (Delaney, Kalen. Interior Microsoft SQL Server 2000, Microsoft Press, 2000). Bases de dados SQL Server 7.0 e SQL Server 2000 tem opções autogrow e autoshrink. Pode utilizar estas opções para ajudá-lo para comprimir ou expandir o log de transacções.

Para obter mais informações sobre como estas opções podem afectar o servidor, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base: Existe uma diferença entre a truncagem versus a compressão do ficheiro de registo de transacções. Quando o SQL Server trunca um ficheiro de registo de transacções, isto significa que o conteúdo desse ficheiro (por exemplo, as transacções consolidadas) são eliminados. No entanto, quando visualiza o tamanho do ficheiro uma perspectiva de espaço em disco (por exemplo, no Explorador do Windows ou utilizando o comando dir ) o tamanho permanece inalterado. No entanto, o espaço dentro do ficheiro .ldf agora pode ser reutilizado por novas transacções. Apenas quando o SQL Server diminui o tamanho do ficheiro log transacções,, na realidade, verá uma alteração no tamanho físico do ficheiro de registo.

Para obter mais informações sobre como diminuir registos de transacções, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft: Para obter mais informações sobre utilização de registo de transacção do SQL Server 6.5, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

Como localizar consultas consumam uma grande quantidade de espaço de registo no SQL Server 2005

No SQL Server 2005, pode utilizar a vista de gestão dinâmica sys.dm_tran_database_transactions (DMV) para localizar as consultas que consomem grandes quantidades de espaço de registo. As seguintes colunas o sys.dm_tran_database_transactions DMV pode ser útil:

• database_transaction_log_bytes_used
• database_transaction_log_bytes_used_system
• database_transaction_log_bytes_reserved
• database_transaction_log_bytes_reserved_system
• database_transaction_log_record_count

Pode consultar a coluna sql_handle da sys.dm_exec_requests DMV para obter o texto de instrução real que consome grandes quantidades de espaço de registo. Pode fazê-lo aderir sys.dm_tran_database_transactions DMV e sys.dm_tran_session_transactions DMV na coluna transaction_id e, em seguida, adicionando uma associação adicional com sys.dm_exec_requests na coluna session_id.

Para obter mais informações sobre sys.dm_tran_database_transactions DMV, visite o seguinte Web site da Microsoft Developer Network (MSDN): Para obter mais informações sobre sys.dm_tran_session_transactions DMV, visite o seguinte site da Web MSDN: Para obter mais informações sobre sys.dm_exec_requests DMV, visite o seguinte site da Web MSDN: