Avec ce court article, je voudrais dissiper un malentendu lié à l'analyse des bases de données AWR exécutées sur Oracle Exadata. Depuis près de 10 ans, je suis constamment confronté à la question : quelle est la contribution d'Exadata Software à la productivité ? Ou, en utilisant des mots nouvellement inventés : dans quelle mesure le travail d'une base de données particulière est-il « expert » ?
Souvent, à mon avis, cette question correcte reçoit une réponse incorrecte en référence aux statistiques AWR. Il présente la méthode d'attente du système, qui traite le temps de réponse comme la somme du temps de fonctionnement des processeurs (CPU DB) et du temps d'attente des différentes classes.
Avec l'avènement d'Exadata, des attentes système spécifiques liées au fonctionnement du logiciel Exadata sont apparues dans les statistiques AWR. En règle générale, les noms de ces attentes commencent par le mot « cellule » (le serveur Exadata Storage est appelé une cellule), parmi lesquelles les plus courantes sont les attentes portant les noms explicites « cell smart table scan », « cell multiblock lecture physique » et « lecture physique d’un seul bloc de cellule ».
Dans la plupart des cas, la part de ces attentes Exadata dans le temps de réponse total est faible et, par conséquent, elles n'entrent même pas dans la section Top10 des événements de premier plan par temps d'attente total (dans ce cas, vous devez les rechercher dans la section Attente de premier plan). rubrique événements). Avec beaucoup de difficulté, nous avons trouvé un exemple d'AWR quotidien de nos clients, dans lequel les attentes d'Exadata étaient incluses dans la section Top10 et s'élevaient au total à environ 5 % :
événement
Attend
Temps d'attente total (sec)
Attendre moyenne
% de temps de base de données
Cours d'attente
Processeur de base de données
115.2K
70.4
SQL*Net plus de données de dblink
670,196
5471.5
8.16ms
3.3
Réseau
lecture physique d'un seul bloc de cellule
5,661,452
3827.6
676.07us
2.3
E/S utilisateur
Synchroniser le rééquilibrage ASM
4,350,012
3481.3
800.30us
2.1
Autre
lecture physique multibloc de cellules
759,885
2252
2.96ms
1.4
E/S utilisateur
lecture du chemin direct
374,368
1811.3
4.84ms
1.1
E/S utilisateur
Message SQL*Net de dblink
7,983
1725
216.08ms
1.1
Réseau
analyse de table intelligente cellulaire
1,007,520
1260.7
1.25ms
0.8
E/S utilisateur
température de lecture du chemin direct
520,211
808.4
1.55ms
0.5
E/S utilisateur
enq : TM - confliction
652
795.8
1220.55ms
0.5
Candidature
Les conclusions suivantes sont souvent tirées de ces statistiques AWR :
1. La contribution de la magie Exadata aux performances de la base de données n'est pas élevée - elle ne dépasse pas 5 % et la base de données « s'exadapte » mal.
2. Si une telle base de données est transférée d'Exadata vers l'architecture classique « serveur + baie », les performances ne changeront pas beaucoup. Car même si cette baie s'avère trois fois plus lente que le système de stockage Exadata (ce qui n'est guère possible pour les baies All Flash modernes), alors en multipliant 5 % par trois on obtient une augmentation de la part des attentes d'E/S à 15 % - la base de données survivra certainement à cela !
Ces deux conclusions sont inexactes et faussent en outre la compréhension de l’idée derrière Exadata Software. Exadata ne se contente pas de fournir des E/S rapides, son fonctionnement est fondamentalement différent de l'architecture classique serveur + baie. Si le fonctionnement de la base de données est véritablement « exadapté », alors la logique SQL est transférée vers le système de stockage. Les serveurs de stockage, grâce à un certain nombre de mécanismes spéciaux (principalement les index de stockage Exadata, mais pas seulement), trouvent eux-mêmes les données nécessaires et envoient la base de données aux serveurs. Ils le font de manière assez efficace, de sorte que la part des attentes typiques d'Exadata dans le temps de réponse total est faible.
Comment ce partage va-t-il évoluer en dehors d’Exadata ? Comment cela affectera-t-il les performances de la base de données dans son ensemble ? Les tests répondront au mieux à ces questions. Par exemple, attendre une « analyse de table intelligente de cellule » en dehors d'Exadata peut se transformer en une analyse complète de table si lourde que les E/S prennent tout le temps de réponse et les performances se dégradent considérablement. C'est pourquoi il est erroné, lors de l'analyse d'AWR, de considérer le pourcentage total des attentes d'Exadata comme la contribution de sa magie aux performances, et encore plus d'utiliser ce pourcentage pour prédire les performances en dehors d'Exadata. Pour comprendre à quel point le travail de la base de données est « exact », vous devez étudier les statistiques AWR de la section « Statistiques d'activité de l'instance » (il existe de nombreuses statistiques avec des noms explicites) et les comparer entre elles.
Et pour comprendre ce que ressentira une base de données en dehors d'Exadata, il est préférable de faire un clone de base de données à partir d'une sauvegarde sur l'architecture cible et d'analyser les performances de ce clone sous charge. En règle générale, les propriétaires d'Exadata ont cette opportunité.
Auteur: Alexey Struchenko, chef du département de base de données Jet Infosystems
Source: habr.com