Reconstruction d'index inefficace ?

Bonjour à tous,

Je ne suis pas dba, mais consultant sur des produits dont les bases sont stockées dans un runtime SQL Server 2008 Entreprise SP2.
Aucun des fils que j'ai consulté sur la reconstruction d'index ne laisse apparaître de souci analogue, voici donc les faits :

Depuis la mise à jour en dernière version du produit, mes utilisateurs ont constaté de - très - gros ralentissement lors de "traitements" auparavant quasi-instantanés comme l'affichage unitaire d'une fiche (1 à 2 s) ou le fait de la quitter sans aucune modification (5 à 10s) :aie:

J'ai donc consulté divers sites et testé sur une copie de la base de production de reconstruire les index fragmentés à plus de 50% (une vingtaine de tables)
Que ce soit via des PS glanées de ci de là, des ALTER INDEX ... REBUILD/REORGANIZE, ou via SSMS, rien à faire, mes index restent fragmentés :cry:

J'ai même constaté en passant par SSMS (noeud Indexes / Rebuild) que le taux de fragmentation bouclait 8O (50, 60, 83, 70, 50...)
Bref je suis un poil perplexe.

A toutes fins utiles :
Serveur virtuel : Win2003 Server R2 Standard SP2 32 bits, E7330@2,4 GHz, 4Go RAM)
Instance par défaut, limitée à 3 Go + AWE
Base de données : mode de récupération simple, 4Go de MDF (67% libres), log 1Go (99% libres)
tempdb : MDF 1Go, LDF 512Mo, vide suite au redémarrage de l'instance

Postes clients : Win7 64bits, Core i5 @3,1Ghz, 4Go de RAM
Réseau en gigabit

J'ai vu en parcourant différents fils que la virtualisation et les SGBDR comme SQL Server n'étaient pas franchement copains comme cochons, mais avant la mise à jour aucune lenteur anormale n'avait été constatée. A part jouer sur les index, je ne vois pas ce que je peux faire, mais s'il y a d'autres vérifications ou pistes je suis preneur.

Merci pour vos lumières et suggestions toujours appréciées ;)

Bonne journée

1) AWE avec 4 Go de RAM ne sert a rien.

2) un taux de fragmentation est relatif à une unité de mesure.
Si votre table contient 3 lignes d'environ 50 octets, le taux de fragmentation apparaitra de l'ordre de 98,125 %
En effet, les lignes sont stockées dans des pages de 8 Ko. Or 150 octets dans une page de 8 000 octets => 7850 octets de vide, soit 7850/8000...
Dans votre requête, filtrez sur les index ayant au moins 8 pages...

3) les VM sont en effet très dommageable suer le plan de perf. Lisez les articles que j'ai écrit à ce sujet, notamment : http://blog.developpez.com/sqlpro/p8...irtualisation/

A +

1) OK désactivé

2) j'ai donc filtré la requête comme suit (+ un filtre sur les tables utilisées dans le cadre de la problématique citée) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

SELECT object_name(IPS.object_id) AS [TableName], SI.name AS [IndexName], IPS.Index_type_desc, IPS.avg_fragmentation_in_percent, IPS.page_count, -- modif IPS.avg_fragment_size_in_pages, IPS.avg_page_space_used_in_percent, IPS.record_count, IPS.ghost_record_count, IPS.fragment_count, IPS.avg_fragment_size_in_pages FROM sys.dm_db_index_physical_stats(12, NULL, NULL, NULL , 'DETAILED') IPS JOIN sys.tables ST WITH (nolock) ON IPS.object_id = ST.object_id JOIN sys.indexes SI WITH (nolock) ON IPS.object_id = SI.object_id AND IPS.index_id = SI.index_id WHERE ST.is_ms_shipped = 0 AND (SI.name LIKE '%T_H%' OR SI.name LIKE '%SAL%') AND IPS.page_count > 8 -- modif ORDER BY 1,5 GO

---

