Discussion :

[demxav]

J'ai une problématique à résoudre sur la réorganisation des "data" et des "index" des tables DOL.
Actuellement en production nous réorganisons tous nos indexes « clustered et non clustered » de nos tables DOL. Le schéma de « lock » de nos tables sont en « Data Pages Locking » avec une « Primary key – clustered » et avec des indexes « non-clstered ». Certaines tables sont trés volumineuses (40 Millions de rows).
Pour la défragmentation de nos indexes, nous utilisons la commande « optdiag », et nous contrôlons uniquement le taux « lgio ». Nous estimons qu’une réorganisation doit être faite si le taux est inférieur à 0,8. Nous ne utilisons pas la commande « reorg rebuild » mais suppression et création d’indexes.
Or nous constatons que nous réorganisons toutes les nuits, toujours les mêmes indexes, nous constatons qu’il y a une très forte dégradation du taux « lgio » en une journée de production. Il nous arrive très souvent que la recréation des indexes ne soient pas finis, le matin, lors de la mise en ligne de notre système d’information.
Nous pensons que nous faisons trop souvent de réorganisation d’indexes, et surtout que nous faisons une mauvaise analyse des taux de défragmentations.

Avez-vous la réponse à mes 2 questions ?

1-Quelle est la différence exacte entre la commande « create nonclustered index <NomTable>.<NomIndex> » et la commande « reorg rebuild <NomTable> <NomIndex> » ?

2-Quels sont exactement les taux à contrôler pour connaître réellement l’état de défragmentation des indexes sur les tables DOL ? Sur le forum, j’ai cru comprendre qu’il faut analyser plusieurs paramètres pour déterminer l’état de désorganisation d’un index ou d’une table DOL. Faut-il contrôler le taux « dpcr » ou « ipcr » avec le taux « sput » et « delrows » et « forwrows », etc ….. ?

Cordialement

demxav

[Fabien Celaia]

1) Le reorg rebuild peut se faire en ligne (sans donc verrouiller totalement la table). Il nécessite par contre plus d'espace disque que la recréation... et c'est peut-être un problème dans votre cas de figure. Il a cependant l'avantage de rebuilder que ce qui doit l'être... à la différence de votre drop/create.

2) le lgio (large io efficiency ) est une valeur statistique... je ne me baserai pas forcément sur elle pour ma stratégie de reconstruction. Utilisez-vous massivement les larges io sur vos indexes ?

Plus généralement : êtes-vous en environnement OLTP our ou mixte ? Ne serait-il pas plus indiqué de vous baser sur une stratégie moins orientée "on refait tout", surtout avec les volumétries annoncées ? Avez-vous envisagé le partitionnement ? Parallélisez-vous vos traitements ?

[demxav]

Bonjour,

Merci pour les explications sur la commande "reorg rebuild".

Concernant l'analyse et l'interprétation du rapport généré par la commande "optdiag", j'ai besoin d'explications complémentaires.
(Nous pouvons obtenir le même rapport avec la commande "derived_stat")
Pour comprendre notre problématique je vous apporte plus d'informations.
Tout nos server ASE sont en 12.5.3 sur machine Solaris.
Nous sommes plutôt en environnement mixte.
Dans un premier temps (pour différentes raisons), nous n'envisageons pas de partitionner nos tables et de paralléliser nos requêtes.

Notre stratégie n'est pas exactement "tout ou rien", Pour chaque indexes de chaque table DOL, nous contrôlons "uniquement" son ratio "lgio" associé, et si il est inférieur à un seuil nous réorganisons l'index correspondant. Notre seuil fixé à 0.7 est purement aléatoire !!!!

Pourquoi vous dites que le ratio "lgio" est une valeur statistique ? Dans notre cas, il varie beaucoup.
Comment on détermine l'utilisation massive des "lgio" sur nos indexes ?

Comment faut-il analyser les ratios du rapport "optdiag" ? Dans la doc Sybase "Performance & Tuning : Optimizer and Abstract Plans", je n'ai pas trouver (ou compris) comment on détermine qu'un index est défragmenté. Dans les explications de Sybase, en résumé, si les ratios (dpcr, ipcr, sput, lgio) sont faibles (<1), il faut "refaire" l'index.

Existe-il, un calcul "générique" sur les différents ratios fournis par Sybase, pour déterminer l'état de dégradation d'un index ?

Je pense qu'il faut analyser plusieurs paramètres pour être pertinent sur la réorganisation des tables DOL.
Mon analyse est-elle exacte ?

Coedialement

demxav

Ci-joint un rapport "optdiag" d'une nos tables DOL