Version imprimable
Bonjour,
J'ai un soucis avec un journal de log qui sature.
Dans un premier temps j'ai fais :
-- BACKUP LOG toto WITH TRUNCATE_ONLY
-- puis DBCC SHRINKFILE du fichier de log
-- passer la base en mode de récup simple !
-- arret et redemarage de l'instance...
Le résultat est qu'effectivement j'ai bien reduit je journal, mais celui ci recommence à grossir, grossir, grossir...
Que dois je vérifier ? Quel type de transaction peu générer ce problème ? Je suis paumée là...
Bonjour,
- BACKUP LOG toto WITH TRUNCATE_ONLY : ne faites JAMAIS cela.
Sinon vous coupez la séquence de chaîne de sauvegarde du fichier du journal des transactions, seul garant de l'intégrité de votre base de données !
- DBCC SHRINKFILE du fichier de log : idem : à ne réserver qu'aux manœuvres d'urgence, par manque d'espace disque : SQL Server s'échine à prendre de l'espace disque que vous lui enlevez, et qu'il reprendra tôt ou tard.
Sachant qu'un accès disques est au moins 1000 fois plus coûteux qu'un accès en RAM, je vous laisse imaginer les dégâts que cela peut causer sur les performances de vos requêtes ...
- passer la base en mode de récup simple : il faut d'abord voir si cela correspond aux requis du métier de votre entreprise ... quelle quantité de données pouvez-vous vous "permettre" de perdre ?
- arret et redemarage de l'instance : en faisant cela vous perdez tout le cache de données et de procédures.
Donc pour toute nouvelle requête exécutée après le redémarrage, il y a recompilation du plan de requête, coûteux en CPU ...
Si vous êtes en mode de récupération FULL, pensez à sauvegarder le fichier du journal des transactions régulièrement : c'est cela qui lui évitera de gonfler.
Si vous êtes en mode de récupération SIMPLE et que le journal gonfle, c'est que vous êtes en train de modifier une quantité de données élevée dans une transaction.
Voyez à procéder par lots si cela pose problème.
A lire ;)
@++ ;)
Est ce que celui grossit tout le temps ? A des heures pré déterminés ?Citation:
Envoyé par Liloye
Regardez si du coté des transactions importantes générant une grosse quantité de données ou des opérations de maintenance.
++
Oui oui, je sais... J'ai effectué ces manips que pour ne pas exploser le disque qui était vraiment à saturation et récuperer de l'espace !
D'autre part, je suis passée en mode simple car aucune sauvegarde des journaux n'étaient effectués entre 2 sauvegardes complètes...
En revanche je n'arrive toujours pas à comprendre comment une base qui 2 Go arrive à 5 Go en moins d'une journée !?
Autre chose, est ce que l'option "auto shrink" pourrait répondre à mon problème ? et est ce que cette option n'est pas aussi dangereuse qu'un "SHRINKFILE " ?
Dans ce cas restez en mode FULL et faites des sauvegardes du fichier du journal des transactions plus fréquemment.Citation:
D'autre part, je suis passée en mode simple car aucune sauvegarde des journaux n'étaient effectués entre 2 sauvegardes complètes...
La quantité de données que stocke votre base de données est de 2Go.Citation:
En revanche je n'arrive toujours pas à comprendre comment une base qui 2 Go arrive à 5 Go en moins d'une journée !?
Dans le mode de récupération FULL, le fichier du journal des transactions enregistre toutes les informations nécessaires à défaire ou refaire une transaction (il les écrit d'abord avant de procéder aux modifications de données à proprement dites).
Si donc vous avez une table qui est mise à jour toutes les secondes, même si son nombre de lignes est faible, le fichier du journal des transactions, lui, va continuer de grossir.
Elle n'est pas aussi dangereuse, elle est encore plus dangereuse, parce que dans ce cas-là vous allez réduire aussi le fichier de données de votre base de données, et comme je vous l'ai expliqué dans ma précédente réponse, cela est inutile en plus d'être très contre-performant.Citation:
Autre chose, est ce que l'option "auto shrink" pourrait répondre à mon problème ? et est ce que cette option n'est pas aussi dangereuse qu'un "SHRINKFILE " ?
Choisissez le mode de récupération qui est adapté à votre application ;)
Décrivez-nous ce que fait votre application, et quelle quantité ("temps de données") vous pouvez vous permettre de perdre.
@++ ;)