Mon fichier journal dans SQL Server a utilisé tout l'espace sur mon disque. J'effectue des sauvegardes complètes chaque nuit, mais le fichier journal ne cesse de croître. Que puis-je faire?Mon fichier journal est trop volumineux
Sur la plupart des systèmes occupés, vous devez planifier la sauvegarde des journaux tout au long de la journée, puis la sauvegarde complète de nuit. C'est une pratique assez courante.
Supprimer le fichier journal? Editer: Apparemment, la suppression du fichier journal est mauvaise, c'est juste juste un journal au serveur SQL. Je laisse cela pour réitérer ce qu'il ne faut pas faire.
Supprimer le fichier journal serait vraiment mauvais pour un serveur SQL ... Il contient les informations à récupérer à partir d'une erreur matérielle. –
Vous pouvez utiliser une sorte de rotation de journal, et conserver uniquement un journal d'une durée fixe, par exemple les 7 derniers jours. Cela devrait être plus que suffisant. Ou vous pouvez réinitialiser le journal chaque nuit, car vous devriez l'avoir dans votre sauvegarde.
Vous avez sauvegarder vos journaux ainsi que la base de données principale
Cela devrait rétrécir:
dbcc shrinkfile('databasename_log', 0)
essayez ceci:
dump transaction <dbname> with no_log
puis réduire le fichier journal en définissant l'option autoshrink dans les paramètres du serveur SQL ou par.
Je pense que vous pouvez utiliser dbcc pour le réduire aussi, mais je ne me souviens pas de la syntaxe.
Si vous avez un travail planifié pour effectuer des sauvegardes complètes, cela est bon et devrait être votre point de départ, mais vous devez également effectuer régulièrement des sauvegardes du journal des transactions.
La sauvegarde du journal des transactions entraîne le retrait de l'espace. Une fois que vous avez défini votre calendrier de sauvegarde du journal des transactions, vous serez probablement en mesure d'envisager de réduire le journal des transactions à une taille plus appropriée. Comme il ne va plus croître indéfiniment.
La stratégie de sauvegarde pour une restauration complète se compose de:
* Database backups.
* Differential backups (optional).
* Transaction log backups.
Je vous suggère de consulter la référence Microsoft suivant. Dans certains cas,
http://msdn.microsoft.com/en-us/library/aa173551(SQL.80).aspx
vous pourriez trouver le fichier journal ne tronque pas correctement, même si une sauvegarde du journal est exécuté. Vous pouvez faire une sauvegarde avec TRUNCATE_ONLY pour le vérifier. Lorsque vous exécutez cela, il doit tronquer le journal des transactions:
BACKUP LOG dbname WITH TRUNCATE_ONLY
La cause de ce problème est une transaction ouverte dans une première partie du journal. SQL ne tronquera pas le journal après cette transaction, ce qui risque de générer un journal de plus en plus volumineux. Vous devez savoir quelles transactions restent ouvertes et pourquoi.Vous pouvez surveiller votre espace de journal avec:
DBCC SQLPERF (LOGSPACE)
Informations sur les longues opérations en cours d'exécution peut être trouvée en utilisant:
DBCC OPENTRAN
Ou:
select * from sys.dm_tran_database_transactions
Bonjour, gardez à l'esprit que l'utilisation de l'option WITH TRUNCATE_ONLY ne sauvegardera pas réellement le journal des transactions. Vous perdrez la possibilité de restaurer à un moment donné et devriez donc immédiatement suivre cette action avec une sauvegarde complète, une fois que les problèmes du journal des transactions seront résolus. –
Il est préférable d'ajouter des sauvegardes du journal des transactions à votre horaire.
BACKUP LOG database TO DISK = 'D:/database_log.bak'
Gardez à l'esprit que dans les modèles de récupération complète ou journalisées en bloc journal des transactions est tronquée lors de la sauvegarde du journal des transactions est fait, il est nécessaire de sauvegarder le journal régulièrement afin de gérer la taille de la transaction bûche. Sinon, le fichier journal des transactions va augmenter jusqu'à ce qu'il n'y ait plus d'espace disponible.
Si la récupération ponctuelle n'est pas nécessaire et que les modifications de la base de données sont peu fréquentes, il est préférable d'utiliser un modèle de récupération simple (sans journaux de transactions). Dans ce cas, le journal des transactions est automatiquement tronqué pour supprimer les fichiers journaux virtuels inactifs. Dans le modèle de récupération simple, la troncation du journal des transactions a lieu après chaque point de contrôle.
Ceci est une question d'administration DB. Pas une question de programmation. – EBGreen
Je pense qu'il devrait rester ouvert, de nombreuses petites entreprises les programmeurs doivent agir en tant qu'administrateurs DB. –
En effet. Certaines personnes sont un peu trop «proches» :) –