Discussion :

[ermips]

Bonjour,
je ne comprends pas pourquoi la taille de la première sauvegarde du journal de transaction après une sauvegarde complète est pratiquement équivalente à la taille de la base elle même.

Ce comportement est-il "normal" ?

Le serveur est un SQLSERVER 2008 SP2

[krousty]

Bonjour,

Oui c'est normal , une sauvegarde complète ne vide pas les journaux de transaction.

cette discutions vous aidera peut être :
http://www.developpez.net/forums/d11...ion-sqlserver/

Cordialement,

[ermips]

mais là on dirait que la sauvegarde remplit le journal des transactions.
La somme des journaux de transaction d'une journée est bien moins importante que cette sauvegarde du journal juste après la sauvegarde complète.
La sauvegarde complète génère des transactions ?

[mikedavem]

Effectivement si vous êtes en mode de récupération complet ou bulk-logged il vous faudra sauvegarder le journal pour pouvoir le vider.

++

[dbaffaleuf]

mais là on dirait que la sauvegarde remplit le journal des transactions.
La somme des journaux de transaction d'une journée est bien moins importante que cette sauvegarde du journal juste après la sauvegarde complète.
La sauvegarde complète génère des transactions ?

Elle génère un checkpoint en début de backup, qui est loggé effectivement mais ça ne représente que deux log records. Quel est le mode de récupération des transactions sur cette base ?

Code :

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

1
2
select databasepropertyex('<mabase','recovery')
GO

Et lancer entre le backup full et le backup log (volumineux):

Code :

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

1
2
dbcc sqlperf(logspace)
GO

De quelle base s'agit-il ?

[ermips]

Les sauvegardes sont organisées de cette façon :
Un plan de maintenance FULL BACKUP de la base à 22h
Une sauvegardes des journaux de transaction toutes les heures

et donc la sauvegarde du journal des transactions à 23h (la première du journal des transactions après Full backup) fait pratiquement la taille de la base
puis décroit à la sauvegarde d'après (On passe de 20 Go à quelques Mo)

[mikedavem]

Est-ce que tu n'as pas une tâche de maintenance de type reconstruction d'index qui tournerait avant le backup full ?

A+

[ermips]

Effectivement, après la sauvegarde de la base il y une reconstruction d'index

[mikedavem]

C'est ta reconstruction d'index qui fait augmenter la volumétrie de ton journal dans ton cas. Si tu utilises les plans de maintenance de SQL Server, la tâche de reconstruction d'index s'attaque à tous les index de ta base sans se préoccuper de leur fragmentation. Donc plus ta base prendra du volume en taille ou en nombre d'objets plus tu as de chance de voir ton journal grossir après reconstruction de ces indexes.

Tu peux donc créer ton propre script de réindexation qui regarde au préalable la fragmentation de tes index et qui opère uniquement sur ceux qui le nécessitent vraiment.

++

[ermips]

Je ne vois pas trop comment optimiser la défragmentation.
L' objectif de la diminution de la taille de la sauvegarde du fichier de transaction est d'améliorer la restauration de la base. Je vais peut être envisager de diminuer la fréquence de la défragmentation des index

[elsuket]

Bonjour,

la requête que j'ai publié ici peut vous y aider. Voyez également l'article de SQLPro sur le sujet

J'ai écrit une procédure plus récemment qui liste les index en fonction de leur fragmentation et de leur utilisation : les plus recherchés et les plus fragmentés sont défragmentés les premiers, étant donné que je ne peux les défragmenter que dans une fenêtre de maintenance bien précise. Enjoy

@++

[ermips]

Merci, pour les infos et les scripts : il y a un peu de lecture avant avant de mettre en pratique...

Je me pose une question en cas de mise en miroir de la base : est ce que ça ça veut dire que l'on ne peut pas utiliser la défragmentation des index par défaut puisqu'on se retrouve avec un fichier de transaction de la taille de la base ?

[iberserk]

Vous voulez parler du log shipping?

[dbaffaleuf]

Merci, pour les infos et les scripts : il y a un peu de lecture avant avant de mettre en pratique...

Je me pose une question en cas de mise en miroir de la base : est ce que ça ça veut dire que l'on ne peut pas utiliser la défragmentation des index par défaut puisqu'on se retrouve avec un fichier de transaction de la taille de la base ?

Dans une session de miroir les deux bases partenaires doivent être en mode de récupération FULL, donc ça n'empêche pas de reconstruire les indexes, simplement l'opération sera loggée entièrement. La solution de passer en mode BULK_LOGGED sans casser la chaîne de backup n'est pas possible dans une session de miroir car le mode de récupération est nécessairement FULL.

[mikedavem]

D'où la nécessite de minimiser l'impact de cette opération sur le journal à ce qui doit être réellement reconstruit ou réorganisé :-)

++