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

Tenho um processo demorado que mantém uma transação aberta por toda a duração.

Não tenho controle sobre a maneira como isso é executado.

Como uma transação é mantida aberta por toda a duração, quando o log de transações é preenchido, o SQL Server não pode aumentar o tamanho do arquivo de log.

Portanto, o processo falha com o erro "The transaction log for database 'xxx' is full".

Tentei evitar isso aumentando o tamanho do arquivo de log de transações nas propriedades do banco de dados, mas recebo o mesmo erro.

Não tenho certeza do que devo tentar a seguir. O processo dura várias horas, por isso não é fácil jogar por tentativa e erro.

Alguma ideia?

Se alguém estiver interessado, o processo é uma importação de organização em Microsoft Dynamics CRM 4.0.

Há bastante espaço em disco, temos o log no modo de registro simples e fizemos o backup do log antes de iniciar o processo.

- = - = - = - = - ATUALIZAÇÃO - = - = - = - = -

Obrigado a todos pelos comentários até agora. O seguinte é o que me levou a acreditar que o log não cresceria devido à transação aberta:

Eu estou recebendo o seguinte erro...

Import Organization (Name=xxx, Id=560d04e7-98ed-e211-9759-0050569d6d39) failed with Exception:
System.Data.SqlClient.SqlException: The transaction log for database 'xxx' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

Seguindo esse conselho, fui para " log_reuse_wait_desc column in sys.databases" e ele continha o valor " ACTIVE_TRANSACTION".

De acordo com a Microsoft: http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx

Isso significa o seguinte:

Uma transação está ativa (todos os modelos de recuperação). • Uma transação de longa duração pode existir no início do backup de log. Nesse caso, a liberação de espaço pode exigir outro backup de log. Para obter mais informações, consulte "Transações ativas de longa duração", posteriormente neste tópico.

• Uma transação é adiada (SQL Server 2005 Enterprise Edition e versões posteriores apenas). Uma transação adiada é efetivamente uma transação ativa cujo rollback está bloqueado devido a algum recurso indisponível. Para obter informações sobre as causas das transações adiadas e como retirá-las do estado adiado, consulte Transações adiadas.

Eu não entendi alguma coisa?

- = - = - = - ATUALIZAÇÃO 2 - = - = - = -

Acabei de iniciar o processo com o tamanho do arquivo de log inicial definido para 30 GB. Isso levará algumas horas para ser concluído.

- = - = - = - ATUALIZAÇÃO Final - = - = - = -

O problema era realmente causado pelo arquivo de log consumindo todo o espaço disponível em disco. Na última tentativa, liberei 120 GB e ainda usei tudo e acabou falhando.

Não percebi que isso estava acontecendo antes porque, quando o processo estava em execução durante a noite, ele voltava em caso de falha. Desta vez, consegui verificar o tamanho do arquivo de log antes do rollback.

Obrigado a todos por sua contribuição.

Este é um script único ou um trabalho que ocorre regularmente?

No passado, para projetos especiais que requerem temporariamente muito espaço para o arquivo de log, criei um segundo arquivo de log e o tornei enorme. Assim que o projeto estiver concluído, removemos o arquivo de log extra.

Para corrigir esse problema, altere o modelo de recuperação para Simples e depois diminua o registro de arquivos

1. Propriedades do banco de dados> Opções> Modelo de recuperação> Simples

2. Tarefas de banco de dados> Reduzir> Arquivos> Log

Feito.

Em seguida, verifique o tamanho do arquivo de log do banco de dados em Propriedades do banco de dados> Arquivos> Arquivos do banco de dados> Caminho

Para verificar o log do sql server completo: abra o Log File Viewer em SSMS> Database> Management> SQL Server Logs> Current

Eu tive esse erro uma vez e acabou sendo o disco rígido do servidor que ficou sem espaço em disco.

Você tem Ativar Aumento Automático e Crescimento Irrestrito de Arquivo ativados para o arquivo de log? Você pode editá-los via SSMS em "Propriedades do banco de dados> Arquivos"

