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 % :
Espaces
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
Autres
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
Demande de leasing
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, de surcroît, elles dénaturent la compréhension du concept d'Exadata Software. Exadata ne se contente pas de fournir des E/S rapides ; son fonctionnement diffère fondamentalement de l'architecture classique « serveur + baie ». Lorsqu'une base de données devient véritablement « Exadata », la logique SQL est migrée vers le système de stockage. serveurs Grâce à plusieurs mécanismes spécifiques (principalement les index de stockage Exadata, mais pas seulement), les données nécessaires sont automatiquement trouvées et transmises aux serveurs de base de données. Cette opération est très efficace, ce qui réduit considérablement la part des temps d'attente typiques d'Exadata dans le temps de réponse global.
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
