The package dbms_application_info lets you add supplemental information in your session, which can be picked up in the V$SESSION view.
A very useful package, which I have used many times myself, but for some reason it is rarely used by Developers. It should typically be called before beginning a transaction in order to register and name a transaction/client_info/module for later use when measuring performance across an application.
exec dbms_application_info.set_client_info('Step one.'); exec dbms_application_info.set_module('module1','gettrades');
Here is an example where I was troubleshooting a "hanging" delete statement for a customer.
Turned out the problem was concurrency locks:
select SID,SERIAL#,SQL_ID,STATUS,osuser,machine,schemaname,MODULE,ACTION,CLIENT_INFO,LOGON_TIME,EVENT,STATE,FINAL_BLOCKING_SESSION "blocking" from v$session WHERE schemaname='SALES' AND STATUS='ACTIVE' UNION select SID,SERIAL#,SQL_ID,STATUS,osuser,machine,schemaname,MODULE,ACTION,CLIENT_INFO,LOGON_TIME,EVENT,STATE,FINAL_BLOCKING_SESSION "blocking" from v$session where SID = (SELECT FINAL_BLOCKING_SESSION FROM V$SESSION WHERE schemaname='SALES' AND STATUS='ACTIVE');
In the resulting two rows, the first one is mine, the second is the blocking session:
SID | SERIAL# | SQL_ID | STATUS | OSUSER | MACHINE | SCHEMANAME | MODULE | ACTION | CLIENT_INFO | LOGON_TIME | EVENT | STATE | blocking |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 | 4759 | 5jg1839cyxzgh | ACTIVE | oracle | mytestserver.com | SALES | DELETE MODULE | DELETE_SCHEMA | Delete XSD. | 15.02.2018 12:04:43 | library cache lock | WAITING | 2285 |
2285 | 48625 | g3bc37vx8fy3u | INACTIVE | JIM | COMPANY\PC-157 | SALES | SQL*Plus | 14.02.2018 14:08:57 | SQL*Net message from client | WAITING | NULL |
For more information, check the documentation
Tracing Enhancements Using DBMS_MONITOR (In 10g, 11g and Above) (Doc ID 293661.1) at My Oracle Support.
No comments:
Post a Comment