Esta é uma abordagem da velha escola, mas se você estiver realizando uma atualização iterativa ou operação de inserção em SQL, algo que é executado por um longo tempo, é uma boa ideia periodicamente (programaticamente) chamar "checkpoint". Chamar "ponto de verificação" faz com que o SQL grave no disco todas as alterações apenas de memória (páginas sujas, são chamadas) e itens armazenados no log de transações. Isso tem o efeito de limpar o log de transações periodicamente, evitando problemas como o descrito.

O seguinte truncará o log.

USE [yourdbname] 
GO

-- TRUNCATE TRANSACTION LOG --
DBCC SHRINKFILE(yourdbname_log, 1)
BACKUP LOG yourdbname WITH TRUNCATE_ONLY
DBCC SHRINKFILE(yourdbname_log, 1)
GO

-- CHECK DATABASE HEALTH --
ALTER FUNCTION [dbo].[checker]() RETURNS int AS BEGIN  RETURN 0 END
GO

Se o seu modelo de recuperação de banco de dados estiver cheio e você não tiver um plano de manutenção de backup de log, receberá este erro porque o log de transações fica cheio devido a LOG_BACKUP.

Isso impedirá qualquer ação neste banco de dados (por exemplo, reduzir) e o Mecanismo de banco de dados do SQL Server gerará um erro 9002.

Para superar esse comportamento, aconselho você a verificar isso O log de transações do banco de dados 'SharePoint_Config' está cheio devido ao LOG_BACKUP que mostra as etapas detalhadas para resolver o problema.

Encontrei o erro: "O log de transações do banco de dados '...' está cheio devido a 'ACTIVE_TRANSACTION' ao excluir linhas antigas das tabelas do meu banco de dados para liberar espaço em disco. Percebi que esse erro ocorreria se o número de linhas para ser excluído era maior que 1000000 no meu caso. Então, em vez de usar 1 instrução DELETE, eu dividi a tarefa de exclusão usando DELETE TOP (1000000) .... instrução.

Por exemplo:

em vez de usar esta declaração:

DELETE FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

usando a seguinte declaração repetidamente:

DELETE TOP(1000000) FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

Meu problema foi resolvido com a execução múltipla de exclusões limitadas como

Antes

DELETE FROM TableName WHERE Condition

Depois de

DELETE TOP(1000) FROM TableName WHERECondition

A resposta à pergunta não é excluir as linhas de uma tabela, mas é o espaço do tempDB que está sendo ocupado devido a uma transação ativa. isso acontece principalmente quando há uma mesclagem (upsert) sendo executada onde tentamos inserir, atualizar e excluir as transações. A única opção é certificar-se de que o banco de dados está configurado para o modelo de recuperação simples e também aumentar o arquivo para o espaço máximo (adicionar outro grupo de arquivos). Embora isso tenha suas próprias vantagens e desvantagens, essas são as únicas opções.

A outra opção que você tem é dividir a fusão (upsert) em duas operações. um que faz a inserção e outro que faz a atualização e exclusão.

Experimente isto:

USE YourDB;  
GO  
-- Truncate the log by changing the database recovery model to SIMPLE.  
ALTER DATABASE YourDB
SET RECOVERY SIMPLE;  
GO  
-- Shrink the truncated log file to 50 MB.  
DBCC SHRINKFILE (YourDB_log, 50);  
GO  
-- Reset the database recovery model.  
ALTER DATABASE YourDB
SET RECOVERY FULL;  
GO 

Espero que ajude.

Aqui está o meu código de herói. Eu enfrentei esse problema. E use este código para corrigir isso.

 USE master;

    SELECT 
        name, log_reuse_wait, log_reuse_wait_desc, is_cdc_enabled 
    FROM 
        sys.databases 
    WHERE 
        name = 'XX_System';

    SELECT DATABASEPROPERTYEX('XX_System', 'IsPublished');


    USE XX_System;
    EXEC sp_repldone null, null, 0,0,1;
    EXEC sp_removedbreplication XX_System;


    DBCC OPENTRAN;
    DBCC SQLPERF(LOGSPACE);
    EXEC sp_replcounters;



    DBCC SQLPERF(LOGSPACE);

Experimente isto:

Se possível reinicie os serviços MSSQLSERVER e SQLSERVERAGENT .