Discussion :

[orafrance]

Bonjour,

comme probablement tous les DBA SQL sur cette terre, ça m'agace prodigieusement d'avoir une erreur aussi bête que "transaction log is full".

J'essaye donc de trouver des solutions sachant que j'ai pas nécessairement du disque à foison (en fait si mais je veux être plus intelligent que mettre 100 Go pour une base de 100 Mo backupée 3 fois par jour ) et que j'ai pas toutes mes nuits et week-ends à passer sur le monitoring pour savoir si j'ai un souci de backup et/ou de journal de transactions.

J'avais donc pensé créer un deuxième fichier log et envoyer une alerte quand le premier se rempli, me laissant le temps de régler le problème tranquillement et réduire ensuite sereinement la taille du 2eme fichier log. Sauf que visiblement, si on a 2 fichiers logs cette idiot de SQL Server qui veut absolument optimiser les perfs parallélise les écritures. C'est parfait quand on s'inquiète des perfs mais pour le coup ça m'aide pas moi

Trève de plaisanterie, y a-t-il une autre manière de gérer le souci de fichier log plein que de le déplacer sur un disque plus gros à chaque fois qu'il le fait exploser ? Y a-t-il moyen de forcer l'utilisation séquentielle des fichiers (quand le 1er est plein, il utilise le deuxième et pas avant) ?

Merci de votre aide

[SQLpro]

1) tu peut faire un BACKUP LOG ... WITH TRUNCATE ONLY (plus supporté en 2008
2) tu peut mettre une alerte de l'agent si le pourcentage de remplissage du JT est supérieur à x% de la taille prédéfinie du JT. Par exemple tu le taille à 100 Go et tu met une alerte à 80
3) tu peut automatiser l'alerte pour quelle exécute une tache de sauvegarde du JT
4) pour passer d'un fichier à l'autre il faut fermer la base ou re démarrer l'instance (je ne sais plus, à tester) Il ne //lélise pas sur le JT !

A +

[mikedavem]

Bonsoir orafrance,

Sauf que visiblement, si on a 2 fichiers logs cette idiot de SQL Server qui veut absolument optimiser les perfs parallélise les écritures.

Les enregistrements dans le journal s'effectuent de manière séquentielle. Cela m'étonnerait que SQL Server parallélise les écritures sur ce genre de fichier.

++

[orafrance]

Les enregistrements dans le journal s'effectuent de manière séquentielle. Cela m'étonnerait que SQL Server parallélise les écritures sur ce genre de fichier.

j'ai fait le test, et il parallélise bien les écritures. Visiblement, il écrit un coup dans l'un, un coup dans l'autre. Et évidemment, jamais il ne rempli le premier (qui serait sans autogrow pour déclencher une alerte).

[orafrance]

1) tu peut faire un BACKUP LOG ... WITH TRUNCATE ONLY (plus supporté en 2008
2) tu peut mettre une alerte de l'agent si le pourcentage de remplissage du JT est supérieur à x% de la taille prédéfinie du JT. Par exemple tu le taille à 100 Go et tu met une alerte à 80
3) tu peut automatiser l'alerte pour quelle exécute une tache de sauvegarde du JT
4) pour passer d'un fichier à l'autre il faut fermer la base ou re démarrer l'instance (je ne sais plus, à tester) Il ne //lélise pas sur le JT !

A +

1) c'est pas terrible pour les backups et en mirroir c'est carrément pas possible
2) sauf que j'ai plusieurs fichiers sur le même disque et une telle alerte ne saurait régler le souci (tu peux avoir 10 fichiers à 50% mais le dur qui est plein)
3) oui mais si le log se rempli c'est souvent parce que le backup ne fonctionne pas justement. Et un faire un backup local ça ne m'arrange pas pour la gestion de DPM
4) pas possible d'arrêter l'instance