Discussion :

[grouhan]

Bonjour,

lors de l'analyse AWR je constate que les événements d'attentes ne représentent même pas 50 % du DB Time. Ceci indique t'il un manque de ressource CPU ?



Merci pour vos retours

[grouhan]

Bonjour,

quelqu'un aurait-il un début d'explication ?

Je vous joins un autre AWR sur une autre version d'oracle et sur un autre OS où je constate le même comportement

[Mohamed.Houri]

Bonjour

Est-ce que votre application se trouve sur un serveur mutualisé? D'autres applications peuvent entrer en concurence avec la votre si cela est vrai.

Sinon, comme expliqué dans un de mes messages précédents, vous avez un Load relativement elevé puisque il est de 19,4 au début du snapshot. Ceci signifie qu'au moins 19-10=9 processes étaient en attente de CPU ou d'I/O (on ne peut pas le dire avec certitude sans un vmstat).

De plus, à votre place, j'essaierai d'identifier les requêtes qui font du db file sequential read. En effet avec 13,8 M de waits il serait interessant de lancer la requête suivante

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
SELECT
    sql_id,
    10 * COUNT(1) cnt
FROM
    dba_hist_active_sess_history
WHERE
    sample_time BETWEEN TO_DATE('03052022 02:20:00', 'ddmmyyyy hh24:mi:ss') AND TO_DATE('03052022 02:40:00', 'ddmmyyyy hh24:mi:ss')
AND event = 'db file sequential read'
GROUP BY
    sql_id
ORDER BY
    2 DESC;

C'est possible que cela soit dû à votre insert sur la table xxx123.zzechcd0 fait en autonomous transaction. Vous faites 7 millions d'insert en 20 minutes. Cela se voit dans votre nombre de transactions par seconde qui est de 6,348.

Code :

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

6348 *20*60= 7,617,600 user commit

Je crois que cet enorme nombre de commit par seconde n'a pas eu beaucoup d'effet sur le temps d'attente log file sync pour deux raisons:

• Les commits sont faits dans un bloque PL/SQL; ceci incrémente le nombre de log file sync par PL/SQL call et non par user commit
• Vous utilisez COMMIT WRITE BATCH NOWAIT;

A votre place j'essaierai de réduire ce nombre de transaction si cela est possible. A noter aussi que votre log file sync, bien qu'il ne cause apparement aucun soucis particulier, il se fait en parallele puisque j'observe les waits event correspondants tels que

• LGWR any worker group
• LGWR worker group ordering

Dans le cas où vous seriez à même de confirmer que votre activité de commit devient prépondérante, il serait intéressant de prévoir de remettre le LGWR en série via le paramètre suivant

Code :

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

_use_single_log_writer= true

Vérifier également le cache de la séquence xxx123.zzechcd0_seq car vous avez des temps d'attente du type enq: SQ - contention

Je me demande enfin, qu'est ce qui peut causer un echange de données si grand que le temps d'attente SQL*Net more data from client apparaise dans la liste des Top 10 Foreground Events by Total Wait Time

Bref, ce sont là quelques remarques rapides pour vous aider dans votre analyse. S'il faut aller plus loin il faut envisager de faire appel à une intervention externe

Bien Cordialement
Mohamed

[grouhan]

Bonjour,

merci pour ce retour

la base de donnés se trouve effectivement sur un serveur mutualisé, mais pourquoi dans ce cas les métriques remontées DB CPU + wait non idle sont si éloigné des 100 % de DB Time ?

Concernant le load average, vous le comparez avec le nombre de CORE de 10 et non le nombre de CPU ! C'est-à-dire qu'ici pour une seconde, il n'y a que 10 secondes de temps CPUs qui peuvent être alloués aux processus ? et non 40 secondes correspondant aux nombre de CPUs ?

Pouvez-vous détailler SVP pourquoi le fait de mettre le LGWR en série serait plus performant que de le laisser en parallèle ?

Concernant le temps d'attente SQL*Net more data from client , il y a comme vous avez du le constater, des tailles de requêtes qui sont énormes ! C'est peut-être une des causes, je ne sais pas vraiment comment calculer pour une requête donnée, le nombre de paquets qui seront transmis.

J'ai demandé l'exécution de la requête pour identifier les principaux responsables des db file sequential read

Cordialement,
Jérôme

[grouhan]

Bonjour,

le résultat de la requête d'identification des db file sequential read,

Pouvez-vous SVP préciser l'utilité du x 10 sur le count dans la requête

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
ID	Event	date	cnt
bpwycm2ddtpn8	db file sequential read	03-MAY-22	16540
0j5f88wgcjhar	db file sequential read	03-MAY-22	13050
5qfmanqqqc674	db file sequential read	03-MAY-22	3780
71wrw5hp2y2u8	db file sequential read	03-MAY-22	1960
6dnrtvptawkbz	db file sequential read	03-MAY-22	1630
fzpsyss0j5s1c	db file sequential read	03-MAY-22	860
5c1r3pryfmhgj	db file sequential read	03-MAY-22	700
8nqs09h6ab6dp	db file sequential read	03-MAY-22	570
gps8d61c9wgd2	db file sequential read	03-MAY-22	340
azkctv7957sd0	db file sequential read	03-MAY-22	250
fv67qs22mzu1a	db file sequential read	03-MAY-22	250
cya3bmxmrxhvt	db file sequential read	03-MAY-22	240
dpj97daz86qqp	db file sequential read	03-MAY-22	230
c93d0bh2y9hgd	db file sequential read	03-MAY-22	210
05yfvup6yb647	db file sequential read	03-MAY-22	150

le sql id 0j5f88wgcjhar correspond à une requête insert et le sql id 1r9tp8726b06j au PLSQL correspondant
le sql id 5fz44xytwdb26 correspond à une requête delete

Le sql id bpwycm2ddtpn8 correspond à une requête select