Version imprimable
bonjour a tous
Une petit Question pour nos experts SQL server
Si mon Base est en mode de récupération compléte
et j'ai pas un backup régulier pour purgées du journal à intervalles réguliers et je suis devant un phénomène de saturation du log
Est ce que la lancement manuel d'opération "checkpoint" peut vider le contenu du log
ou je doit lancer l'opération recommandé backup log + DBCC SHRINKFILE
n'hésitez pas à me corriger si je dit des bêtise
merci pour vos remarques
Ben pourquoi garder un mode de récupération complet quand on ne fait pas les backups du LOG ? Le problème est plutôt là !Citation:
Envoyé par NULL008
Changer le mode à SIMPLE à ce moment.
C'est comme choisir du diesel alors qu'on a une voiture à essence, y a comme un truc qui n'est pas cohérent !
merci bien pour votre réponse
vu que je suis débutant et loin d’être expert
je pause une autre Question su le même piste
si on parle de saturation du Fichier log
s'agit'il d'une saturation phyisque (occupation total d'espace disque) ou on parle d'une saturation logique taille du fichier journal occupé a 100%
merci
Le journal de transactions sous SQL Server est composé / découpé logiquement de fichiers virtuels (VLF).
Lorsque ceux-ci se remplissent c'est bien l'espace physique correspond qui est occupé. Un VLF peut être actif ou inactif et dans le dernier cas les données présentes seront écrasées physiquement par d'autres enregistrements.
Lorsqu'on dit qu'un fichier journal est saturé c'est que tous les VLF qui le composent sont actifs et ne peuvent plus être réutilisés par SQL Server tant qu'un checkpoint / backup log / réplication soit effectué. Dans ce cas tu as plusieurs choix possibles:
- tu as de la place et l'expansion de fichier est autorisé (autogrow). Dans ce cas SQL Server étendra physiquement le fichier avec de nouveaux VLFs
- tu n'as plus de place ou l'autogrow n'est pas autorisée et tu auras une erreur stipulant que tu ne peux plus écrire dans le journal des transactions correspond
++
Non ! Absolument pas... Extrait de notre livreCitation:
Envoyé par NULL008
Pièce jointe 209806 :
Écriture des données
Lors de l’envoi de la commande CHECKPOINT (effectuée automatiquement à intervalle régulier, environ
toutes les minutes), le système parcourt la mémoire à la recherche des pages sales, qui contiennent
donc les nouvelles données à écrire. Il les regroupe par contiguïtés des emplacements physiques sur les
plateaux du disque et les écrit dans les fichiers de données, ceci afin d’optimiser la durée du processus.
• Si une page mémoire a été modifiée plusieurs fois entre deux commandes CHECKPOINT, une seule écriture
physique sera effectuée.
• Le regroupement par contiguïtés des emplacements physiques sur les plateaux du disque permet de
minimiser le trajet de la tête de lecture.
Une fois que les pages sales ont été définitivement répercutées dans les fichiers de données, les transactions
inscrites au journal et concernant ces pages sont marquées comme terminées et la place qu’elles
occupent dans le journal peut être libérée.
Peut être libéré ne veut pas dire est libéré...OUI ! Il existe un autre moyen, beaucoup plus dégueulasse (tant qu'a faire de la merde, n'hésitez pas...) qui consiste à passer alternativement du mode de récupération FULL au mode SIMPLE.... et de faire un SHRINK.Citation:
ou je doit lancer l'opération recommandé backup log + DBCC SHRINKFILE
De toute façons dans les deux cas faire un SHRINK est une imbécilité ! C'est une opération d'urgence, pas une opération à planifier !
Dire, non, faire, oui !Citation:
n'hésitez pas à me corriger si je dit des bêtise
merci pour vos remarques
A +
