RE: Direct SGA access problem because of structs' changing start address
- From: Jonathan Lewis <jonathan@xxxxxxxxxxxxxxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 8 Jan 2014 22:34:18 +0000
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
@jloracle
________________________________
From: keydana@xxxxxx [keydana@xxxxxx]
Sent: 08 January 2014 22:06
To: oracle-l@xxxxxxxxxxxxx
Cc: Jonathan Lewis; frits.hoogland@xxxxxxxxx
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
Other related posts:
