Discussion:
tracing specific sql_id in 12.2
Noveljic Nenad
2017-12-12 15:02:52 UTC
Permalink
Has somebody tried tracing a specific sql_id in Oracle 12.2? The feature doesn't seem to work properly.

Here's the test case:

Session 1:
alter system set events='sql_trace[sql: 2asugy1n1r7y7] level=12' ;
SQL> alter system set events='sql_trace[sql: 2asugy1n1r7y7] level=12' ;

System altered.

SQL> quit

Session 2:
connect / as sysdba
SQL> oradebug setmypid
Statement processed.
SQL> oradebug eventdump session
sql_trace[sql: 2asugy1n1r7y7] level=12

SQL> select count(*) from v$sql where sql_id='2asugy1n1r7y7';

COUNT(*)
----------
0

SQL> select /* test_trace */ 1 from dual ;

1
----------
1

SQL> select count(*) from v$sql where sql_id='2asugy1n1r7y7';

COUNT(*)
----------
1




Unlike 12.1, the SQL doesn't get traced on a 12.2 database unless ran in the same session where the "alter system set events" was executed .


Nenad

Twitter:@NenadNoveljic
Home page: http://nenadnoveljic.com/blog/

____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">p { font-family: Arial;font-size:9pt }</style>
</head>
<body>
<p>
<br>Important Notice</br>
<br>This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system.</br>
<br>E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of the Vontobel Group and its affiliates for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.<br/>
</p>
</body>
</html>
Tanel Poder
2017-12-14 16:14:40 UTC
Permalink
Maybe there's some bug in 12.2 with event propagation when using ALTER
SYSTEM, maybe a variation of what's described here:

https://blog.tanelpoder.com/2013/10/07/why-doesnt-alter-system-set-events-set-the-events-or-tracing-immediately/

... Although eventdump seems to show the event is enabled for the session
too. Did you start session 2 before or after issuing ALTER SYSTEM in st?

If 12.2 happens to use the Multitenant config, perhaps test running the
ALTER SYSTEM at the root CDB level...

--
Tanel Poder
http://blog.tanelpoder.com
Post by Noveljic Nenad
Has somebody tried tracing a specific sql_id in Oracle 12.2? The feature
doesn’t seem to work properly.
alter system set events='sql_trace[sql: 2asugy1n1r7y7] level=12' ;
SQL> alter system set events='sql_trace[sql: 2asugy1n1r7y7] level=12' ;
System altered.
Noveljic Nenad
2017-12-14 16:48:48 UTC
Permalink
No multitenant, and tested with both new and existing 2. session. Most probably a bug - quite inconvenient.

However, I’ve managed to reconstruct the doubly linked list, where the system events are stored:

linked list ptr to root entry:
BCFFDE18+28: *BCFFDE40 = 989423B8

root_Entry:
989423B8+ 0: *989423B8 = 00000080
989423B8+B8: *98942470 = 96DDD200

Traversing linked list:
96DDD198+68: *96DDD200 = 96DDD580
96DDD518+68: *96DDD580 = 98942470

1. element:
96DDD198+ 0: *96DDD198 = 02160001
96DDD198+28: *96DDD1C0 = 00000006
96DDD198+38: *96DDD1D0 = 00000000
96DDD198+50: *96DDD1E8 = 00000000
96DDD198+68: *96DDD200 = 96DDD580
96DDD198+70: *96DDD208 = 98942470

2. element:
96DDD518+ 0: *96DDD518 = 0216000E
96DDD518+28: *96DDD540 = 80000001
96DDD518+38: *96DDD550 = 96DDD198
96DDD518+50: *96DDD568 = 96DDD250
96DDD518+68: *96DDD580 = 98942470
96DDD518+70: *96DDD588 = 96DDD200

Explanation of some important locations:

- BCFFDE18 is the address of x$ksmsp.ksmchcom='dbgdInitEventGr'

- If the third least significant bit of element’s offset+28 is set to 1, the SQL will be traced. This means that the element 1 should trigger tracing in the example above.

- The offsets 38 and 50 should contain the pointers to the other element (see the element 2), but curiously for the first element they are not initialized:

96DDD198+38: *96DDD1D0 = 00000000

96DDD198+50: *96DDD1E8 = 00000000


After initializing the offset 0x50 for the first element with the values of the second element the tracing kicked in. (Of course, I did this only in the sandbox environment for experimental purposes.)

The question is, which one in the chain of dbgd functions and under which conditions is changing this location. This might give us a clue about a possible workaround.

The list above was produced with the following Perl program:

https://github.com/nenadnoveljic/oradb/blob/master/select_x_linked_events.pl

Nenad

http://nenadnoveljic.com/blog/
@NenadNoveljic



From: ***@poderc.com [mailto:***@poderc.com] On Behalf Of Tanel Poder
Sent: Donnerstag, 14. Dezember 2017 17:15
To: Noveljic Nenad
Cc: ORACLE-L (oracle-***@freelists.org)
Subject: Re: tracing specific sql_id in 12.2

Maybe there's some bug in 12.2 with event propagation when using ALTER SYSTEM, maybe a variation of what's described here:

https://blog.tanelpoder.com/2013/10/07/why-doesnt-alter-system-set-events-set-the-events-or-tracing-immediately/

... Although eventdump seems to show the event is enabled for the session too. Did you start session 2 before or after issuing ALTER SYSTEM in st?

If 12.2 happens to use the Multitenant config, perhaps test running the ALTER SYSTEM at the root CDB level...
--
Tanel Poder
http://blog.tanelpoder.com


On Tue, Dec 12, 2017 at 5:02 PM, Noveljic Nenad <***@vontobel.com<mailto:***@vontobel.com>> wrote:
Has somebody tried tracing a specific sql_id in Oracle 12.2? The feature doesn’t seem to work properly.

Here’s the test case:

Session 1:
alter system set events='sql_trace[sql: 2asugy1n1r7y7] level=12' ;
SQL> alter system set events='sql_trace[sql: 2asugy1n1r7y7] level=12' ;

System altered.


____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">p { font-family: Arial;font-size:9pt }</style>
</head>
<body>
<p>
<br>Important Notice</br>
<br>This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system.</br>
<br>E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of the Vontobel Group and its affiliates for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.<br/>
</p>
</body>
</html>
Stefan Koehler
2017-12-14 17:24:30 UTC
Permalink
Hey Nenad,
i am a little bit surprised to see that it works when you modify the link listed in the SGA as the events are copied to PGA (event propagation): https://twitter.com/OracleSK/status/899924819835277312

Did you modify the list before the event propagation code kicks in?

Best Regards
Stefan Koehler

Independent Oracle performance consultant and researcher
Website: http://www.soocs.de
Post by Noveljic Nenad
No multitenant, and tested with both new and existing 2. session. Most probably a bug - quite inconvenient.
BCFFDE18+28: *BCFFDE40 = 989423B8
989423B8+ 0: *989423B8 = 00000080
989423B8+B8: *98942470 = 96DDD200
96DDD198+68: *96DDD200 = 96DDD580
96DDD518+68: *96DDD580 = 98942470
96DDD198+ 0: *96DDD198 = 02160001
96DDD198+28: *96DDD1C0 = 00000006
96DDD198+38: *96DDD1D0 = 00000000
96DDD198+50: *96DDD1E8 = 00000000
96DDD198+68: *96DDD200 = 96DDD580
96DDD198+70: *96DDD208 = 98942470
96DDD518+ 0: *96DDD518 = 0216000E
96DDD518+28: *96DDD540 = 80000001
96DDD518+38: *96DDD550 = 96DDD198
96DDD518+50: *96DDD568 = 96DDD250
96DDD518+68: *96DDD580 = 98942470
96DDD518+70: *96DDD588 = 96DDD200
-       BCFFDE18 is the address of x$ksmsp.ksmchcom='dbgdInitEventGr'
-       If the third least significant bit of element’s offset+28 is set to 1, the SQL will be traced. This means that the element 1 should trigger tracing in the example above.
96DDD198+38: *96DDD1D0 = 00000000
96DDD198+50: *96DDD1E8 = 00000000
After initializing the offset 0x50 for the first element with the values of the second element the tracing kicked in. (Of course, I did this only in the sandbox environment for experimental purposes.)
The question is, which one in the chain of dbgd functions and under which conditions is changing this location. This might give us a clue about a possible workaround.
https://github.com/nenadnoveljic/oradb/blob/master/select_x_linked_events.pl
Nenad
http://nenadnoveljic.com/blog/
@NenadNoveljic
--
http://www.freelists.org/webpage/oracle-l
Noveljic Nenad
2017-12-14 20:18:39 UTC
Permalink
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.

2. 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


-----Original Message-----
From: Stefan Koehler [mailto:***@soocs.de]
Sent: Donnerstag, 14. Dezember 2017 18:25
To: Tanel Poder; Noveljic Nenad
Cc: ORACLE-L
Subject: RE: tracing specific sql_id in 12.2

Hey Nenad,
i am a little bit surprised to see that it works when you modify the link listed in the SGA as the events are copied to PGA (event propagation): https://twitter.com/OracleSK/status/899924819835277312

Did you modify the list before the event propagation code kicks in?

Best Regards
Stefan Koehler

Independent Oracle performance consultant and researcher
Website: http://www.soocs.de
Post by Noveljic Nenad
No multitenant, and tested with both new and existing 2. session. Most probably a bug - quite inconvenient.
BCFFDE18+28: *BCFFDE40 = 989423B8
989423B8+ 0: *989423B8 = 00000080
989423B8+B8: *98942470 = 96DDD200
96DDD198+68: *96DDD200 = 96DDD580
96DDD518+68: *96DDD580 = 98942470
96DDD198+ 0: *96DDD198 = 02160001
96DDD198+28: *96DDD1C0 = 00000006
96DDD198+38: *96DDD1D0 = 00000000
96DDD198+50: *96DDD1E8 = 00000000
96DDD198+68: *96DDD200 = 96DDD580
96DDD198+70: *96DDD208 = 98942470
96DDD518+ 0: *96DDD518 = 0216000E
96DDD518+28: *96DDD540 = 80000001
96DDD518+38: *96DDD550 = 96DDD198
96DDD518+50: *96DDD568 = 96DDD250
96DDD518+68: *96DDD580 = 98942470
96DDD518+70: *96DDD588 = 96DDD200
- BCFFDE18 is the address of x$ksmsp.ksmchcom='dbgdInitEventGr'
- If the third least significant bit of element’s offset+28 is set to 1, the SQL will be traced. This means that the element 1 should trigger tracing in the example above.
96DDD198+38: *96DDD1D0 = 00000000
96DDD198+50: *96DDD1E8 = 00000000
After initializing the offset 0x50 for the first element with the values of the second element the tracing kicked in. (Of course, I did this only in the sandbox environment for experimental purposes.)
The question is, which one in the chain of dbgd functions and under which conditions is changing this location. This might give us a clue about a possible workaround.
https://github.com/nenadnoveljic/oradb/blob/master/select_x_linked_events.pl
Nenad
http://nenadnoveljic.com/blog/
@NenadNoveljic
____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.

Important Notice
This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system.

E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of the Vontobel Group and its affiliates for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.
Stefan Koehler
2017-12-15 08:15:36 UTC
Permalink
Hey Nenad,
Post by Noveljic 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
Post by Noveljic Nenad
Hey Stefan,
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/
--
http://www.freelists.org/webpage/oracle-l
Tanel Poder
2017-12-14 22:03:06 UTC
Permalink
You've been having fun :-)

I geeked out a bit and tested this out too on 12.2 ... indeed, seeing the
same behavior. Also interesting that when using ALTER SYSTEM to disable
that event, it doesn't remove it from the other session (as far as
eventdump shows)... so it's telling that even the ALTER command/event
propagation doesn't seem to recognize this event being set (correctly) in
these secondary sessions.

--
Tanel Poder
http://blog.tanelpoder.com
Post by Noveljic Nenad
No multitenant, and tested with both new and existing 2. session. Most
probably a bug - quite inconvenient.
However, I’ve managed to reconstruct the doubly linked list, where the
BCFFDE18+28: *BCFFDE40 = 989423B8
989423B8+ 0: *989423B8 = 00000080
989423B8+B8: *98942470 = 96DDD200
Noveljic Nenad
2017-12-14 22:14:47 UTC
Permalink
You've been having fun :-)

ð Indeed: no bugs – less fun ☺ !

I geeked out a bit and tested this out too on 12.2 ... indeed, seeing the same behavior. Also interesting that when using ALTER SYSTEM to disable that event, it doesn't remove it from the other session (as far as eventdump shows)... so it's telling that even the ALTER command/event propagation doesn't seem to recognize this event being set (correctly) in these secondary sessions.

ð Are you also getting an ORA-0600 or ORA-07445 in some dbgd clean-up function? This would actually confirm a mess-up with the pointers in the linked list.

Thanks for looking at the problem!

Nenad
--
Tanel Poder
http://blog.tanelpoder.com<http://blog.tanelpoder.com/>

On Thu, Dec 14, 2017 at 6:48 PM, Noveljic Nenad <***@vontobel.com<mailto:***@vontobel.com>> wrote:

No multitenant, and tested with both new and existing 2. session. Most probably a bug - quite inconvenient.



However, I’ve managed to reconstruct the doubly linked list, where the system events are stored:



linked list ptr to root entry:

BCFFDE18+28: *BCFFDE40 = 989423B8



root_Entry:

989423B8+ 0: *989423B8 = 00000080

