AWR : dans quelle mesure la base de données « est-elle en exode de données ? »

Avec ce court article, je voudrais dissiper un malentendu concernant l'analyse AWR des bases de données fonctionnant sur Oracle Exadata. Depuis près de 10 ans, je fais face à la question suivante : quelle est la contribution des logiciels Exadata à la performance ? Ou en utilisant des termes nouveaux : dans quelle mesure une base de données est-elle « exadatisée » ?

Il arrive souvent que cette question légitime, à mon avis, reçoive une réponse incorrecte se basant sur les statistiques AWR. Celles-ci présentent une méthode d'attente système, considérant le temps de réponse comme la somme du temps de travail des processeurs (DB CPU) et du temps d'attente de diverses classes.

Avec l'apparition d'Exadata, des attentes système spécifiques liées aux logiciels Exadata sont apparues dans les statistiques AWR. En général, les noms de ces attentes commencent par le mot “cell” (un serveur de stockage Exadata est appelé cellule), et on rencontre le plus fréquemment des attentes aux noms évocateurs comme “cell smart table scan”, “cell multiblock physical read” et “cell single block physical read”.

Dans la plupart des cas, la part de ces attentes Exadata dans le temps de réponse global est faible, et donc elles ne figurent même pas dans la section Top10 Foreground Events by Total Wait Time (dans ce cas, il faut les chercher dans la section Foreground Wait Events). Nous avons eu beaucoup de mal à trouver chez nos clients un exemple quotidien d'AWR où les attentes Exadata figuraient dans la section Top10 et représentaient environ 5 % :

Événement

Attentes

Temps d'attente total (sec)

Attente moyenne

% temps DB

Classe d'attente

DB CPU

115,2K

70.4

SQL*Net plus de données du dblink

670,196

5471.5

8,16 ms

3.3

Réseau

cell single block physical read

5,661,452

3827.6

676,07 µs

2.3

Utilisateur I/O

Sync rééquilibrage ASM

4,350,012

3481.3

800,30 µs

2.1

Autre

cell multiblock physical read

759,885

2252

2,96 ms

1.4

Utilisateur I/O

lecture par chemin direct

374,368

1811.3

4,84 ms

1.1

Utilisateur I/O

SQL*Net message du dblink

7,983

1725

216,08 ms

1.1

Réseau

cell smart table scan

1,007,520

1260.7

1,25 ms

0.8

Utilisateur I/O

lecture par chemin direct temp

520,211

808.4

1,55 ms

0.5

Utilisateur I/O

enq: TM — contention

652

795.8

1220,55 ms

0.5

Application

À partir de telles statistiques AWR, on tire souvent les conclusions suivantes :

1. La contribution de la magie d'Exadata à la performance de la base de données n'est pas élevée — elle ne dépasse pas 5 %, et la base de données « exadatisée » fonctionne mal.

2. Si une telle base est transférée d'Exadata vers une architecture classique « serveur + matrice », la performance ne changera pas significativement. En effet, même si cette matrice s'avérait trois fois plus lente que le système de stockage Exadata (ce qui est peu probable pour les matrices All Flash modernes), en multipliant 5 % par trois, on obtiendrait une augmentation de la part des attentes en entrée/sortie à 15 % ­— une telle base de données est certainement capable de le supporter !

Les deux résultats sont imprécis, et de plus, ils déforment la compréhension de l'idée sous-jacente au logiciel Exadata. Exadata n'assure pas simplement une entrée/sortie rapide, elle fonctionne de manière fondamentalement différente par rapport à l'architecture classique « serveur + stockage ». Si le travail de la base de données est vraiment « exadata » — alors la logique SQL est transférée au système de stockage. Storage serveurs grâce à une série de mécanismes spéciaux (avant tout les Exadata Storage Indexes, mais pas seulement) trouvent elles-mêmes les données nécessaires et les transmettent aux serveurs DB. Elles le font de manière suffisamment efficace, c'est pourquoi la part des attentes spécifiques à Exadata dans le temps de réponse global est faible. 

Comment cette part va-t-elle changer en dehors d'Exadata ? Quel impact cela aura-t-il sur la performance globale de la base de données ? Le meilleur moyen de répondre à ces questions est de procéder à des tests. Par exemple, l'attente “cell smart table scan” en dehors d'Exadata peut se transformer en un scan de table complet si lourd que l'entrée/sortie occupera tout le temps de réponse et que la performance se détériorera dramatiquement. C'est pourquoi il est incorrect, lors de l'analyse AWR, de considérer le pourcentage total des attentes d'Exadata comme une contribution de sa magie à la performance et, surtout, d'utiliser ce pourcentage pour prédire les performances en dehors d'Exadata. Pour comprendre à quel point le travail de la base “exadata” doit être étudié, il faut examiner les statistiques AWR de la section “Instance Activity Stats” (il y a beaucoup de statistiques avec des noms évocateurs) et les comparer entre elles.

Et pour comprendre comment la base de données se comportera hors d'Exadata, il est préférable de faire un clone de la base à partir d'une sauvegarde sur l'architecture cible et d'analyser la performance de ce clone sous charge. Cette possibilité est généralement offerte aux propriétaires d'Exadata.

Auteur : Alexey Struchenko, responsable de la division des bases de données chez « Infosystèmes Jet »

Source : habr.com