Discussion :

[slefevre01]

Bonjour,
A priori (en sql2000), il n'est pas possible de défragmenter une table avec des champ Image (LOB) en reconstruisant l'index cluster sur celle-ci. Ce n'est pas spécifié dans la documentation sqlserver (ca m'aurait éviter de perdre du temps si ca l'avait était)

J'ai plusieurs tables de commerceserver2002 très fragmentées, exemple:
sp_spaceused:
table: OrderGroup
rows: 474802
reserved: 6121616 KB
data: 1136416 KB
index_size: 49064 KB
unused: 4936136 KB

La base fait 40Go, dont 20Go en "unused".
Hormis le fait que ce prend de la place inutilement, ca rallonge les temps de backups, et doit sûrement dégrader les performances car les tables sont très fragmentées.

Je voulais savoir si vous êtes confronté à ce genre de problème.
Et quelle solution vous avez apportée ?

L'ultime solution serait d'exporter les tables dans des tables temporaires, de dropper (ou tronquer) celles-ci avant de réimporter, mais c'est très lourd car les tables comportent beaucoup de contraintes et FK, et c'est une application est utilisée en 24/24h 7/7j.

Ou alors migrer en sql2005 (sous condition que CS2002 est validé avec sql2005), car il me semble que cette option de rebuild a été ajouté pour les champs LOBS.

Par avance merci,

Sébastien

[SQLpro]

Hormis le fait que ce prend de la place inutilement, ca rallonge les temps de backups, et doit sûrement dégrader les performances car les tables sont très fragmentées.

les backup ne prennent pas en compte les pages vides !
Comment savez vous si les tables sont fragmentées sans avoir lancées les commandes adéquates pour le savoir comme DBCC SHOWCONTIG ou encore dm_db_index_physical_stats ???

A +

[slefevre01]

Bonjour,

Le backup fait 38Go, la base (mdf) 40Go.
J'ai fait un sp_spaceused (après dbcc updateusage) sur l'ensemble des tables, et je me suis apercu que 5 tables avaient une taille d'unused très élevé. (au total , 20 Go unused)

J'ai fait des showcontig avant, après reindex, et constaté que l'EXtendScanFragmentation était élevé. (50% après dbcc dbreindex)

DBCC SHOWCONTIG scanning 'OrderGroup' table...
Table: 'OrderGroup' (2089058478); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned................................: 13721
- Extents Scanned..............................: 1721
- Extent Switches..............................: 1720
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.71% [1716:1721]
- Logical Scan Fragmentation ..................: 0.00%
- Extent Scan Fragmentation ...................: 43.11%
- Avg. Bytes Free per Page.....................: 697.3
- Avg. Page Density (full).....................: 91.38%

Point commun entre ces tables, un champ Image.

Sur les tables qui avaient un unused élevé mais SANS champ Image, la création d'un index cluster a permis de ramener l'unused à presque zero. C'est pas le cas pour mes 5 tables.

Après, je me suis dit que l'unused était peut-être utilisé pour stocker ces fameuses données binaires. J'ai donc fait un export de cette table dans une base du même serveur avec l'outil import/export d'objets, puis recréér les mêmes index, et là, je constate que l'unused fait 20000 Ko contre 4936208 KB sur la table d'origne.

Donc pour l'instant je reste sur l'idée que les données sont fragmentées.
Ou alors, il s'agit d'un bug dans la gestion des pages. le serveur est en SQL2000sp4, et j'ai testé sur un autre sql2000sp3a, c'est pareil.

Merci d'avance pour votre aide

Sebastien

[SQLpro]

C'est logique que vous voyez une fragmentation d'extent scan. A mon sens, c'est justement à cause du BLOB. Vous n'y pourrez rien et cela n'est pas remédiable. Pour comprendre pourquoi, il faudrait que vous explique comment fonctionne un moteur de stockage base de données et celui de sql server en particulier !

Donc, aucune fragmentation. Quand aux pages libres, inutile de déflater le fichier. C'est une hérésie !

A +