Discussion :

[Ikebukuro]

Amis DBA bonjour,

J’ai généré un rapport Statspack et je me pose des questions sur les points suivants :

Le serveur a 4 cpus.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Database    DB Id    Instance     Inst Num  Startup Time   Release     RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
                                                       1 30-Nov-21 17:06 19.0.0.0.0  NO
 
Host Name             Platform                CPUs Cores Sockets   Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
                              Linux x86 64-bit           4     4       4         19.3

1) La base est en version Standard donc sans parallélisme. Alors comment peut-on avoir un DB Time > au Elapsed Time ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
SQL> select banner from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 – Production
 
Begin Snap:          5 03-Dec-21 13:04:05       69       2.0
  End Snap:          8 03-Dec-21 14:11:35       71       2.0
   Elapsed:      67.50 (mins) Av Act Sess:       1.0
   DB time:      70.52 (mins)      DB CPU:      49.67 (mins)

2) Le nombre d’ordres SQL capturés compte pour plus de 100% du DB CPU : c’est normal ou c’est un bug de Statspack de la version 19?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SQL ordered by CPU  ...  Snaps: 5-8
-> Total DB CPU (s):           2,980
-> Captured SQL accounts for  214.6% of Total DB CPU
-> SQL reported below exceeded  1.0% of Total DB CPU

Merci pour vos retours 😊

[dell68]

Je possède ce lien expliquant les interprétations des rapports AWR et STATSPACK
https://prezi.com/tlp_ga71ztxy/franc...tspack-report/
Bonne chance

[Ikebukuro]

Je connaissais ce lien mais, sauf erreur de ma part, il ne gère pas ma problématique d'une édition Standard Oracle.
En résumé, si j'ai une édition Standard et un serveur avec 4 CPU, est-ce que Oracle peut utiliser ces 4 CPUs ou est-il limité à un seul CPU?

[vanagreg]

En Standard Edition 2 tu es limité à 2 CPUs. Au niveau des comptages je ne sais pas trop comment Statspack fait, mais ça m'étonnerait qu'il soit très maintenu et suive proprement les évolutions Oracle (multitenant entres autres). Je me demande d'ailleurs si Statspack utilise toujours DBMS_JOB pour ses snapshots.

[Pomalaix]

Il faut revenir à la définition de base du DB time.
C'est le temps passé dans la base, par les sessions d'avant plan (et non les processus noyau) en CPU et en attentes actives ("non idle").
C'est le fait que les attentes soient incluses dans le DB time qui est décisif.

Même sur un système qui aurait un seul processeur et un seul coeur, vous pouvez avoir plusieurs sessions. Elles auront certes des tranches de temps processeur à tour de rôle, mais elles peuvent être en attente simultanément.

Exemple : J'ai un base dans laquelle j'ai 3 sessions en cours. A 14h, je fais un UPDATE sans COMMIT dans ma session S1, ce qui va donc maintenir un verrou sur la ligne concernée, et je m'arrête là. J'ai 2 sessions par ailleurs qui essayent à leur tour de faire un UPDATE sur cette même ligne. Elles se retrouvent en attente. A 15h, le DB time total résultant de ces 3 sessions depuis 14h est de 2 heures : une fraction de seconde pour S1 qui a fait son UPDATE, une heure pour S2, une heure pour S3.


Il est donc tout à fait possible d'avoir le DB time supérieur au temps passé (elapsed), sans invoquer ni le parallélisme ni même le fait d'avoir un CPU multicoeur.


(Parenthèse 1 : La limitation de l'édition standard 2 est de 2 supports de CPU (sockets).
Avec les CPU modernes, ça peut correspondre à un bon paquet de coeurs. Il existe par exemple des Xeon à 36 coeurs)


(Parenthèse 2 : Je suppose que vous êtes sur une machine virtuelle. Elle est probablement mal configurée, car elle indique 4 sockets et 4 coeurs)

[pachot]