989423B8+B8: *98942470 = 96DDD200




____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">p { font-family: Arial;font-size:9pt }</style>
</head>
<body>
<p>
<br>Important Notice</br>
<br>This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system.</br>
<br>E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of the Vontobel Group and its affiliates for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.<br/>
</p>
</body>
</html>
Tanel Poder
2017-12-14 22:50:18 UTC
Permalink
Nope I didn't get any errors, maybe I wasn't trying hard enough ;-)

On Fri, Dec 15, 2017 at 12:14 AM, Noveljic Nenad <
Post by Noveljic Nenad
ð Are you also getting an ORA-0600 or ORA-07445 in some dbgd clean-up
function? This would actually confirm a mess-up with the pointers in the
linked list.
Ghassan Salem
2017-12-15 08:03:04 UTC
Permalink
This is bug 25989066 (and 25994378), fixed in 18.1, no backport to 12.2
available yet.

rgds

On Thu, Dec 14, 2017 at 11:14 PM, Noveljic Nenad <
Post by Tanel Poder
You've been having fun :-)
ð Indeed: no bugs – less fun J !
I geeked out a bit and tested this out too on 12.2 ... indeed, seeing the
same behavior. Also interesting that when using ALTER SYSTEM to disable
that event, it doesn't remove it from the other session (as far as
eventdump shows)... so it's telling that even the ALTER command/event
propagation doesn't seem to recognize this event being set (correctly) in
these secondary sessions.
ð Are you also getting an ORA-0600 or ORA-07445 in some dbgd clean-up
function? This would actually confirm a mess-up with the pointers in the
linked list.
Thanks for looking at the problem!
Nenad
--
Tanel Poder
http://blog.tanelpoder.com
On Thu, Dec 14, 2017 at 6:48 PM, Noveljic Nenad <
No multitenant, and tested with both new and existing 2. session. Most
probably a bug - quite inconvenient.
However, I’ve managed to reconstruct the doubly linked list, where the
BCFFDE18+28: *BCFFDE40 = 989423B8
989423B8+ 0: *989423B8 = 00000080
989423B8+B8: *98942470 = 96DDD200
____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
Important Notice
This message is intended only for the individual named. It may contain
confidential or privileged information. If you are not the named addressee
you should in particular not disseminate, distribute, modify or copy this
e-mail. Please notify the sender immediately by e-mail, if you have
received this message by mistake and delete it from your system.
E-mail transmission may not be secure or error-free as information could
be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also
processing of incoming e-mails cannot be guaranteed. All liability of the
Vontobel Group and its affiliates for any damages resulting from e-mail use
is excluded. You are advised that urgent and time sensitive messages should
not be sent by e-mail and if verification is required please request a
printed version.
Noveljic Nenad
2017-12-15 08:09:58 UTC
Permalink
Thank you for the information!

It would be nice if you could share more technical details. Unfortunately, the bug note has not been published on Metalink yet.

Do you know if the backport for 12.2 has been planned already?

Best,
Nenad

http://nenadnoveljic.com/blog/



From: Ghassan Salem [mailto:***@gmail.com]
Sent: Freitag, 15. Dezember 2017 09:03
To: Noveljic Nenad
Cc: Tanel Poder; ORACLE-L (oracle-***@freelists.org)
Subject: Re: tracing specific sql_id in 12.2

This is bug 25989066 (and 25994378), fixed in 18.1, no backport to 12.2 available yet.
rgds

On Thu, Dec 14, 2017 at 11:14 PM, Noveljic Nenad <***@vontobel.com<mailto:***@vontobel.com>> wrote:
You've been having fun :-)

=> Indeed: no bugs – less fun ☺ !

I geeked out a bit and tested this out too on 12.2 ... indeed, seeing the same behavior. Also interesting that when using ALTER SYSTEM to disable that event, it doesn't remove it from the other session (as far as eventdump shows)... so it's telling that even the ALTER command/event propagation doesn't seem to recognize this event being set (correctly) in these secondary sessions.

=> Are you also getting an ORA-0600 or ORA-07445 in some dbgd clean-up function? This would actually confirm a mess-up with the pointers in the linked list.

Thanks for looking at the problem!

Nenad
--
Tanel Poder
http://blog.tanelpoder.com<http://blog.tanelpoder.com/>

On Thu, Dec 14, 2017 at 6:48 PM, Noveljic Nenad <***@vontobel.com<mailto:***@vontobel.com>> wrote:

No multitenant, and tested with both new and existing 2. session. Most probably a bug - quite inconvenient.



