IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration SQL Server Discussion :

Reconstruction d'index inefficace ?


Sujet :

Administration SQL Server

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    Avril 2007
    Messages
    89
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Avril 2007
    Messages : 89
    Par défaut 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)

    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

    J'ai même constaté en passant par SSMS (noeud Indexes / Rebuild) que le taux de fragmentation bouclait (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

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 998
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 998
    Billets dans le blog
    6
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    Avril 2007
    Messages
    89
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Avril 2007
    Messages : 89
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 ) 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.

  4. #4
    Expert confirmé
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Par défaut
    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 ?

    ++

  5. #5
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    Avril 2007
    Messages
    89
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Avril 2007
    Messages : 89
    Par défaut
    Citation Envoyé par mikedavem Voir le message
    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

    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.

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 998
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 998
    Billets dans le blog
    6
    Par défaut
    9 pages, fragmentation mesurée à 40% c'est normal. C'est pas une réelle fragmentation, et vous n'y pourrez jam

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 998
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 998
    Billets dans le blog
    6
    Par défaut
    9 pages, fragment
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  8. #8
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 998
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 998
    Billets dans le blog
    6
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Reconstruction d'index inéficasse
    Par Drezounet218 dans le forum MS SQL Server
    Réponses: 6
    Dernier message: 07/03/2008, 16h28
  2. [Firebird] - Reconstruction d'index ?
    Par SurfingJeff dans le forum Administration
    Réponses: 4
    Dernier message: 18/04/2007, 16h37
  3. [DBA] : reconstruction d'indexs
    Par PpPool dans le forum Oracle
    Réponses: 21
    Dernier message: 19/10/2006, 16h13
  4. Reconstruction d'index
    Par superfly dans le forum Oracle
    Réponses: 22
    Dernier message: 23/03/2006, 16h58
  5. reconstruction d'index de texte intégral
    Par zarbiman dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 14/12/2005, 08h23

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo