Ancora sulla V$OPEN_CURSOR

mercoledì 11 maggio 2011 alle 11:58 | Pubblicato su Diario | 8 commenti

Visto che la mia risposta ai commenti del post precedente diventava pericolosamente lunga ho deciso di dedicare un post  apposito.

Tracciando il piano di esecuzione di una query sulla V$OPEN_CURSOR si verifica parte di quanto dice Alessandro:


--------------------
SQL_ID  3xyw5tppy1w8t, child number 0
-------------------------------------
select * from v$open_cursor where sid=1

Plan hash value: 2659856713

-----------------------------------------------------------------
| Id  | Operation        | Name    | Rows  | Bytes | Cost (%CPU)|
-----------------------------------------------------------------
|   0 | SELECT STATEMENT |         |       |       |     1 (100)|
|*  1 |  FIXED TABLE FULL| X$KGLLK |     1 |   121 |     0   (0)|
-----------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter(("KGLLKSNM"=1 AND "KGLHDNSP"=0 AND
"INST_ID"=USERENV('INSTANCE') AND "KGLHDPAR"<>"KGLLKHDL"))


la vista alla base della V$OPEN_CURSOR è la X$KGLLK dove in effetti si possono trovare ancora più informazioni, il problema è decifrarle.

Ricordo che io sono partito dalla necessità di individuare il testo di un statement il cui cursore in qualche ciclo non veniva chiuso provocando l’errore ORA-1000. Il numero di cursori aperti dato dal conteggio sulle statistiche è quello da prendere a riferimento e che se raggiunge il limite imposto dal parametro OPEN_CURSORS provoca l’errore ORA-1000. Il numero di record in  V$OPEN_CURSOR per una data sessione è sempre maggiore al numero di cursori realmente aperti che possono portare all’errore  ORA-1000. Dal punto di vista dell’occupazione di memoria e delle prestazioni presumo sia effettivamente vero che si possono considerare i cursori riportati nella V$OPEN_CURSOR come aperti.

Ho fatto il seguente test, ho aperto una sessione con un utente, da un’altra ho interrogato la V$OPEN_CURSOR con la seguente query:


select saddr,sid,count(*) from v$open_cursor where sid=151 group by saddr,sid;

il cui risultato era:


SADDR    SID                    COUNT(*)
-------- ---------------------- ----------------------
2DF4C87C 151                    2
2DF6569C 151                    3
2DF4A0AC 151                    1
2DF53FEC 151                    5
2DF389FC 151                    2
2DF4016C 151                    18
2DF6BA24 151                    9
2DF3C5B4 151                    2
2DF3128C 151                    5
2DF2D6D4 151                    6



Il database è poco usato, suppongo che quelli siano cursori di sessioni aperte e chiuse in precedenza, che hanno avuto lo stesso SID ma SADDR diverso. Ho provato a chiudere la connessione e riaprirla subito dopo (da sql*plus) e questa a ripreso lo stesso SADDR (ma diverso SERIAL#). Essendo tutti statement su viste di sistema, ad esempio:


select privilege# from sysauth$ where (grantee#=:1 or grante



ho ipotizzato che siano legati a chiamate ricorsive però qui siamo un po’ sull’esoterico

Settando per la sessione di test il parametro SESSION_CACHED_CURSORS a 0 in effetti non si trovano poi nella V$OPEN_CURSOR record per la coppia SID,SADDR

Il thread di AskTom segnalato da Alessandro mi pare quello che ho visto anche io ieri ma come quasi tutti questi thread faccio fatica a leggere fino in fondo.

Ieri ho trovato anche questo post di Dion Cho che confesso di non aver compreso a fondo, che però da anche un suggerimento per approfindire l’analisi: fare un dump dello stato del processo con l’istruzione:

alter session set events 'immediate trace name processstate level 10';

8 commenti »

RSS feed for comments on this post. TrackBack URI

  1. ho individuato probabilmente la parte che piu ti interessa😉 :

    http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1041031921901#1018065300346796630

  2. 🙂 grazie.
    Ho provato anche attivare il trace sql per un breve intervallo sulla sessione ed effettivamente i record con stesso SID e SADDR diverso paiono legati a chiamate ricorsive (che compaiono nel trace).

  3. L’ho trovato anch’io il post…davvero interessante…io ho trovato anche questo che secondo me o meglio da come l’ho capita è complementare a quello di Dion Cho….
    http://www.orafaq.com/node/758

  4. Invece riguardo la questione del “più SADDR per SID” non ho scoperto nulla, se non che, dopo altri tests, me li sono ritrovati anch’io, e come tu accennavi sembrano essere tutti recursive SQLs.
    Bisogna sottolineare comunque che anche questi SQLs di sistema possono contribuire a far superare la soglia open_cursors.

  5. Ho notato che quando terminiamo una sessione, i cursori USER relativi a quel SID in V$OPEN_CURSOR, vengono (come ci si dovrebbe aspettare) rimossi, mentre quelli recursive no.
    Quindi i SADDRs in V$OPEN_CURSOR per un certo SID, diversi da V$SESSION.SADDR, sono relativi a sessioni che avevano in passato ottenuto quel SID. Una verifica può essere fatta filtrando V$OPEN_CURSOR per uno di questi SADDR “spuri”: otteniamo una serie di cursori relativi a differenti SID.

  6. altro contributo alla discussione viene sempre da Jonathan Lewis qui:

    http://forums.oracle.com/forums/thread.jspa?messageID=2329804&#2329804

  7. anche Tanel Poder ha dato il suo contributo alla causa:
    http://forums.oracle.com/forums/message.jspa?messageID=2706348#2706348

  8. Devo dire che questa volta Tanel Poder non ha per niente contribuito alla causa. Si è messo a parlare del perché Oracle utilizzi la strategia di hashing sulla stringa ASCII del testo delle queries, mentre qui si parlava di Session Cursor Cache.
    Tanel (sarà il nome o il cognome?) questa volta mi hai deluso!😉


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: