Performances de SQL basées sur les performances d'autres requêtes exécutées en même temps - AWR

Question

Dans Oracle 10g, j'ai un SQL qui s'exécute raisonnablement plus rapidement (environ 30-40 minutes environ) aujourd'hui. Lorsque le même SQL a été exécuté il y a deux jours, il a fallu environ 2,5 heures pour que le SQL soit terminé. Je pensais que le plan d'exécution de la requête pouvait avoir changé. Mais ce n'était pas le cas. Les deux plans d'exécution ont été mis en correspondance. Donc, avec l'aide de DBA, j'ai généré le rapport AWR pour trouver l'activité de la base de données au cours de la période. Effectivement, cette requête à long terme présenté avec quelques autres requêtes. Dans l'AWR, cette requête comportait un nombre élevé de tampons, une liste de lectures de disques mais il y avait au moins quatre autres requêtes qui étaient encore plus élevées (elles constituaient ensemble 98%). En fait, la plus grande interrogation dans les deux listes était d'environ 50% de la taille de la mémoire tampon et de 80% des lectures de disque, alors que la taille de la mémoire ne prenait qu'environ 2% et 0,9% respectivement. Ma requête ne figurait dans aucune autre liste, y compris le temps CPU et les appels analysés.

Donc, ma question - Est-il possible qu'une grande quantité de tampon et les lectures de disque par d'autres requêtes impactent les performances de ma requête?

Answer 1

Absolument. Sans entrer dans les profondeurs de la conception de base de données, un système de base de données a un tas de ressources partagées sous le capot.

La plus grande est généralement les pages de données. Ils sont conservés sur le serveur et fournissent des données pour une requête. Si vous lisez une table plusieurs fois, par exemple, la seconde lecture est beaucoup, beaucoup, beaucoup plus efficace lorsque la page est déjà en mémoire. Si d'autres requêtes utilisent le cache de pages, vous insérez moins de pages dans le cache, et il est plus probable que votre requête doive lire sur le disque.

Bien sûr, il peut également y avoir des conflits directs. Plusieurs requêtes peuvent tenter d'extraire des données du disque en même temps - et vos appels d'E/S peuvent se retrouver dans une file d'attente les retardant.

Il peut également y avoir des interactions plus subtiles. Une optimisation importante pour les moteurs de base de données est "lecture avant". Autrement dit, si vous lisez une page de données, il est probable que vous voudrez la suivante également. Pendant que le moteur traite les données en mémoire, le système d'E/S peut s'éteindre et aller chercher le suivant.

Eh bien, si vous avez beaucoup de requêtes en cours d'exécution en même temps, le moteur peut ne pas avoir la bande passante à lire en avance pour vos pages.

Ce ne sont que quelques exemples de la façon dont la mise en mémoire tampon et d'autres requêtes affectent les performances. Mais la réponse est un "oui" retentissant. D'autres requêtes peuvent avoir un impact sur les performances de votre requête.