The primary point of directly reading shared memory is that by doing so you bypass Oracle. So when the entire instance hangs and will not grant new connections you can go around the problem and see what is happening (or not happening as the case may be). You also avoid the latching overhead required for accessing the shared memory structures via Oracle. True, you may see some inconsistent data, but you will see it.HTH -- Mark D Powell --
From: email@example.com [mailto: firstname.lastname@example.org] On Behalf Of Allen, Brandon
Sent: Monday, August 21, 2006 12:25 PM
To: email@example.com; firstname.lastname@example.org; email@example.com
Cc: Oracle Discussion List
Subject: RE: reading the SGA from my own program
Please forgive my ignorance, but what is the point of this direct SGA access anyway? Why not just query v$session_event and/or v$session_wait, or the underlying x$ tables?Thanks,Brandon
From: firstname.lastname@example.org [mailto: email@example.com] On Behalf Of Tanel Poder
Sent: Saturday, August 19, 2006 2:30 AM
Cc: firstname.lastname@example.org; 'Oracle Discussion List'
Subject: RE: reading the SGA from my own programAlso, if all you're interested in is the current wait state of a session, then there's no real fundamental need to map those SHM segments which do not contain the data you're interested in (as far as I understand).Tanel.. . .
I am trying to play around with reading the SGA using my own program, as popularized by Kyle Hailey and Miladin Modrakovic's papers and presentations. I am confused about where to find x$ksusecst (session wait) and other items in the fixed area.
Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.