Discussion :

[vinch999]

Bonjour,

Voici ma question :
Lors d'un backup différentiel ou full, est-ce que l'on peut/doit constater une montée importante de l'utilisation du fichier transaction log?

La raison de ma question est que le log transactionnel gonfle énormément par moment, parfois jusqu'à saturation et donc crash .
Je soupçonne les backup d'être potentiellement responsables de ce problème.

Le volume de ma db est d'environ 5 To.
Le fichier de log transactionnel est de 250 Go.
recovery model : simple

Merci d'avance pour les infos.

[SQLpro]

Si vous êtes en mode simple oui.

• En effet le processus de sauvegarde FULL ou DIFFERENTIAL, commence par poser un point d'arrêt dans le journal pour signaler l'opération de sauvegarde en cours.
• Puis, il y a copie binaire de chaque page de la base
• Enfin, il y a copie de la portion du JT depuis le point d'arrêt jusqu'à la fin du journal.

Si votre sauvegarde dure 2 heures aucun recyclage du JT n'est possible, pendant les 2 heures que va durer la sauvegarde, sinon vous perdriez les transactions, la sauvegarde deviendrait incohérente et il ne serait pas possible de restaurer !

Pourquoi êtes vous en mode simple ? Quel est le but de votre base de données ? A quoi sert-elle ? Est-ce une base décisionnelle ? ou transactionnelle ?
Parce que je soupçonne une mauvaise utilisation, soit de la sauvegarde soit pire, du mode de journalisation....

A +

[Boubou2020]

vous été en mode du récupération simple dans ce mode, le commit du transaction est sous la responsabilité du checkpoint
le checkpoint supprime les transactions validées du journal sans les sauvegarder
Le but du journal de transaction en mode simple est de garantir la cohérence et l’intégrité des données
SI vous été en mode de récupération simple et pourtant la taille du fichier de transaction grossissait, la solution est essayer de bien redimensionner correctement la taille du fichier et d’effectuer des Checkpoints plus réguliers.
de plus essayer de voir si vous avez toujour des transaction ouvert qui atteint une opération de type commit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC opentran

[vinch999]

Merci pour les infos je comprends mieux le pourquoi.

Je ne suis pas la personne en charge de la stratégie de backup.
C'est une base transactionnelle.
J'ignore le pourquoi du choix du mode simple recovery.
Le backup différentiel à lieu +- au moment où commencent beaucoup d'écritures. Je vais déjà dans un premier temps faire déplacer le backup à un moment où c'est plus calme afin de voir comment ça se comporte.

[SQLpro]

Merci pour les infos je comprends mieux le pourquoi.

Je ne suis pas la personne en charge de la stratégie de backup.
C'est une base transactionnelle.
J'ignore le pourquoi du choix du mode simple recovery.
Le backup différentiel à lieu +- au moment où commencent beaucoup d'écritures. Je vais déjà dans un premier temps faire déplacer le backup à un moment où c'est plus calme afin de voir comment ça se comporte.

C'est un peu suicidaire de mettre une base transactionnelle en mode simple ! En cas de défaillance par exemple du stockage, vous devrez repartir de la dernière sauvegarde, alors qu'en mode FULL, vous pouvez reconstituez :
- l'intégralité de la base jusqu'à l'ultime transaction, grâce à une sauvegarde en mode d'urgence du journal de transaction s'il est encore lisible
- la dernière minute d'enregistrement des données en sauvegardant la base en mode d'urgence (si le journal n'est pas lisible)

En sus, le mode FULL permet de reconstituer la base avec arrêt dans le temps à partir des journaux de transactions (PITR). Par exemple si quelqu'un à supprimé des données par erreur à 11h27, alors restaurer la base à côté avec un STOPAT 11h26, permettra de récupérer les données manquantes...

A +

[vinch999]

Oui en effet je sais bien c'est risqué.
Je ne sais pas pourquoi ils n'ont pas mis en mode FULL. Surement une question de coût de maintenance...
Sans tenir compte du coût de la perte de données