Discussion :

[voyageur]

J'ai une table avec 20 millions de lignes au depart sur laquelle j'ai fais ces traitements :
- select count(*) --> durée 1 minute, normal
- delete de 1 millions de lignes ---> durée 5 minutes, normal
- select count(*) --> interminable toujours en execution aprés 1 heure !!

La table a juste une clé primaire.

La cause est evidemment le delete en masse, mais je ne comprend pas pourquoi ?

[SQLpro]

Fragmentation de l'index...

Commencez par défragmenter les index de cette table.

Pour visualiser la fragmentation des index de cette table utilisez la commande DBCC SHOWCONTIG.

A +

[voyageur]

Fragmentation de l'index...

Commencez par défragmenter les index de cette table.

Pour visualiser la fragmentation des index de cette table utilisez la commande DBCC SHOWCONTIG.

A +

voici le resultat :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Table: 'MaTable' (1982630106); index ID: 1, database ID: 41
TABLE level scan performed.
- Pages Scanned................................: 1111028
- Extents Scanned..............................: 142713
- Extent Switches..............................: 188459
- Avg. Pages per Extent........................: 7.8
- Scan Density [Best Count:Actual Count].......: 73.69% [138879:188460]
- Logical Scan Fragmentation ..................: 68.81%
- Extent Scan Fragmentation ...................: 9.77%
- Avg. Bytes Free per Page.....................: 838.2
- Avg. Page Density (full).....................: 89.64%

[Babyneedle]

- Logical Scan Fragmentation ..................: 68.81%
- Extent Scan Fragmentation ...................: 9.77%

Yikes!

Essaye

Code :

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

DBCC DBREINDEX ('maTable')

et ensuite revérifie si la fragmentation a diminué.

*ATTENTION* ça peut prendre du temps! Ne pas faire sur une table en production!

En passant, quel est fill factor de tes index?

S'il y a beaucoup d'inserts et deletes sur la table, il faudra réduire le fill factor. Il faudra aussi scéduler des reindex de façon régulière.

[voyageur]

Effectivement j'ai utilisé DBCC REINDEX mais le temps d'execution est colossale, depuis hier deja 17 heures en execution est toujours pas fini !!!

Comment faire dans ce cas ?
La base contient des tables ou il y a autant d'operation d'ecritures que d'operation de lecture, pensez vous que changer le fill factor soit benefique ?

Pour l'instant je travaille en environenment de dév ( meme volumetrie que celle en production ), mais je pensais faire un script regulier de recréation d'index sur les tables mais si ca met autant de temps ca ne va pas etre possible de faire ca en production !!

Quelle strategie me conseillez vous ?

[elsuket]

bonjour,

Si tu es sous SQL Server 2005, tu peux utiliser la commande ALTER INDEX avec ses options pour défragmenter et eventuellement changer le FILLFACTOR de tes indexes.
De plus la commande ALTER INDEX n'est pas bloquante comme une commande DBCC. Regarde la documentation sur l'option ONLINE de la commande ALTER INDEX.

Si tu fais un SELECT COUNT(*) alors que ton DELETE n'est pas encore terminé, il est normal que tu n'aies pas le résultat du SELECT COUNT(*).
Tu peux utiliser la vue système sys.sysindexes (avec indid = 1 (index cluster), rowcnt, et id = OBJECT_ID('MA_TABLE')) pour savoir combien de lignes sont dans ta table, c'est beaucoup plus rapide que d'utiliser la commande SELECT COUNT(*) . Tu peux également y sélectionner OrigFillFactor pour connaître la valeur du FillFactor la dernière fois qu'il a été (re)construit.