none
problème de performances RRS feed

 > 

  • Question

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    sur mon serveur Windows 2003 R2 SP2 avec SQL Server 2005 Enterprise SP4, je rencontre un problème de performances lors de l'exécution d'une requête. Je suppose une fragmentation interne des tables concernées.

    j'ai exécuté les requêtes suivantes:

    DBCC showcontig("TEMP_ESF_STAGIAIRES_CA") WITH NO_INFOMSGS ;Go
    DBCC showcontig("TEMP_DOSSCP_CA") WITH NO_INFOMSGS ;Go
    DBCC showcontig("TEMP_SALARIE_CSP") WITH NO_INFOMSGS ;Go

     
    voici les résultats:

    DBCC SHOWCONTIG analyse la table 'TEMP_ESF_STAGIAIRES_CA'...

     

    Table : 'TEMP_ESF_STAGIAIRES_CA' (1645353026) ; index ID : 1, base de données ID : 14

     

    Analyse du niveau TABLE effectuée.

     

    - Pages analysées................................: 151999

     

    - Extensions analysées..............................: 19003

     

    - Commutateurs d'extension..............................: 19002

     

    - Moyenne des pages par extension........................: 8.0

     

    - Densité d'analyse [meilleure valeur:valeur réelle].......: 99.98% [19000:19003]

     

    - Fragmentation d'analyse logique..................: 0.01%

     

    - Fragmentation d'analyse d'extension...................: 0.38%

     

    - Moyenne d'octets libres par page.....................: 341.3

     

    - Densité de page moyenne (complète).....................: 95.78%

     

    DBCC SHOWCONTIG analyse la table 'TEMP_DOSSCP_CA'...

     

    Table : 'TEMP_DOSSCP_CA' (1516584491) ; index ID : 1, base de données ID : 14

     

    Analyse du niveau TABLE effectuée.

     

    - Pages analysées................................: 9159

     

    - Extensions analysées..............................: 1155

     

    - Commutateurs d'extension..............................: 1298

     

    - Moyenne des pages par extension........................: 7.9

     

    - Densité d'analyse [meilleure valeur:valeur réelle].......: 88.14% [1145:1299]

     

    - Fragmentation d'analyse logique..................: 2.13%

     

    - Fragmentation d'analyse d'extension...................: 1.47%

     

    - Moyenne d'octets libres par page.....................: 689.3

     

    - Densité de page moyenne (complète).....................: 91.48%

     

    DBCC SHOWCONTIG analyse la table 'TEMP_SALARIE_CSP'...

     

    Table : 'TEMP_SALARIE_CSP' (1628077086) ; index ID : 1, base de données ID : 14

     

    Analyse du niveau TABLE effectuée.

     

    - Pages analysées................................: 8236

     

    - Extensions analysées..............................: 1034

     

    - Commutateurs d'extension..............................: 1033

     

    - Moyenne des pages par extension........................: 8.0

     

    - Densité d'analyse [meilleure valeur:valeur réelle].......: 99.61% [1030:1034]

     

    - Fragmentation d'analyse logique..................: 0.08%

     

    - Fragmentation d'analyse d'extension...................: 1.35%

     

    - Moyenne d'octets libres par page.....................: 38.7

     

    -Densité de page moyenne (complète).....................: 99.52%

     

     Je ne sais pas interpréter ces résultats. Voyez-vous un problème flagrant?

     

    Merci pour votre aide.

    mercredi 21 septembre 2011 09:42
    |

Réponses

  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter
    Il faut regarder fragmentation d'analyse logique (le nombre de fois ramené sur 100 où la page suivante dans le plan d'allocation d'une table / d'un index n'est pas aussi la page suivante physiquement sur disque, précisément la valeur de retour de sys.dm_db_index_physical_stats().avg_fragmentation_in_percent), et la densité d'analyse (le nombre de commutations d'extents effectuées pour lire l'ensemble de l'objet par rapport au nombre idéal de lectures d'extents si la table / l'index n'était pas fragmenté).
    Globalement:
    - Fragmentation d'analyse logique doit être le plus proche possible de 0%.
    - Densité d'analyse doit être le plus proche possible de 100%.
    Donc dans ton cas ce ne semble pas être le pb.
    Il faudrait voir le résultat de :
    set statistics io on
set statistics time on
set statistics profile on

SELECT (...)

    David B.
    jeudi 22 septembre 2011 17:08
    |

Toutes les réponses

  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter
    Il faut regarder fragmentation d'analyse logique (le nombre de fois ramené sur 100 où la page suivante dans le plan d'allocation d'une table / d'un index n'est pas aussi la page suivante physiquement sur disque, précisément la valeur de retour de sys.dm_db_index_physical_stats().avg_fragmentation_in_percent), et la densité d'analyse (le nombre de commutations d'extents effectuées pour lire l'ensemble de l'objet par rapport au nombre idéal de lectures d'extents si la table / l'index n'était pas fragmenté).
    Globalement:
    - Fragmentation d'analyse logique doit être le plus proche possible de 0%.
    - Densité d'analyse doit être le plus proche possible de 100%.
    Donc dans ton cas ce ne semble pas être le pb.
    Il faudrait voir le résultat de :
    set statistics io on
set statistics time on
set statistics profile on

SELECT (...)

    David B.
    jeudi 22 septembre 2011 17:08
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    merci beaucoup David pour ta réponse

     

    afin de procéder à une défragmentation interne, on m'a dit qu'il  suffit d'utiliser la reconstruction d'index dans le plan de maintenance de la base, confirmes-tu?

     

    Merci

    vendredi 23 septembre 2011 08:22
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    En effet.

     

    David B.
    vendredi 23 septembre 2011 09:33
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter
    merci
    vendredi 23 septembre 2011 09:55
    |