Il y a onze jours, j'ai écrit sur un blog sur la façon dont Adaptive Dynamic Stats consommait des ressources dans mes bases de données RAC de production.
Après avoir éteint cet incendie, j'étais sur le point d'examiner certaines requêtes peu performantes signalées par nos responsables de l'assurance qualité dans Test et d'autres bases de données hors production. J'ai fait comme n'importe quel bon administrateur de base de données Oracle. J'ai rassemblé un appel de procédure stockée qui a dupliqué le problème. Dans ma session, j'ai démarré une trace SQL et exécuté la procédure stockée. Il a fallu 50 secondes pour terminer, alors que cela prenait 5 secondes ou moins avant de passer de 11.2.0.4 à 12.1.0.2. Cette procédure stockée contient un certain nombre d'instructions SQL et une trace SQL semblait être un endroit logique pour commencer. J'avais besoin de savoir quelle instruction SQL de la procédure causait les problèmes.
J'ai exécuté le fichier de trace SQL via TKPROF et j'ai été surpris par les résultats. Les instructions SQL de la procédure stockée semblaient s'exécuter assez rapidement. Mais j'ai été accueilli par de nombreuses déclarations similaires à celles-ci :
SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring
optimizer_features_enable(default) no_parallel */ SUM(C1)
FROM
(SELECT /*+ qb_name("innerQuery") INDEX_FFS( "XXX"
"INDEX_NAME") */ 1 AS C1 FROM
"OWNER"."TABLE_NAME" SAMPLE BLOCK(71.048, 8) SEED(1)
"XXX") innerQuery C'est l'échantillonnage dynamique au travail. En examinant toutes les instructions d'échantillonnage dynamique exécutées dans mon fichier de trace, j'ai pu déterminer qu'elles représentaient 45 secondes de la durée d'exécution globale ! Aïe !
L'échantillonnage dynamique est censé m'aider. Le temps passé à obtenir des exemples de statistiques est censé être bien inférieur au temps gagné en exécutant l'instruction SQL avec de meilleures statistiques. Si ce n'est pas le cas, les performances de votre instruction SQL peuvent en souffrir, comme ce fut mon cas.
J'ai noté une chose que je trouvais intéressante, c'est que ces requêtes d'échantillonnage dynamique étaient exécutées une fois pour chaque table et une fois pour chacun de ses index. L'une des tables impliquées dans ma requête comporte 7 index, donc pour cette table, j'ai eu 8 requêtes d'échantillonnage dynamique !
Dans mon article de blog il y a 11 jours, j'avais défini le paramètre optimiser_dynamic_sampling sur 0, ce qui empêche l'exécution de ces requêtes. Je n'avais pas encore appliqué cette modification à notre environnement de test, je devais donc le faire. Dès que je l'ai fait, les performances des requêtes sont revenues à la normale. La valeur par défaut de ce paramètre pour ma base de données est 2. Votre valeur par défaut peut différer selon la valeur du paramètre Optimizer_features_enable. Selon ce billet de blog, une valeur de 2 signifie que l'échantillonnage dynamique se déclenchera lorsqu'au moins une des tables n'a pas de statistiques. Mais pour être honnête, l'échantillonnage dynamique ne me procure aucun avantage et ne me cause que du tort. Je vais donc le laisser de côté dans son intégralité pour le moment.
