Le journal des transactions de la base de données est plein

J'ai un processus de longue durée qui maintient une transaction ouverte pendant toute la durée.

Je n'ai aucun contrôle sur la manière dont cela est exécuté.

Étant donné qu'une transaction est maintenue ouverte pendant toute la durée, lorsque le journal des transactions se remplit, SQL Server ne peut pas augmenter la taille du fichier journal.

Donc, le processus échoue avec l'erreur "The transaction log for database 'xxx' is full".

J'ai tenté d'éviter cela en augmentant la taille du fichier journal des transactions dans les propriétés de la base de données, mais j'obtiens la même erreur.

Je ne sais pas ce que je devrais essayer ensuite. Le processus dure plusieurs heures, il n'est donc pas facile de jouer à des essais et des erreurs.

Des idées?

Si quelqu'un est intéressé, le processus est une importation d'organisation dans Microsoft Dynamics CRM 4.0.

Il y a beaucoup d'espace disque, nous avons le journal en mode de journalisation simple et avons sauvegardé le journal avant de lancer le processus.

- = - = - = - = - MISE À JOUR - = - = - = - = -

Merci à tous pour les commentaires jusqu'à présent. Voici ce qui m'a amené à croire que le journal ne se développerait pas en raison de la transaction ouverte:

Je reçois l'erreur suivante...

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

Donc, suite à ce conseil, je suis allé à " log_reuse_wait_desc column in sys.databases" et il avait la valeur " ACTIVE_TRANSACTION".

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

Cela signifie ce qui suit:

Une transaction est active (tous les modèles de récupération). • Une transaction de longue durée peut exister au début de la sauvegarde du journal. Dans ce cas, la libération de l'espace peut nécessiter une autre sauvegarde du journal. Pour plus d'informations, consultez «Transactions actives de longue durée», plus loin dans cette rubrique.

• Une transaction est différée (SQL Server 2005 Enterprise Edition et versions ultérieures uniquement). Une transaction différée est en fait une transaction active dont la restauration est bloquée en raison d'une ressource indisponible. Pour plus d'informations sur les causes des transactions différées et comment les sortir de l'état différé, voir Transactions différées.

Ai-je mal compris quelque chose?

- = - = - = - MISE À JOUR 2 - = - = - = -

Je viens de lancer le processus avec une taille de fichier journal initiale de 30 Go. Cela prendra quelques heures.

- = - = - = - MISE À JOUR finale - = - = - = -

Le problème était en fait dû au fait que le fichier journal consommait tout l'espace disque disponible. Dans la dernière tentative, j'ai libéré 120 Go et il a encore utilisé tout cela et a finalement échoué.

Je ne savais pas que cela se produisait auparavant parce que lorsque le processus fonctionnait pendant la nuit, il revenait à l'échec. Cette fois, j'ai pu vérifier la taille du fichier journal avant la restauration.

Merci à tous pour votre contribution.

S'agit-il d'un script ponctuel ou d'un travail régulier?

Dans le passé, pour les projets spéciaux qui nécessitent temporairement beaucoup d'espace pour le fichier journal, j'ai créé un deuxième fichier journal et je l'ai rendu énorme. Une fois le projet terminé, nous avons supprimé le fichier journal supplémentaire.

Pour résoudre ce problème, modifiez le modèle de récupération en simple puis réduisez le journal des fichiers

1. Propriétés de la base de données> Options> Modèle de récupération> Simple

2. Tâches de base de données> Réduire> Fichiers> Journal

Terminé.

Vérifiez ensuite la taille de votre fichier journal db dans Propriétés de la base de données> Fichiers> Fichiers de base de données> Chemin

Pour vérifier le journal complet du serveur SQL: ouvrez la visionneuse de fichiers journaux dans SSMS> Base de données> Gestion> Journaux SQL Server> Actuel

J'ai eu cette erreur une fois et cela a fini par être le disque dur du serveur qui manquait d'espace disque.

Avez-vous activé la croissance automatique et la croissance de fichier illimitée pour le fichier journal? Vous pouvez les modifier via SSMS dans "Propriétés de la base de données> Fichiers"

C'est une approche à l'ancienne, mais si vous effectuez une mise à jour itérative ou une opération d'insertion dans SQL, quelque chose qui s'exécute pendant une longue période, c'est une bonne idée d'appeler périodiquement (par programme) "checkpoint". L'appel de «point de contrôle» fait en sorte que SQL écrive sur le disque toutes ces modifications de mémoire seule (pages modifiées, elles sont appelées) et les éléments stockés dans le journal des transactions. Cela a pour effet de nettoyer périodiquement votre journal des transactions, évitant ainsi des problèmes comme celui décrit.

Ce qui suit tronquera le journal.

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

Si votre modèle de récupération de base de données est complet et que vous n'avez pas de plan de maintenance de sauvegarde de journal, vous obtiendrez cette erreur car le journal des transactions devient plein en raison de LOG_BACKUP.

Cela empêchera toute action sur cette base de données (par exemple, réduire) et le moteur de base de données SQL Server générera une erreur 9002.

Pour surmonter ce problème, je vous conseille de vérifier ceci Le journal des transactions de la base de données 'SharePoint_Config' est plein en raison de LOG_BACKUP qui montre des étapes détaillées pour résoudre le problème.

J'ai rencontré l'erreur: «Le journal des transactions de la base de données '...' est plein en raison de 'ACTIVE_TRANSACTION' lors de la suppression des anciennes lignes des tables de ma base de données pour libérer de l'espace disque. J'ai réalisé que cette erreur se produirait si le nombre de lignes à être supprimé était supérieur à 1000000 dans mon cas.Ainsi, au lieu d'utiliser 1 instruction DELETE, j'ai divisé la tâche de suppression en utilisant l'instruction DELETE TOP (1000000) ....

Par exemple:

au lieu d'utiliser cette instruction:

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

en utilisant l'instruction suivante à plusieurs reprises:

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

Mon problème a été résolu avec plusieurs exécutions de suppressions limitées comme

Avant

DELETE FROM TableName WHERE Condition

Après

DELETE TOP(1000) FROM TableName WHERECondition

La réponse à la question n'est pas de supprimer les lignes d'une table, mais c'est l'espace tempDB qui est occupé en raison d'une transaction active. cela se produit principalement quand il y a une fusion (upsert) est en cours d'exécution où nous essayons d'insérer la mise à jour et de supprimer les transactions. La seule option est de s'assurer que la base de données est définie sur le modèle de récupération simple et d'augmenter également le fichier à l'espace maximum (ajouter un autre groupe de fichiers). Bien que cela ait ses propres avantages et inconvénients, ce sont les seules options.

L'autre option dont vous disposez est de diviser la fusion (upsert) en deux opérations. l'un qui fait l'insertion et l'autre qui fait la mise à jour et la suppression.

Essaye ça:

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 

J'espère que cela aide.

Voici mon code de héros. J'ai fait face à ce problème. Et utilisez ce code pour résoudre ce problème.

 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);

Essaye ça:

Si possible, redémarrez les services MSSQLSERVER et SQLSERVERAGENT .