RE: tracing specific sql_id in 12.2

  • From: Stefan Koehler <contact@xxxxxxxx>
  • To: Tanel Poder <tanel@xxxxxxxxxxxxxx>, nenad.noveljic@xxxxxxxxxxxx
  • Date: Fri, 15 Dec 2017 09:15:36 +0100 (CET)

Hey Nenad,

What I did, is updated the pointer between step 1 and 2 in the SGA, so the 
"corrected" configuration was copied from SGA to PGA. The whole test case is 
reproducible at will.

Yes, this is what i meant and makes sense :-) 

Best Regards
Stefan Koehler

Independent Oracle performance consultant and researcher
Website: http://www.soocs.de
Twitter: @OracleSK

Noveljic Nenad hat am 14. Dezember 2017 um 21:18 geschrieben:


Hey Stefan,

I've understood the process as follows:


1. alter system set events...

The events will be built in PGA and transferred to SGA. In particular, the 
individual elements of the doubly linked list will be copied by the function 
dbgdCopyEventNode.


1. connecting to the database

It is the reversed process. The same function will copy the elements of the 
linked list from SGA to heap.

What I did, is updated the pointer between step 1 and 2 in the SGA, so the 
"corrected" configuration was copied from SGA to PGA. The whole test case is 
reproducible at will.

I've just uploaded the DTrace script for tracing the different function calls 
which are participating in the event propagation: 
https://github.com/nenadnoveljic/dtrace/blob/master/dbgd_flow_122.d . While ;
both steps can be traced, you'd need to stop the dedicated process 
immediately after forking in Step 2, which would allow you to attach to it 
with the DTrace. By the way, I described this foot-in-the-door technique 
here: http://nenadnoveljic.com/blog/debugging-session-creation/

Best,
Nenad

http://nenadnoveljic.com/blog/
Twitter: @NenadNoveljic
--
//www.freelists.org/webpage/oracle-l


Other related posts: