Version imprimable
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,
ç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.
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.
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:
2
3
A +Code:DBCC SHRINKFILE (...) --> préciser le fichier du JT avec la taille de 15000 (Mo).
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?
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.Citation:
Envoyé par aalaouis
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 :
- Modifier le mode récupération de Model => simple ; ainsi les prochaines bases de données seront en mode simple
- modifier le mode de récupération de votre base => simple ; ainsi l'occupation interne du journal sera réduit à la taille de fonctionnement
- 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 !)
Quel risque voulez vous couvrir exactement ?Citation:
Envoyé par aalaouis
faire un SHRINK n'aura AUCUN EFFET tant que vous ne faites pas de sauvegarde transactionnelles.Citation:
Envoyé par aalaouis
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 +
C'est une petite base, les différentielles n'ont pas d'intérêt dans ce cas.Citation:
Envoyé par Michel.Priori
A +
Pas faux ; 30 Go ce n'est pas une "grosse base"Citation:
Envoyé par SQLpro
Par contre on ne sait pas en combien de temps le journal a atteint 300 Go.
Ce peut être une petite base avec plein d'update sur un petit nombre de pages créant ainsi un point chaud.
Ou pas.
On ne connait pas non plus les RPO et RTO.
Le mode simple est peut être adapté ...
Faudrait que aalaouis se manifeste et nous en dise plus ;)
Merci beaucoup pour votre aide,Citation:
Envoyé par aalaouis
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