SQL > select kqfdtequ from x$kqfdt where kqfdtnam = 'X$KGLCURSOR ';
KQFDTEQU
-- ---- ---- ---- ---- ---- --
X$KGLOB <--- this means that x$kglcursor actually uses the same memory
structure as x$kglob (but can shows different elements/columns of it)
The next query shows us the physical memory offsets X$ table columns
representing elements in fixed arrays:
SQL > select t.kqftanam, c.kqfconam, c.kqfcotab, c.kqfcotyp, c.kqfcosiz,
c.kqfcolof
2 from x$kqfta t, x$kqfco c
3 where t.indx = c.kqfcotab
4 and c.kqfconam in ( 'KSUSEAPP ', 'KGLOBTS0 ');
KQFCOTYP = 3 shows that these columns are raw string type, not a pointer to
anywhere, thus they are stored within given memory structures (kglob for
library cache objects), not somewhere else. Just to check:
SQL > select addr, kglobts0 from x$kglob where kglobts0 is not null and
rownum < 5;
Also, as you see from following queries, the session and library cache
elements are allocated from totally different memory regions, so there is no
sharing of common information (derived tables can reference to data
structures in shared manner, but only to different columns within the same
data structure (as I understand))..
This is actually perfectly reasonable, because if there was a common memory
location for MODULE and ACTION for both sessions and library cache, then
what should happen to module and action values in cached cursors when
session sets a new module/action and parses a new query? The old
module/action values must not change, thus have to be stored independently
in different locations, for each child cursor separately.
Now this overhead is much more important than the session array effect I
thought of at first :)
