RE: Direct SGA access problem because of structs' changing start address

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Wed, 8 Jan 2014 22:34:18 +0000
Message-ID: <CE70217733273F49A8A162EE074F64D901DD5A43_at_exmbx05.thus.corp>

Yes, addr is an address is private memory - the lag on addr is 88 bytes which is the size of an element of x$ksmsp (on recent 64-bit systems), although you will find larger jumps can appear every 46 rows because the array has been segmented into chunks of about 4KB.

The lag on ksmchptr is the size of the chunk allocated in the shared pool.

The point of comparing addr to the min/max ksmchptr was to show that x$ksmsp wasn't in the shared pool anywhere.

The shared pool is contained in a number of memory granules, and includes things like the library cache and dictionary cache (among lots of other areas) - if you want to scan the shared pool you could walk the x$ksmsp array in order to identify chunks - but there is no coherent meaning in an ordered list of chunks (and a single object in the shared pool could be made of many scattered chunks). If you want some information from the shared pool you need to follow pointers to be able to build objects, and build lists of similar objects (e.g. a list of all the dc_tables objects). I was thinking of the latter approach when I mentioned linked lists.

You might find "Oracle Core" a useful book to read if you want more details - I don't know if it answers exactly the questions you want answered, and it certainly doesn't tell you how to find the start of the shared pool (either in sequence of chunk allocation or as linked lists).

Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
_at_jloracle

---

From: keydana_at_gmx.de [keydana_at_gmx.de] Sent: 08 January 2014 22:06
To: oracle-l_at_freelists.org
Cc: Jonathan Lewis; frits.hoogland_at_gmail.com Subject: Re: Direct SGA access problem because of structs' changing start address

Hi Jonathan, & hi Frits & all,

thanks a lot, but could you please elaborate? In fact when I query

select min(KSMCHPTR), max(KSMCHPTR), min(addr), max(addr) from x$ksmsp;

from different sessions and in different instances, really the min(KSMCHPTR) and max(KSMCHPTR) seem to be constant... Does this mean the ADDR reflects private process memory locations, and the KSMCHPTR, the shared memory addresses I want to read from?

Extending the query I was using to get the row size,

select addr,

       to_number(rawtohex(addr), 'XXXXXXXXXXXXXXXX') decaddr,
       abs(to_number(rawtohex(addr), 'XXXXXXXXXXXXXXXX') - to_number(rawtohex(lag(addr) over (order by addr)), 'XXXXXXXXXXXXXXXX')) itemsize,
       ksmchptr,
       to_number(rawtohex(KSMCHPTR), 'XXXXXXXXXXXXXXXX') decptr,
       abs(to_number(rawtohex(KSMCHPTR), 'XXXXXXXXXXXXXXXX') - to_number(rawtohex(lag(KSMCHPTR) over (order by KSMCHPTR)), 'XXXXXXXXXXXXXXXX'))   ptrsize

from x$ksmsp
order by KSMCHPTR
fetch next 10 rows only;

ADDR DECADDR ITEMSIZE KSMCHPTR DECPTR PTRSIZE

---------------- ------------------------ ---------- ---------------- ---------- ----------

00007F182EC44308 139741840556808 88 0000000062000058 1644167256 00007F182EC44360 139741840556896 88 00000000620000B0 1644167344 88 00007F182EC443B8 139741840556984 88 00000000620000E0 1644167392 48 00007F182EC44410 139741840557072 88 00000000620CCFD0 1645006800 839408 00007F182EC44468 139741840557160 88 00000000620CD000 1645006848 48 00007F182EC444C0 139741840557248 88 0000000062A95A88 1655265928 10259080

00007F182EC44518  139741840557336  88 0000000062A96A88 1655270024       4096
00007F182EC44570  139741840557424  88 0000000062A97A88 1655274120       4096
00007F182EC445C8  139741840557512  88 0000000062A98A88 1655278216       4096
00007F182EC44620  139741840557600  88 0000000062A99A88 1655282312       4096

... on the other hand, I think I misunderstood, this looks more like the lag in ksmchptr reflects the actual chunk size, so this won't probably be what I need to read...

Sorry I'm confused, but it's the first time I'm looking into this... As for x$ksmfsv, this looks like variable locations and their types, but how could I make use of that?

It would be great if you could take the time to explain a little further. To be honest I don't understand, either,

"find the linked list that connects all the items in the shared pool"

... I thought that while LRU list and free list(s) are linked lists running through the shared pool, with x$ksmsp I'd just be reading, kind of, sequentially from memory, like in a dump - or does it represent yet another linked list?

Thanks a lot, again,
Sigrid

>> x$ksmsp looks like a segmented array dynamically created in your session
>> memory. (Check the addr value against the min() and max() ksmchptr.)
>> You need some other way to find the linked list that connects all the items in
>> the shared pool - which probably means checking the right variables in x$ksmfsv

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

Received on Wed Jan 08 2014 - 23:34:18 CET