Dans ce jeux de résultat (~100 lignes, j'évite donc de polluer le fil sauf si c'est nécessaire), il y a des index CLUSTERED et NONCLUSTERED. Seuls ces derniers affichent encore des taux parfois supérieurs à 60%, mais le page_count n'excède pas 26000 dans le pire des cas.
Je suis rattrapé par mon manque de connaissances : les requêtes que j'ai exécutées auraient du traiter (au moins pour une) tous les index fragmentés à plus de 40%, il y a donc une subtilité pour les NONCLUSTERED ?

Exemple : table T_HST_NATIONALITE, 4717 lignes
PK_T_HST_NATIONALITE, NONCLUSTERED INDEX, , 9 pages, %frag 77,77
IX_T_HST_NATIONALITE, NONCLUSTERED INDEX, , 9 pages, %frag 44,44
IX_T_HST_NATIONALITE_1, CLUSTERED INDEX, 33 pages, %frag 0

3) Malheureusement comme souvent pas le choix, bien qu'à la lecture de cet article (assez chaud pour moi :oops:) il semble que pour 2 users et 1,5Go de données "utiles" cela devrait passer ?

Quoiqu'il en soit j'ai d'autres clients avec des VMWare et des volumes approchants, mais c'est le seul à ramer autant.

Merci encore.

Visiblement rien d'anormal du côté de tes index.

As-tu déjà pensé à regarder le comportement de tes ressources serveurs ? CPU, RAM, disques etc ....

Si tu es en milieu virtualisé as-tu vérifié que les ressources de ton serveur SQL ne soient pas vampirisées par l'hyperviseur ?

++

Citation:

---

Envoyé par mikedavem

Visiblement d'anormal du côté de tes index.

As-tu déjà pensé à regarder le comportement de tes ressources serveurs ? CPU, RAM, disques etc ....

Si tu es en milieu virtualisé as-tu vérifié que les ressources de ton serveur SQL ne soient pas vampirisées par l'hyperviseur ?

++

---

Ce n'est pas du tout ma partie :(
Sorti du gestionnaire des tâches, je ne connais pour ainsi dire rien au monitoring.
Je vais demander à l'admin de la machine de voir ce qu'il peut faire mais je ne suis pas hyper optimiste. Pas de machine physique pour faire un test, et concernant les VM je n'ai pas accès à cette partie, seulement au serveur SQL. LA personne qui pourrait gérer cela n'est pas présente lors de mes interventions, donc forcément ça aide...

Bref je vais demander un coup de main mais c'est loin d'être gagné.
Ce qui me semble réellement bizarre, c'est que je suis intimement convaincu qu'il s'agit d'un souci au niveau de l'exécutable qui gère tout cela (la version précédente était vraiment très performante), mais là je suis aussi démuni que mes utilisateurs, j'ai l'impression que je vais me trouver un violon et un vent contraire :aie:

Mais soyons positifs, j'ai désormais la certitude d'avoir fait tout ce que j'ai pu pour cette ^%#@! de BDD, donc je vais renvoyer chacun vers ses prérogatives, on verra bien.

Merci en tout cas d'avoir pris le temps d'examiner mon problème et d'y répondre. S'il y a du neuf du côté des VM on verra (j'ai trouvé un best practice de VMWare concernant le SQL qui parle de Soft-NUMA, on verra bien s'ils s'en sortent avec ça, parce que pour moi c'est abscons).

Merci encore et bonne soirée à tous.

PS: Je ne vais pas vous faire perdre plus de temps, je marque donc le sujet résolu. Merci à tous.

9 pages, fragmentation mesurée à 40% c'est normal. C'est pas une réelle fragmentation, et vous n'y pourrez jam

A +

9 pages, fragment

9 pages, fragmentation de 40% c'est normal, c'est pas de frag !!!

En effet, imaginez 2 rames TGV de 8 voitures (une rame = une extension).
Si chaque voiture de la rame 1 est pleine et seulement 1 de la rame 2 (soit 9 wagons) alors vous avez 40% de vide, ce que vous indique cette requête.

La fragmentation est mesurée par rapport à la page sur les extensions qui sont des blocs de 8 pages contigus.

A +

Merci pour cet exemple très clair, comme d'habitude :mrgreen:
Une subtilité de plus comprise, c'est déjà pas mal pour commencer la journée ;)

Bonne journée.