Share via

Solucionar erros de log de transações com a Instância Gerenciada SQL do Azure

  • Artigo

Aplica-se a:Instância Gerenciada SQL do Azure

Você pode ver os erros 9002 ou 40552 quando o log de transações estiver cheio e não puder aceitar novas transações. Esses erros ocorrem quando o log de transações do banco de dados, gerenciado pela Instância Gerenciada SQL do Azure, excede os limites de espaço e não pode continuar a aceitar transações. Esses erros são semelhantes a problemas com um log de transações completo no SQL Server, mas têm resoluções diferentes no SQL Server, no Banco de Dados SQL do Azure e na Instância Gerenciada do SQL do Azure.

Nota

Este artigo é focado na Instância Gerenciada SQL do Azure. A Instância Gerenciada do SQL do Azure é baseada na versão estável mais recente do mecanismo de banco de dados do Microsoft SQL Server, portanto, grande parte do conteúdo é semelhante, embora as opções e ferramentas de solução de problemas possam diferir do SQL Server.

Para saber mais sobre como solucionar problemas de um log de transações no Banco de Dados SQL do Azure, consulte Solucionar erros de log de transações com o Banco de Dados SQL do Azure.

Para obter mais informações sobre como solucionar problemas de um log de transações no SQL Server, consulte Solucionar problemas de um log de transações completo (Erro 9002 do SQL Server).

Backups automatizados e o log de transações

Na Instância Gerenciada SQL do Azure, os backups do log de transações são feitos automaticamente. Para obter frequência, retenção e mais informações, consulte Backups automatizados. Para controlar quando backups automatizados foram executados em uma instância gerenciada pelo SQL, consulte Monitorar a atividade de backup.

O local e o nome dos arquivos de banco de dados não podem ser gerenciados, mas os administradores podem gerenciar arquivos de banco de dados e configurações de crescimento automático de arquivos. As causas e resoluções típicas de problemas de log de transações são semelhantes ao SQL Server.

Semelhante ao SQL Server, o log de transações para cada banco de dados é truncado sempre que um backup de log é concluído com êxito. O truncamento de log exclui arquivos de log virtuais (VLFs) inativos do log de transações, liberando espaço dentro do arquivo, mas não alterando o tamanho do arquivo no disco. O espaço vazio no arquivo de log pode ser usado para novas transações. Quando o arquivo de log não pode ser truncado por backups de log, o arquivo de log cresce para acomodar novas transações. Se o arquivo de log crescer até seu limite máximo na Instância Gerenciada SQL do Azure, novas transações de gravação falharão.

Na Instância Gerenciada SQL do Azure, você pode comprar armazenamento de complementos, independentemente da computação, até um limite. Para obter mais informações, consulte Gerenciamento de arquivos para liberar mais espaço.

Truncamento do log de transações impedido

Para descobrir o que está impedindo o truncamento de log em um determinado caso, consulte log_reuse_wait_desc em sys.databases. A espera de reutilização de log informa quais condições ou causas estão impedindo que o log de transações seja truncado por um backup de log regular. Para obter mais informações, veja sys.databases (Transact-SQL).

SELECT [name], log_reuse_wait_desc FROM sys.databases;

Os seguintes valores de in sys.databases podem indicar o motivo pelo qual o truncamento do log de transações do banco de log_reuse_wait_desc dados está sendo impedido:

log_reuse_wait_desc Diagnóstico Resposta necessária
NADA Estado típico. Não há nada que impeça o log de truncar. Não
PONTO DE VERIFICAÇÃO Um ponto de verificação é necessário para o truncamento de log. Raros. Nenhuma resposta necessária, a menos que seja mantida. Se for sustentado, registre uma solicitação de suporte no Suporte do Azure.
LOG BACKUP É necessário um backup de log. Nenhuma resposta necessária, a menos que seja mantida. Se for sustentado, registre uma solicitação de suporte no Suporte do Azure.
BACKUP OU RESTAURAÇÃO ATIVA Um backup de banco de dados está em andamento. Nenhuma resposta necessária, a menos que seja mantida. Se for sustentado, registre uma solicitação de suporte no Suporte do Azure.
TRANSAÇÃO ATIVA Uma transação contínua está impedindo o truncamento de log. O arquivo de log não pode ser truncado devido a transações ativas e/ou não confirmadas. Ver secção seguinte.
REPLICAÇÃO Na Instância Gerenciada SQL do Azure, pode ocorrer se a replicação ou o CDC estiverem habilitados. Se for sustentado, investigue os agentes envolvidos com CDC ou replicação. Para solucionar problemas de CDC, consulte trabalhos no msdb.dbo.cdc_jobs. Se não estiver presente, adicione via sys.sp_cdc_add_job. Para replicação, consulte Solução de problemas de replicação transacional. Se não for solúvel, envie uma solicitação de suporte ao Suporte do Azure.
AVAILABILITY_REPLICA A sincronização com a réplica secundária está em andamento. Nenhuma resposta necessária, a menos que seja mantida. Se for sustentado, registre uma solicitação de suporte no Suporte do Azure.

