Discussion :

[arona]

quand utilisez vous cette utilitaire ??
Je pose la question car j'ai souvent urilisez sp_sysmon pour avoir des stats sur l'utilisation serveur des engines i/o proc stock stat diverse sur des temps d'éxécutions afin de voir les goulets ... mais je ne sais pas utiliser optdiag.
Merci de vos infos a ce sujet.

[mpeppler]

L'utilisation principale d'optdiag (pour moi) c'est l'extraction des statistiques d'une table. On peut aussi l'utiliser pour charger des statistiques dans une table (p.ex. pour simuler la répartition de données de productions sur un serveur de test).

L'extraction des statistiques en mode texte se fait comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
optdiag statistics histo..table_size -o /tmp/table_size.diag -Usa -P.... -Sserveur

et cela donne un fichier avec ce genre d'info:

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
19
20
21
22
 
Statistics for index:                   "table_size_pk" (clustered)
Index column list:                      "serverName", "insertDate", "dbName", "tableName", "segmentName"
     Data page count:                   174744
     Empty data page count:             0
     Data row count:                    2290020.0000000000000000
     Forwarded row count:               0.0000000000000000
     Deleted row count:                 0.0000000000000000
     Data page CR count:                28643.0000000000000000
     OAM + allocation page count:       1270
     First extent leaf pages:           0
     Data row size:                     86.0131048329484429
     Index height:                      5
     Parallel join degree:              0.0000000000000000
     Unused page count:                 47
     OAM page count:                    6
 
  Derived statistics:
     Data page cluster ratio:           0.9555267787653449
     Space utilization:                 0.5591278173457184
     Large I/O efficiency:              0.7625947002758090
...

ainsi que les histogrammes de distribution des valeurs dans les colonnes de bases des indexes:

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
19
20
21
22
 
Histogram for column:                   "insertDate"
Column datatype:                        date
Requested step count:                   20
Actual step count:                      34
Sampling Percent:                       0
 
     Step     Weight                    Value
 
        1     0.00000000       <=       "Dec 31 2003"
        2     0.04707488       <=       "Jun  9 2004"
        3     0.04728249       <=       "Aug  3 2004"
        4     0.02111898       <=       "Aug 26 2004"
        5     0.00333062       <=       "Aug 27 2004"
        6     0.00423175       <=       "Sep  2 2004"
...
       29     0.04967224       <=       "Jun 13 2006"
       30     0.04662874       <=       "Jul 18 2006"
       31     0.04684076       <=       "Aug 22 2006"
       32     0.04618701       <=       "Sep 25 2006"
       33     0.01095042       <=       "Oct  3 2006"
       34     0.00179341       <=       "Oct  4 2006"

Ces histogrammes permettent à l'optimiseur d'évaluer le nombres d'IO qui sont nécessaires en fonction de clauses WHERE.

Tout ceci est expliqué en détail dans le manuel "Performance and Tuning", qui vaut nettement la peine d'être lu!


Michael

[arona]

C'est marrant je voyais plus optdiag comme un "outil" pour aider a tuner des requètes ...
Sont utilisation se limite a l'extraction des statistiques d'une table ou d'autres utilisations peuvent elles être faite.

[lsone]

C'est exactement ça, un outil pour le tuning !
Tu peux l'utiliser pour rajouter des steps afin d'optimiser mes requêtes etc ...

Si tu peux, suis la formation Performance and Tuning developper ASE de chez Sybase.

[arona]

Merci à vous.

[Fabien Celaia]

Autre intérêt de optdiag : modifier les pas pour l'optimiseur.

Cas d'école:

• chaque nuit, des insertions de la journes sont faites dans une base décisionnelle via bcp.
• chaque WE, les stats sont rejouées
• chaque jour, les utilisateurs accèdent aux dernières données

Problème:

• Toutes les requêtes utilisant des dates de la dernières semaine n'utilisent pas correctement l'index sur la date.

Diagnostic:

• Le dernier step de stat est à une date inférieure de la date intéressante => magic number => mauvaises perfs

Tuning

• Extraction des stats avec optdiag
• Modification du dernier échelon de date à date = date + 1 an
• Importation des stats

[Fabien Celaia]

Autre intérêt de optdiag : modifier les pas pour l'optimiseur.

Cas d'école:

• chaque nuit, des insertions de la journes sont faites dans une base décisionnelle via bcp.
• chaque WE, les stats sont rejouées
• chaque jour, les utilisateurs accèdent aux dernières données

Problème:

• Toutes les requêtes utilisant des dates de la dernières semaine n'utilisent pas correctement l'index sur la date.

Diagnostic:

• Le dernier step de stat est à une date inférieure de la date intéressante => magic number => mauvaises perfs

Tuning

• Extraction des stats avec optdiag
• Modification du dernier échelon de date à date = date + 1 an
• Importation des stats

Cf