RE: tracing specific sql_id in 12.2

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: _at_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: _at_NenadNoveljic

--
http://www.freelists.org/webpage/oracle-l