Discussion :

[aalaouis]

Bonjour,
La taille du Log de ma base SQL Server2019 dépasse les 300 Giga alors que ma base n'a que 30 Giga, comment pourrais-je réduire la taille du Log (Mode récupération FULL)? sachant que je n'ai plus beaucoup d'espace libre sur le disque?
Merci pour votre aide,

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

ça serait déjà bien de comprendre le mode FULL.
Si vous ne faites jamais de sauvegarde LOG, ça ne sert pas à grand chose au final.

[SQLpro]

Vous devez sauvegarder régulièrement le journal de transaction. Au moins 1 fois par heure tous les jours. Conserver au moins tous les journaux à la fréquence de vos sauvegardes full.
Par exemple si sauvegardes FULL tous les jours alors conserver au plus 48h de journaus de transactions.

Code :

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

1
2
3
 
BACKUP DATABASE ... -->sauvegarde "full"
BACKUP LOG ... --> sauvegarde transactionnelle

Dans votre cas il faudra couper la journal de transaction à environ 15 Go une fois ces sauvegardes effectuées en utilisant l'opération :

Code :

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

DBCC SHRINKFILE (...) --> préciser le fichier du JT avec la taille de 15000 (Mo).

A +

[aalaouis]

Merci pour votre réponse, je fais une sauvegarde FULL par semaine, si je fais une sauvegarde FULL avant d'intervenir et je lance un shrink pour le fichier LOG, je ne risque rien pour la base de PROD?

[Michel.Priori]

je fais une sauvegarde FULL par semaine,

Même sans connaitre vos contraintes de restauration, il me parait contre productif de devoir restaurer la dernière full et l'ensemble des backup log capturés toutes les heures, afin de remonter la base à vendredi 15h37.
Vous devriez penser à intercaler des différentielles par demi journée ou journée.
Du coup la restauration lira le dernier backup full, la dernière différentielle, l'ensemble des journaux ayant été backupés après la différentielle

A moins que les journaux ne vous intéressent pas ; que vous avez juste besoin d'un backup full de temps en temps.
Dans ce cas là il faut faire plusieurs choses :

1. Modifier le mode récupération de Model => simple ; ainsi les prochaines bases de données seront en mode simple
2. modifier le mode de récupération de votre base => simple ; ainsi l'occupation interne du journal sera réduit à la taille de fonctionnement
3. Réduire (shrink) le fichier de log 1 fois et le laisser, par la suite, reprendre sa taille de fonctionnement (ne pas planifier de shrink !)

si je fais une sauvegarde FULL avant d'intervenir et je lance un shrink pour le fichier LOG, je ne risque rien pour la base de PROD?

Quel risque voulez vous couvrir exactement ?

[SQLpro]

...
Vous devriez penser à intercaler des différentielles par demi journée ou journée.
...

C'est une petite base, les différentielles n'ont pas d'intérêt dans ce cas.

A +

[SQLpro]

Merci pour votre réponse, je fais une sauvegarde FULL par semaine, si je fais une sauvegarde FULL avant d'intervenir et je lance un shrink pour le fichier LOG, je ne risque rien pour la base de PROD?

faire un SHRINK n'aura AUCUN EFFET tant que vous ne faites pas de sauvegarde transactionnelles.

1) faire une sauvegarde quotidienne en mode FULL
2) vérifier la sauvegarde FULL (RESTORE VERIFYONLY...)
3) si la sauvegarde vérifié est correcte supprimer les anciennes sauvegardes datant de plusieurs de n jours
4) faire une sauvegarde transactionnelle toutes les heures pendant les heures de production (par exemple 9h 18h)

A +

[aalaouis]

Merci pour votre réponse, je fais une sauvegarde FULL par semaine, si je fais une sauvegarde FULL avant d'intervenir et je lance un shrink pour le fichier LOG, je ne risque rien pour la base de PROD?

Merci beaucoup pour votre aide,

[Michel.Priori]

Bonjour aalaouis,

Afin qu'on puisse vous aider au mieux il nous faut plus d'informations sur les besoins.
Les RPO, RTO ou la justification de la planification actuelle des backups seraient un bon commencement.

Sinon, pour parer au plus pressé, je vous conseille de :
1. Passer la base en mode simple
2. lancer un checkpoint et détacher la base en mettant à jour les stats
3. renommer le fichier de log
4. recréer le fichier de log lors du rattachement (si pb : renommer le fichier de log à l'initial, rattacher la base et recommencer l'étape 2)
5. la remettre en mode complet