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 😉