Discussion :

[Labienus]

Bonjour,

J'ai une croissance forte de mon .mdf après un alter index reorganize inclus dans un plan de maintenance.

Est ce normal?

le DBCC indexdefrag est il plus performant?

Cordialement

Labiénus

[mikedavem]

Une réorganisation ou une reconstruction d'index ?

++

[Labienus]

Bonjour,

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
USE [fmcr_60_mdp_preprod]
 
GO
 
ALTER INDEX [IX_ABSENCES_TYPES] ON [dbo].[ABSENCES_TYPES] REORGANIZE WITH ( LOB_COMPACTION = ON )
 
GO
 
USE [fmcr_60_mdp_preprod]
 
GO
 
ALTER INDEX [PK_ABSENCES_TYPES] ON [dbo].[ABSENCES_TYPES] REORGANIZE WITH ( LOB_COMPACTION = ON )

merci

[mikedavem]

Avez vous des choses en plus dans votre plan ?

Dans le titre vous parlez du fichier .mdf et dans le contenu du poste vous parlez d'un fichier .ndf ... quel fichier grossit exactement ? N'est ce pas plutôt le fichier des transactions (.ldf) ?

++

[Labienus]

re bonjour,

oui, il y a pas mal de steps, en amont, il y a un dbcc shrinkdatabase(s), puis une suppression des .bak antérieurs à 3 jours, puis les sauvegardes de bases.

Re merci

[iberserk]

le DBCC indexdefrag est il plus performant?

->Non. c'est son remplaçant...

Et avec un rebuild? plus intéressant en terme d'espace disque par exemple?

[mikedavem]

Utile le SHRINKDATABASE dans votre cas ? Sachez que cette opération peut tuer vos performances car elle engendre de la fragmentation physique et logique.

Une réorganisation d'index ne s'attaque qu'au niveau feuille de l'index et peut engendrer le grossissement du journal des transactions surtout si votre mode de récupération est FULL. Une reconstruction d'index est plus efficace que la réorganisation d'index dans le sens où elle s'attaque à l'ensemble de l'index mais cette opération engendra plus d'enregistrements dans le journal et le fera le potentiellement plus grossir en fonction du mode de récupération défini sur la base de données.

++

[Labienus]

Bonjour,

Merci de vos retours.
Ce sera donc un 'drop' puis un 'create' index

Cordialement

[iberserk]

Ce sera donc un 'drop' puis un 'create' index

Un rebuild donc...

[dbaffaleuf]

Bonjour,

Merci de vos retours.
Ce sera donc un 'drop' puis un 'create' index

Cordialement

Non il faut utiliser ALTER INDEX REBUILD plutôt que DROP/CREATE ou CREATE with DROP_EXISTING pour plusieurs raisons:
- Si les indexes ont été créés avec une contrainte le DROP INDEX renverra une erreur.
- En droppant la contrainte, on expose la base à une violation (ex duplicates)
- Le drop / create de l'index clustered recréera 2 fois les indexes non clusterisés.

Quant au shrink hebdomadaire c'est une NO-OP dans tous les cas: si tu le fais après le reindex, tu annules tout le bénéfice de la défragmentation, si tu le lances avant, le reindex allouera de nouveau l'espace récupéré par le shrink. Donc ça ne sert à rien. Il vaut mieux avoir une politique avec une enveloppe fixée et monitorer la volumétrie.