AWR reports DBMS_ALERT_INFO queries using significant elapsed time

Question

Hi
10.1.0.3 / OpenVMS 8.2
Has anyone encountered AWR reporting significant resource consumption on queries relating to DBMS_ALERT_INFO (via calls to dbms_alert.register)? The buffer busy waits % from AWR is high as well (see AWR snippets below). Oracle are suggesting this is "expected behaviour for the objects owned by
the SYS user".
The query takes (on average) 2.3 seconds elapsed, using 1.63 CPU seconds and is responsible for 94% of all Buffer Busy Waits.
Elapsed CPU Elap per % Total
Time (s) Time (s) Executions Exec (s) DB Time SQL Id
10,965 7,746 4,756 2.3 4.7 57w71dgk5qbtx
Module: DSA103:[CSC_ENV_1.APPLIC.][SPICE.LIB]SPC_PFS1_MA
SELECT DISTINCT SUBSTR(KGLNAOBJ,11) SID FROM X$KGLOB WHERE KGLHDNSP = 7 AND KGLN
AOBJ LIKE 'ORA$ALERT$%' AND BITAND(KGLHDFLG,128)!=0 UNION SELECT DISTINCT SID FR
OM DBMS_ALERT_INFO
Segments by Buffer Busy Waits DB/Inst: SPICE/ONLINE Snaps: 4930-5026
Buffer
Tablespace Subobject Obj. Busy
Owner Name Object Name Name Type Waits %Total
SYS SYSTEM DBMS_ALERT_INFO TABLE 130,626 93.76
Clive

Answer 1

Christophe Lize wrote:
Closing this thread even if it's not answered...Sorry, I don't have time to test this myself now, but you shouldn't mark this thread as answered if it is not, because other people might find it and think they find an answer if they have a similar question.
I suggest you try the following to narrow down things:
1. Open the RAW trace file and check the cursor numbers of the "direct path reads" - check if you can find any references for those cursor numbers manually. The cursor numbers are those numbers behind the WAIT #<xx>, and you can check if you find any other entry unequal to WAIT #<xx> with the same #<xx>, for example EXEC #<xx> or FETCH #<xx>
A short primer on how to interpret the raw trace file can also be found in MOS document 39817.1
2. Run the RAW trace file through alternative free trace file analyzers like SQLDeveloper (yes it can process raw trace files), OraSRP or Christian Antognini's TVD$XTAT. If you have My Oracle Support access you can also try Oracle's own extended Trace Analyzer (TRCA / TRCANLZR). See MOS Note 224270.1
Check if these tools tell you more about your specific wait event and oddities with the trace file in general.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
Co-author of the "OakTable Expert Oracle Practices" book:
http://www.apress.com/book/view/1430226684
http://www.amazon.com/Expert-Oracle-Practices-Database-Administration/dp/1430226684