:cfou: Reconstruction Index DBCC SHOWCONTIG

Bonjour,

Je viens d'executer la reconstruction d'index sur ma base sql 2000 avec l'assistant ssms 2005 :oops:(la honte oui je sais :lol: ) au préalable j'ai effectué un dbcc showcontig mes index étaient très fragmenté.

Après la reconstruction je refais un dbcc showcontig 21 seconde au lieu 30 woaa c'est super, j'analyse et compare les rapports de dbcc shwcontg, et je remarque ceci:

Citation:

---

DBCC SHOWCONTIG analyse la table 'T_PARAMETRE'...
Table : 'T_PARAMETRE' (175443799) ; index ID : 1, base de données ID : 7
Analyse du niveau TABLE effectuée.
- Pages analysées................................: 5
- Extensions analysées..............................: 3
- Commutateurs d'extension..............................: 2
- Moyenne des pages par extension........................: 1.7
- Densité d'analyse [meilleure valeur:valeur réelle].......: 33.33% [1:3]
- Fragmentation d'analyse logique..................: 40.00%
- Fragmentation d'analyse d'extension...................: 66.67%
- Moyenne d'octets libres par page.....................: 2168.0
- Densité de page moyenne (complète).....................: 73.21%

---

Citation:

---

après reconstruction
- Extensions analysées..............................: 5
- Commutateurs d'extension..............................: 4
- Moyenne des pages par extension........................: 1.0
- Densité d'analyse [meilleure valeur:valeur réelle].......: 20.00% [1:5]
- Fragmentation d'analyse logique..................: 80.00%:koi:
- Fragmentation d'analyse d'extension...................: 60.00%
- Moyenne d'octets libres par page.....................: 2168.0
- Densité de page moyenne (complète).....................: 73.21%

---

Pourquoi après une reconstruction d'index mon index pour cette table est passé de 40% Fragmentation d'analyse logique à 80%, quelqu'un peut m'expliquer merci?

C'est parfaitement normal. Votre table est si petite qu'elle sera toujours vue comme fragmenté. En effet, le stockage des table est fait par page de 8 Ko concaténées au sein d'extensions constitués par des blocs de 8 pages contiguës. Dans votre cas, vous avez 5 pages soit 5/8 d’extensions, soit 3/8 de vide, soit 37,5% (à la louche) de vide.
Après defrag, le compactage étant meilleur, la fragmentation apparait encore plus.

C'est pourquoi généralement on ne tient pas compte des petites tables dans les analyse de fragmentation et on les défragmente systématiquement.

Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/optimis...ntenanceIndex/

A +

Merci d'avoir pris le temps de me répondre.
Concernant l'option relatives à l'espace libre lors de la reconstruction d'index des tables et des vues, que me conseillez vous, devrai-je laisser l'option

-Réorganiser les pages avec les quantité d'espace disponible par défaut

-Modifier l'espace disponible par pourcentage? Et quelle valeur mettre ?

Merci d'avance

Bonsoir,

La valeur dépend surtout de l'usage fait sur l'index.
Un manque d'espace conduira à un split des pages de l'index plus rapide alors qu'une quantité d'espace libre trop importante conduira à un index obèse.

L'augmentation de l'espace libre peut être effectué si vous savez que votre index sera relativement mis à jour fréquemment. Par exemple, vous savez que vous aurez une insertion de données plus importante pendant une période et vous pourrez à ce moment précis augmenter l'espace libre dans vos index pour éviter les splits de pages.

Cependant cette valeur est absorbée au fur et à mesure des insertions (l'espace libre diminuant au fur et à mesure des insert). Il faudra réindex pour récupérer à nouveau cet espace libre.

++

Bonjour,

si je comprends bien, il n'est pas choquant d'avoir une forte fragmentation sur des index portants sur des petites tables ?
A partir de quelle volumétrie devons-nous prendre en compte la fragmentation de l'index ?

J'ai énormément de tables dans ma base avec une forte fragmentation... et ce même après reconstruction d'index...


merci pour vos précisions,

Les tables sont organisées par page (de 8 ko) situées dans des extensions de 8 pages soit 64 Ko de données contiguës.
Si votre table n'en occupe que 3 elle aura toujours une fragmentation d'extension rémanente à 1 - 3/8 = 62,5 %

A +

Je comprends la logique du calcul, mais je dois oublier quelque chose dans mon calcul, j'ai du mal à le reproduire pour une table exemple de ma base :
Elle a 4 champs de taille 9 octets (numeric(10,0)) et comporte 1071 enregistrements.
L'index (fragmenté) composé d'un champs est sur la clé primaire (donc cluster) de cette table.
(ps en passant : je sais très bien que le type de données des champs ne sont pas bon mais je pense que là n'est pas le problème pour ma compréhension du calcul)

résultat du DBCC SHOWCONTIG :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Table*: 'Table Exemple' ; index ID*: 1, base de données ID*: 7 Analyse du niveau TABLE effectuée. - Pages analysées................................: 8 - Extensions analysées..............................: 8 - Commutateurs d'extension..............................: 7 - Moyenne des pages par extension........................: 1.0 - Densité d'analyse [meilleure valeur:valeur réelle].......: 12.50% [1:8] - Fragmentation d'analyse logique..................: 87.50% - Fragmentation d'analyse d'extension...................: 87.50% - Moyenne d'octets libres par page.....................: 2071.6 - Densité de page moyenne (complète).....................: 74.41%

---

Pourriez vous m'aider à retrouver les valeurs de fragmentation ?
Merci pour votre aide

Un petit cours de math ne serait sans doute pas de trop !!!!

Code:

---

1 2 3 4

Pages analysées................................: 8 Moyenne des pages par extension........................: 1.0 donc 1 pages sur 8 = 1/8 = 0.125 soit 12,5% Fragmentation d'extension (pourcentage de pages vides dans l'extension) : 100 - 12,5 = 87,50 %

---

A +