Discussion :

[tropiko]

Bonjour ,
Le rapport ASH m'affiche beaucoup de snaps count pour la lecture (WAITING) d'une PK (db file sequentiel read).
Pourquoi tout ce temps d'attente I/O db sequentiel read = 53 % de l'activité.
Le temps CPU = 35 % de l'activité
Que faut-il faire pour optimiser cet accès d'index PK ?

• Rebuilder la PK (hauteur = 2 déjà ) : Une PK peut-elle subir une défragmentation importante ?
• Revoir la requête
• Tester le FULL SCAN sans PK.

NB : Les stats ne sont pas à jour...
Merci.

[ojo77]

Pour optimiser une PK il faut ordonner les données dans la table. A priori une table n'est pas faite pour ça, c'est plutôt vers l'objet "cluster" qu'il faut se tourner pour mettre en place ce genre de choses.

[mnitu]

Investiguez les traitements qui génèrent cette situation ainsi que les requêtes SQL impliquées en faisant des traces SQL étendues. Trouvez l’explication de ce phénomène et vous allez trouver la solution à apporter.

[pachot]

Bonjour,
Il est normal qu'un accès INDEX UNIQUE SCAN fasse des 'db file sequential read' lorsque les blocs ne sont pas déjà en cache. Il faudrait vérifier le plan d'exécution avec gather_plan_statistics et dbms_xplan.display_cursor(,,'ALLSTATS LAST') pour voir si le nombre de blocs lus est normal ou pas. On s'attend à lire 3 blocs d'index pour chaque accès si blevel=2.

Une PK peut-elle subir une défragmentation importante ?

Si les valeurs viennent d'une sequence, non. sinon, tout dépend de l'activité insert/delete
Cordialement,
Franck.