En Standard Edition 2 tu es limité à 2 CPUs. Au niveau des comptages je ne sais pas trop comment Statspack fait, mais ça m'étonnerait qu'il soit très maintenu et suive proprement les évolutions Oracle (multitenant entres autres). Je me demande d'ailleurs si Statspack utilise toujours DBMS_JOB pour ses snapshots.

c'est 16 threads en En Standard Edition 2

La base est en version Standard donc sans parallélisme. Alors comment peut-on avoir un DB Time > au Elapsed Time ?

Le parallélisme c'est pour utiliser plusieurs threads pour une session. Mais il y a plusieurs sessions. Et des process background.

Le nombre d’ordres SQL capturés compte pour plus de 100% du DB CPU : c’est normal ou c’est un bug de Statspack de la version 19?

Si une procédure PL/SQL exécute une requête SQL, il y a une entrée pour chacun. Et donc la somme va compter le temps 2 fois

Je connaissais ce lien mais, sauf erreur de ma part, il ne gère pas ma problématique d'une édition Standard Oracle.
En résumé, si j'ai une édition Standard et un serveur avec 4 CPU, est-ce que Oracle peut utiliser ces 4 CPUs ou est-il limité à un seul CPU?

Si si, les plusieurs sessions, et le PL/SQL qui appelle le SQL y sont 😉

[Ikebukuro]

Merci beaucoup pour vos réponses, je n'avais jamais travaillé sur une Standard Edition et je découvre ses limitations.