Truncamento de log impedido por uma transação ativa

O cenário mais comum para um log de transações que não pode aceitar novas transações é uma transação de longa duração ou bloqueada.

Execute esta consulta de exemplo para localizar transações não confirmadas ou ativas e suas propriedades.

  • Retorna informações sobre propriedades de transação, de sys.dm_tran_ative_transactions.
  • Retorna informações de conexão de sessão, do sys.dm_exec_sessions.
  • Retorna informações de solicitação (para solicitações ativas), de sys.dm_exec_requests. Esta consulta também pode ser usada para identificar sessões que estão sendo bloqueadas, procure o request_blocked_by. Para obter mais informações, consulte Reunir informações de bloqueio.
  • Retorna o texto da solicitação atual ou o texto do buffer de entrada, usando os DMVs sys.dm_exec_sql_text ou sys.dm_exec_input_buffer . Se os dados retornados pelo text campo de sys.dm_exec_sql_text é NULL, a solicitação não está ativa, mas tem uma transação pendente. Nesse caso, o campo de contém a última instrução passada para o event_info mecanismo de banco de sys.dm_exec_input_buffer dados.
SELECT [database_name] = db_name(s.database_id)
, tat.transaction_id, tat.transaction_begin_time, tst.session_id 
, session_open_transaction_count = tst.open_transaction_count
, transaction_duration_s = datediff(s, tat.transaction_begin_time, sysdatetime())
, input_buffer = ib.event_info
, request_text = CASE  WHEN r.statement_start_offset = 0 and r.statement_end_offset= 0 THEN left(est.text, 4000)
                       ELSE    SUBSTRING ( est.[text],    r.statement_start_offset/2 + 1, 
                                           CASE WHEN r.statement_end_offset = -1 THEN LEN (CONVERT(nvarchar(max), est.[text])) 
                                                ELSE r.statement_end_offset/2 - r.statement_start_offset/2 + 1
                                           END  )  END
, request_status = r.status
, request_blocked_by = r.blocking_session_id
, transaction_state = CASE tat.transaction_state    
                     WHEN 0 THEN 'The transaction has not been completely initialized yet.'
                     WHEN 1 THEN 'The transaction has been initialized but has not started.'
                     WHEN 2 THEN 'The transaction is active - has not been committed or rolled back.'
                     WHEN 3 THEN 'The transaction has ended. This is used for read-only transactions.'
                     WHEN 4 THEN 'The commit process has been initiated on the distributed transaction. This is for distributed transactions only. The distributed transaction is still active but further processing cannot take place.'
                     WHEN 5 THEN 'The transaction is in a prepared state and waiting resolution.'
                     WHEN 6 THEN 'The transaction has been committed.'
                     WHEN 7 THEN 'The transaction is being rolled back.'
                     WHEN 8 THEN 'The transaction has been rolled back.' END 
, transaction_name = tat.name
, transaction_type = CASE tat.transaction_type    WHEN 1 THEN 'Read/write transaction'
                                             WHEN 2 THEN 'Read-only transaction'
                                             WHEN 3 THEN 'System transaction'
                                             WHEN 4 THEN 'Distributed transaction' END
, tst.is_user_transaction
, local_or_distributed = CASE tst.is_local WHEN 1 THEN 'Local transaction, not distributed' WHEN 0 THEN 'Distributed transaction or an enlisted bound session transaction.' END
, transaction_uow    --for distributed transactions. 
, s.login_time, s.host_name, s.program_name, s.client_interface_name, s.login_name, s.is_user_process
, session_cpu_time = s.cpu_time, session_logical_reads = s.logical_reads, session_reads = s.reads, session_writes = s.writes
, observed = sysdatetimeoffset()
FROM sys.dm_tran_active_transactions AS tat 
INNER JOIN sys.dm_tran_session_transactions AS tst  on tat.transaction_id = tst.transaction_id
INNER JOIN Sys.dm_exec_sessions AS s on s.session_id = tst.session_id 
LEFT OUTER JOIN sys.dm_exec_requests AS r on r.session_id = s.session_id
CROSS APPLY sys.dm_exec_input_buffer(s.session_id, null) AS ib 
OUTER APPLY sys.dm_exec_sql_text (r.sql_handle) AS est;