However, I’ve managed to reconstruct the doubly linked list, where the system events are stored:



linked list ptr to root entry:

BCFFDE18+28: *BCFFDE40 = 989423B8



root_Entry:

989423B8+ 0: *989423B8 = 00000080

989423B8+B8: *98942470 = 96DDD200




____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.

Important Notice
This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system.
E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of the Vontobel Group and its affiliates for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.


<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">p { font-family: Arial;font-size:9pt }</style>
</head>
<body>
<p>
<br>Important Notice</br>
<br>This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system.</br>
<br>E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of the Vontobel Group and its affiliates for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.<br/>
</p>
</body>
</html>
Noveljic Nenad
2018-09-25 12:39:49 UTC
Permalink
Oracle fixed the bug in 18c (tested against 18.3.0.0.180717)

Best regards,

Nenad

https://nenadnoveljic.com/



From: Noveljic Nenad
Sent: Freitag, 15. Dezember 2017 09:10
To: 'Ghassan Salem'
Cc: Tanel Poder; ORACLE-L (oracle-***@freelists.org)
Subject: RE: tracing specific sql_id in 12.2

Thank you for the information!

It would be nice if you could share more technical details. Unfortunately, the bug note has not been published on Metalink yet.

Do you know if the backport for 12.2 has been planned already?

Best,
Nenad

http://nenadnoveljic.com/blog/



From: Ghassan Salem [mailto:***@gmail.com]
Sent: Freitag, 15. Dezember 2017 09:03
To: Noveljic Nenad
Cc: Tanel Poder; ORACLE-L (oracle-***@freelists.org)
Subject: Re: tracing specific sql_id in 12.2

This is bug 25989066 (and 25994378), fixed in 18.1, no backport to 12.2 available yet.
rgds

On Thu, Dec 14, 2017 at 11:14 PM, Noveljic Nenad <***@vontobel.com<mailto:***@vontobel.com>> wrote:
You've been having fun :-)

=> Indeed: no bugs – less fun ☺ !

I geeked out a bit and tested this out too on 12.2 ... indeed, seeing the same behavior. Also interesting that when using ALTER SYSTEM to disable that event, it doesn't remove it from the other session (as far as eventdump shows)... so it's telling that even the ALTER command/event propagation doesn't seem to recognize this event being set (correctly) in these secondary sessions.

=> Are you also getting an ORA-0600 or ORA-07445 in some dbgd clean-up function? This would actually confirm a mess-up with the pointers in the linked list.

Thanks for looking at the problem!

Nenad
--
Tanel Poder
http://blog.tanelpoder.com<http://blog.tanelpoder.com/>

On Thu, Dec 14, 2017 at 6:48 PM, Noveljic Nenad <***@vontobel.com<mailto:***@vontobel.com>> wrote:

No multitenant, and tested with both new and existing 2. session. Most probably a bug - quite inconvenient.



However, I’ve managed to reconstruct the doubly linked list, where the system events are stored:



linked list ptr to root entry:

BCFFDE18+28: *BCFFDE40 = 989423B8



root_Entry:

989423B8+ 0: *989423B8 = 00000080

989423B8+B8: *98942470 = 96DDD200




____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.

Important Notice
This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system.
E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of the Vontobel Group and its affiliates for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.


<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">p { font-family: Arial;font-size:9pt }</style>
</head>
<body>
<p>
<br>Important Notice</br>
<br />
This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system.<br />
Without prejudice to any contractual agreements between you and us which shall prevail in any case, we take it as your authorization to correspond with you by e-mail if you send us messages by e-mail. However, we reserve the right not to execute orders and instructions transmitted by e-mail at any time and without further explanation.<br />
E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of Vontobel Holding Ltd. and any of its affiliates (hereinafter collectively referred to as "Vontobel Group") for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.</br>
Please note that all e-mail communications to and from the Vontobel Group are subject to electronic storage and review by Vontobel Group. Unless stated to the contrary and without prejudice to any contractual agreements between you and Vontobel Group which shall prevail in any case, e-mail-communication is for informational purposes only and is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction.<br />
The legal basis for the processing of your personal data is the legitimate interest to develop a commercial relationship with you, as well as your consent to forward you commercial communications. You can exercise, at any time and under the terms established under current regulation, your rights. If you prefer not to receive any further communications, please contact your client relationship manager if you are a client of Vontobel Group or notify the sender.
Please note for an exact reference to the affected group entity the corporate e-mail signature.
For further information about data privacy at Vontobel Group please consult <a href="https://www.vontobel.com">www.vontobel.com</a>.<br />
</p>
</body>
</html>
Loading...