Autres questions (puisque vous êtes forts, j'en profite ) un autre DBA avec qui je travaille me dit que :
- Statspack a été mal porté sur la 19c, sans donner d'exemple précis; est-ce que vous confirmez? si oui, peut-on avoir confiance dans ce qui est affiché dans le rapport?
- les Memory Advisors d'Oracle ne seraient pas pertinents : par exemple, quand tu as des requêtes quasi identiques sans bind variables, la Shared Pool explose et l'advisor te conseillerait plutôt d'augmenter la taille de la Shared Pool plutôt que de dire de remplacer les constantes par des bind variables

Pouvez-vous m'expliquer la différence entre : CPU, core, socket, thread?
Pour moi :
- un CPU : c'est l'objet que l'on fixe sur la carte mère sur le socket et qui renferme les cores
- un core (ou coeur) : c'est l'unité, dans le CPU, qui effectue le travail
- un socket : c'est l'emplacement sur la carte mère pour insérer un CPU
- un thread : c'est un process, géré par un core, qui exécute le travail (requêtes SQL...)

Question à Pomalaix : "Je suppose que vous êtes sur une machine virtuelle. Elle est probablement mal configurée, car elle indique 4 sockets et 4 coeurs"
pourquoi dis-tu que la VM est mal configurée?

[pachot]

- Statspack a été mal porté sur la 19c, sans donner d'exemple précis; est-ce que vous confirmez? si oui, peut-on avoir confiance dans ce qui est affiché dans le rapport?

De manière générale, ce genre d'affirmation dans donner des faits n'est pas crédible. Je ne travaille plus sur des bases oracle, mais j'ai utilisé Statspack sur des 19c je ne vois pas le problème. Statspack est basé sur des métriques qui datent de longtemps et sont toujours les même. En multitenant certaines métriques n'ont pas de sens au niveau PDB, mais c'est tout.

- les Memory Advisors d'Oracle ne seraient pas pertinents : par exemple, quand tu as des requêtes quasi identiques sans bind variables, la Shared Pool explose et l'advisor te conseillerait plutôt d'augmenter la taille de la Shared Pool plutôt que de dire de remplacer les constantes par des bind variables

Oui, pas de magie, les advisor font une première interprétation mais il n'y a pas de solution automatique. L'autre problème des advisors c'est qu'ils regardent des moyennes alors que la charge peut être irrégulière.

Pouvez-vous m'expliquer la différence entre : CPU, core, socket, thread?
Pour moi :
- un CPU : c'est l'objet que l'on fixe sur la carte mère sur le socket et qui renferme les cores
- un core (ou coeur) : c'est l'unité, dans le CPU, qui effectue le travail
- un socket : c'est l'emplacement sur la carte mère pour insérer un CPU
- un thread : c'est un process, géré par un core, qui exécute le travail (requêtes SQL...)

Le premier, c'est le processeur. Le terme de CPU dépend à quel niveau on regarde. Par exemple Linux appelera CPU les threads parce que c'est ce qu'il voit à son niveau. AIX parlera LCPU pour les threads et de VCPU pour une partie du processeur alloué. Un hyperviseur peut montrer les threads (vCPU) comme s'ils étaient 1 socket 1 coeur. Avec la virtualisation ces termes sont compliqués. Il faut connaître ce qu'il y a dessous pour les interpréter.

[Pomalaix]

Question à Pomalaix : "Je suppose que vous êtes sur une machine virtuelle. Elle est probablement mal configurée, car elle indique 4 sockets et 4 coeurs"
pourquoi dis-tu que la VM est mal configurée?

Sous VMWare, quand on crée une VM, on peut choisir la manière dont l'OS verra les CPU qu'on lui alloue. Par exemple, dans votre cas, au lieu de dire 4 sockets de 1 coeur, on aurait pu dire 1 socket de 4 coeurs.
Je pense à vrai dire (mais sans l'avoir expérimenté) que pour Oracle cette nuance ne sera pas un problème d'un point de vue technique et performances, mais j'ai eu récemment un cas sur SQL Server où la VM était paramétrée avec 8 sockets de 1 coeur. Comme l'édition standard de SQL Server ne supporte que 4 sockets, la moitié de la CPU allouée à la VM était inutilisable.

Concernant Statspack, il y a un souci avec la liste des événements d'attente considérés comme inactifs (idle) qui est fausse, et on peut se retrouver avec un "top 5 events" complètement bidon.
Ca se règle assez facilement et on s'en rend compte tout de suite quand on a un peu d'habitude, mais ça reste ennuyeux d'avoir quelque chose de bancal.
D'après la note Oracle 28523746.8, c'est encore le cas en 19.1, et ça serait réglé en 20.1

[Ikebukuro]

Merci Pomalaix pour ton retour : peux-tu m'expliquer comment corriger le pb des idle events buggés dans le rapport Statspack?
J'ai par exemple un top 5 de Waited Events
- pman timer (quasi inconnu d'Oracle)
- data guard manager (pas sur du libellé)
- data guard idle (pas sur du libellé)
- CPU
- ...

[Pomalaix]

Voici la petite commande que j'utilise dans ce cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
insert into  perfstat.stats$idle_event
(select name from v$event_name
where wait_class='Idle'
minus
select event from perfstat.stats$idle_event);

[Ikebukuro]

Merciiiiiiiiiiiiiiiiii

[SQLpro]

Sous VMWare, quand on crée une VM, on peut choisir la manière dont l'OS verra les CPU qu'on lui alloue. Par exemple, dans votre cas, au lieu de dire 4 sockets de 1 coeur, on aurait pu dire 1 socket de 4 coeurs.
Je pense à vrai dire (mais sans l'avoir expérimenté) que pour Oracle cette nuance ne sera pas un problème d'un point de vue technique et performances....

Salut confrère et ami varois... Juste une précision. Chaque socket induit un pan de mémoire dédié (NUMA). Avec une mémoire relativement minime et un grand nombre de pans de mémoire dédié ceci va fatalement induire des requêtes qui vont devoir parcourir plusieurs pans pour lire les données (ces dernière pouvant être à cheval sur deux pans... Dans ce cas il faudra deux threads pour la traiter ce qui, pour des petites requêtes demandera plus de ressources et durera plus longtemps en sus de consommer ces ressources supplémentaire au détriment des autres utilisateurs !

À lire :
https://indico.cern.ch/event/304944/...96898/numa.pdf
https://citeseerx.ist.psu.edu/viewdo...=rep1&type=pdf
notamment :
"This leads to disadvanteous cache evictions when threads migrate between nodes or when threads access the same data from different nodes"

Au fait à samedi !!!

A +