Le journal des transactions de la base de données est pleine
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 façon dont ceci est exécuté.
Comme une transaction est maintenue ouverte pendant toute la durée, lorsque le journal des transactions est rempli, 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 essayé d'éviter cela en augmentant la taille du fichier journal des transactions dans les propriétés de la base, mais j'ai la même erreur.
Je ne sais pas ce que je devrais essayer ensuite. Le processus s'exécute pendant plusieurs heures, il n'est donc pas facile de jouer par essais et 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. Ce qui suit est ce qui a conduit moi à 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 a tenu 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, libérer l'espace peut nécessiter une autre sauvegarde de journal. Pour plus d'informations, reportez-vous à la section "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 effectivement 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 sur la façon de les déplacer hors de l'état différé, consultez Transactions différées.
Ai-je mal compris quelque chose?
-=-=-=- mise à JOUR 2 -=-=-=-
Vient de lancer le processus avec la taille initiale du fichier journal définie sur 30 Go. Cela va prendre une couple d'heures pour le terminer.
-=-=-=- mise à jour finale-=-=-=-
Le problème a été causé par le fichier journal consommant tout l'espace disque disponible. Dans la dernière tentative, J'ai libéré 120GB et il a toujours utilisé tout cela et a finalement échoué.
Je ne savais pas que cela se passait auparavant parce que quand le processus fonctionnait du jour au lendemain, il reculait sur l'échec. Cette fois, j'ai pu vérifier la taille du fichier journal avant la restauration.
Merci à tous pour votre contribution.
8 réponses
Est-ce un script unique ou un travail régulier?
Dans le passé, pour des projets spéciaux temporairement besoin de beaucoup d'espace pour le fichier journal, j'ai créé un deuxième fichier journal et fait énorme. Une fois le projet terminé, nous avons ensuite supprimé le fichier journal supplémentaire.
Pour résoudre ce problème, modifiez Modèle de Récupération à Simple, puis Shrink Fichiers de Log
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
Fait.
Vérifiez ensuite la taille de votre fichier journal de base de données à Propriétés De La Base De Données > Fichiers > Fichiers De Base De Données > Chemin
Pour vérifier le journal complet de sql server: ouvrez SSMS > base de données > Gestion > journaux SQL Server > Courant
J'ai eu cette erreur Une fois et il a fini par être le disque dur du serveur qui manque d'espace disque.
Avez-vousEnable Autogrowth etcroissance de fichiers sans restriction tous deux activés 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 old school, mais si vous effectuez une opération de mise à jour ou d'insertion itérative dans SQL, quelque chose qui fonctionne depuis longtemps, c'est une bonne idée d'appeler périodiquement (par programmation) "checkpoint". L'appel de" checkpoint " amène SQL à écrire sur le disque toutes ces modifications de mémoire uniquement (pages sales, 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 va tronquer 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 plein et que vous ne disposez pas d'un 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 shrink), et le moteur de base de données SQL Server déclenchera une erreur 9002.
Pour surmonter ce comportement, je vous conseille de vérifier ceci le journal des transactions pour la base de données ‘SharePoint_Config’ est plein en raison de LOG_BACKUP qui montre les étapes détaillées à résoudre question.
J'ai rencontré l'erreur :" le journal des transactions pour 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 à supprimer était supérieur à 1000000 dans mon cas. Donc, au lieu d'utiliser 1 instruction DELETE, j'ai divisé la tâche delete en utilisant DELETE TOP (1000000).... déclaration.
Par exemple:
Au Lieu d'utiliser cette instruction:
DELETE FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())
En utilisant ce qui suit déclaration à plusieurs reprises:
DELETE TOP(1000000) FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())