Gestão de ficheiros para libertar mais espaço

Se o log de transações for impedido de truncar na Instância Gerenciada SQL do Azure, liberar espaço pode fazer parte da solução. No entanto, resolver a raiz da condição que bloqueia o truncamento do arquivo de log de transações é fundamental. Em alguns casos, a criação temporária de mais espaço em disco permite que transações de longa duração sejam concluídas, removendo a condição que impede o truncamento do arquivo de log de transações com um backup de log de transações normal. No entanto, liberar espaço pode fornecer apenas alívio temporário até que o log de transações cresça novamente.

Na Instância Gerenciada SQL do Azure, você pode comprar armazenamento de complementos, independentemente da computação, até um limite. Por exemplo, no portal do Azure, acesse a página Computação + armazenamento para aumentar o armazenamento em GB. Para obter informações sobre limites de tamanho do log de transações, consulte Limites de recursos para Instância Gerenciada SQL. Para obter mais informações, consulte Gerenciar espaço de arquivo para bancos de dados na Instância Gerenciada SQL do Azure.

O armazenamento de backup não é deduzido do espaço de armazenamento da instância gerenciada SQL. O armazenamento de backup é independente do espaço de armazenamento da instância e não é limitado em tamanho.

Erro 9002: O log de transações do banco de dados está cheio

9002: The transaction log for database '%.*ls' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases.

O erro 9002 ocorre no SQL Server e na Instância Gerenciada SQL do Azure pelos mesmos motivos.

A resposta apropriada a um log de transações completo depende das condições que causaram o preenchimento do log.

Para resolver o erro 9002, tente os seguintes métodos:

  • O log de transações não está sendo truncado e cresceu para preencher todo o espaço disponível.
    • Como os backups do log de transações na Instância Gerenciada SQL do Azure são automáticos, algo mais deve impedir que a atividade do log de transações seja truncada. A replicação incompleta, o CDC ou a sincronização do grupo de disponibilidade podem estar impedindo o truncamento, consulte Impedir o truncamento do log de transações.
  • O tamanho do armazenamento reservado da instância gerenciada SQL está cheio e o log de transações não pode crescer.
  • O tamanho do Log de Transações é definido como um valor máximo fixo ou o crescimento automático está desativado e, portanto, não pode crescer.

Erro 40552: A sessão foi encerrada devido ao uso excessivo de espaço no log de transações

40552: The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.

Embora o Erro 9002 seja mais comum do que o Erro 40552 na Instância Gerenciada SQL do Azure, ambos podem ocorrer.

Para resolver o erro 40552, tente os seguintes métodos:

  • O problema pode ocorrer em qualquer operação DML, como inserir, atualizar ou excluir. Revise a transação para evitar gravações desnecessárias. Tente reduzir o número de linhas que são operadas imediatamente implementando lotes ou dividindo em várias transações menores. Para obter mais informações, consulte Como usar o processamento em lote para melhorar o desempenho do aplicativo.
  • O problema pode ocorrer devido a operações de reconstrução de índice. Para evitar esse problema, verifique se a seguinte fórmula é verdadeira: (número de linhas afetadas na tabela) multiplicado por (o tamanho médio do campo atualizado em bytes + 80) < 2 gigabytes (GB). Para tabelas grandes, considere criar partições e executar a manutenção do índice apenas em algumas partições da tabela. Para obter mais informações, consulte Criar tabelas e índices particionados.
  • Se você executar inserções em massa usando o utilitário ou a System.Data.SqlClient.SqlBulkCopy classe, tente usar as -b batchsize opções ou BatchSize para limitar o número de linhas copiadas para o bcp.exe servidor em cada transação. Para obter mais informações, consulte bcp Utility.
  • Se você estiver reconstruindo um índice com a ALTER INDEX instrução, use as SORT_IN_TEMPDB = ONopções , ONLINE = ONe RESUMABLE=ON . Com índices retomáveis, o truncamento de log é mais frequente. Para obter mais informações, consulte ALTER INDEX (Transact-SQL).

Próximos passos