What Cancer Cannot Do

http://karenmorton.blogspot.com/2012/10/what-cancer-cannot-do.html

Oracle events : cursor: pin S wait on X & ORA-04030

Dernièrement j'ai rencontré un problème de performance lié à une requête d'insert , lors de l’exécution de cette requête par plusieurs sessions en même temps un de programme se termine en erreur

ORA-12801: error signaled in parallel query server P077ORA-04030: out of process memory when trying to allocate 44452 bytes                                     (initSubHeap:qk,travElemP:qkspmTravCreate) 

L'insert dans la table se fait à partir d'une vue oracle qu'est basé sur d'autres vues oracles avec plusieurs jointures avec d'autres tables.

J'ai constaté la présence de l’évènement cursor: pin S wait on X    parmi les Top 5 Timed Foreground Events

 Top 5 Timed Foreground Events~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                              Avg                              wait   % DBEvent                                 Waits     Time(s)   (ms)   time Wait Class------------------------------ ------------ ----------- ------ ------ ----------DB CPU                                            1,980          51.8db file sequential read             407,338         388      1   10.1 User I/Ocursor: pin S wait on X                 444         304    686    8.0 Concurrencdb file scattered read                8,748         103     12    2.7 User I/Oenq: TX - row lock contention             9          50   5587    1.3 Applicatio

Ma requête est présente dans le bloc SQL ordered by Sharable Memory  dans le report AWR:

SQL ordered by Sharable Memory           
Sharable Mem (b)  Executions   % Total    SQL Id---------------- ------------ -------- -------------       7,388,523            1     0.88 cd1777r7db2kcModule: PPXMINSERT INTO MYTABLE
       5,541,891            1     0.66 4chckmq1yu1vdModule: PPXMINSERT INTO MYTABLE
       5,541,855            1     0.66 0nfd6dkqsfwpwModule: PPXMINSERT INTO MYTABLE
       5,541,851            1     0.66 5yu5smgshjttsModule: PPXMINSERT INTO MYTABLE

Suite à une analyse de ce deux éléments, j'ai constaté que ce problème est lié hard + soft parse de requête.

Le serveur ne supporte plus la charge en mémoire. 

La requête prend toujours le même plan d’exécution (le bon plan). 

J'ai utilisé des bind variables et ça résout le problème : le même sql_id est utilisé par les différents programmes qui font appel à cette requête. La variable dans la requête est le numéro de session.       

ORACLE OPEN WORLD

https://oracleus.activeevents.com/connect/search.ww?event=openworld