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

From: <keydana_at_gmx.de>
Date: Wed, 8 Jan 2014 23:06:51 +0100
Message-Id: <A76B22B2-514E-4AC6-BAA1-1D8F5FAA8230_at_gmx.de>

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:06:51 CET