Discussion :

[Pol63]

bonjour

backup database ne vide pas mon log, il était à 8Go récemment (en meme pas 1 mois) après le backup et en passant par le menu diminuer les fichiers, il est tombé à 6Go (pas top)

dans l'aide ils disent que normalement l'espace occupé doit descendre et qu'une réduction de la taille peut ensuite etre effectuée, sinon c'est qu'il y a des liaisons qui restent ...
bref je vois pas trop
et leur système de journalisation est pas très clair malgré des heures de lecture sur ce sujet
enfin ca ne m'a appris quoi faire en cas de crash et comment et grace à quoi la base se reconstitue, donc ca n'aide pas à comprendre le reste ...

[elsuket]

Bonjour,

Si votre base de données est en mode de restauration complet, alors vous devez régulièrement effectuer un backup du log de transaction.
Vous pouvez par exemple effectuer un backup complet tous les jours, puis un backup de log toutes les heures, de façon à créer un chaînage complet de la vie de votre BD.
Les logs de transaction qui ont été sauvegardés avant votre dernier backup complet avec l'option WITH INIT ne serviront plus à restaurer votre base de données jusqu'à peu de temps avant un crash.
Si un crash se produit, alors vous devrez effectuer une sauvegarde de votre log de transaction tel quel, puis restaurer votre backup complet, puis vos log de transaction dans l'ordre de leur création, puis ce dernier log de transaction avec l'option WITH STOP AT.
Vous devez utiliser ce mode si vous ne pouvez pas vous permettre de perdre des données, par exemple sur une base OLTP.

Il en va tout à fait différemment si votre base de données est en mode de restauration simple : en effet dans ce mode, la troncation du journal se fait automatiquement après chaque point de contrôle (CHECKPOINT), par défaut défini à une minute (vous pouvez cependant le redéfinir avec la procédure stockée système sp_configure, option "recovery interval"). Le journal de transaction n'est donc jamais sauvegardé, et vous ne pouvez vous fier qu'à votre dernier backup complet pour la restaurer. Cela convient parfaitement aux bases de données en lecture seule.

Dans tous les cas, c'est le processus LAZYWRITER qui épluche quelles pages ont été modifiées avant de les écrire dans le fichier de données. Vous pouvez forcer le moteur de base de données à écrire les pages modifiées avec la commande CHECKPOINT. SQLPro a écrit un article à ce sujet (section II-D).

Mais avant de faire cela, vous devez rechercher quel facteur retarde la troncation du journal de transactions : vous pouvez le savoir en requêtant la vue système sys.databases, dans la colonne log_reuse_wait_desc. L'un de ces facteurs est, entre autres, les transactions longues.

Vous pouvez regarder ce qui retarde la troncation de votre journal de transaction ici

Quelle taille occupe votre base de données ? On peut raisonnablement consacrer jusqu'à 1/3 du volume de données à la taille du journal de transactions.
De plus vous ne gagnerez rien à faire rétrécir celui-ci : si SQL Server l'a fait grossir, c'est qu'il a eu besoin de cet espace, et qu'il le reprendra tôt ou tard, et devra donc réallouer de l'espace sur le disque dur, une opération lente ...

[Pol63]

très interressant l'article de SQLpro (j'attends la suite avec impatiente)
et tellement vrai

pour ma base client log_reuse est sur LOG_BACKUP
je vais me pencher la dessus voir si j'arrive à m'en dépatouiller et mettre en place un genre de plan de maintenance (aucune sauvegarde n'est programmée encore ...)

la base doit faire moins d'1Go de données (installée depuis 2mois)

[elsuket]

Bonjour,

Donc comme vous avez "LOG_BACKUP", votre BD doit très probablement être en mode de récupération complet et attend un backup de log

un genre de plan de maintenance (aucune sauvegarde n'est programmée encore ...)

Vous pouvez aussi faire cela avec un petit job et une procédure stockée

la base doit faire moins d'1Go de données (installée depuis 2mois)

Je ne vois pas le rapport entre la taille de la base de données et le temps depuis laquelle elle se trouve en production ...

[SQLpro]

Ce que je pense c'est qu'il y a peut être une transaction qui dure depuis très longtemps, ou biens des transactions mal écrite (sans COMMIT).

Dans ce cas il faudrait savoir quelle sont les transactions les plus longues. Je n'ai pas de 2005 sous la main (des requêtes pourrait voud montrer la chose), mais il y avait une commande DBCC OPENTRAN qui permet de voir cela.

En effet, une transaction non achevée oblige le journal a ne pas se tronquer.

A +

[elsuket]

Bonsoir,

la colonne log_reuse_wait_desc n'est pas à "ACTIVE_TRANSACTION" dans ce cas ?

[Pol63]

Je ne vois pas le rapport entre la taille de la base de données et le temps depuis laquelle elle se trouve en production ...

j'ai jamais dit qu'il y en avait un, c'était pour dire que c'était une base depuis en exploitation alors qu'on ne sait pas faire des sauvegarde encore


sinon pas de transaction ouverte mais j'ai pas eut le temps de regarder encore pour les sauvegardes