Oracle X$ tables – Part 1 – Where do they get their data from?

It’s long-time public knowledge that X$ fixed tables in Oracle are just “windows” into Oracle’s memory. So whenever you query an X$ table, the FIXED TABLE rowsource function in your SQL execution plan will just read some memory structure, parse its output and show you the results in tabular form. This is correct, but not the whole truth.

Check this example. Let’s query the X$KSUSE table, which is used by V$SESSION:

SQL> SELECT addr, indx, ksuudnam FROM x$ksuse WHERE rownum <= 5;

ADDR           INDX KSUUDNAM
-------- ---------- ------------------------------
391513C4          1 SYS
3914E710          2 SYS
3914BA5C          3 SYS
39148DA8          4 SYS
391460F4          5 SYS

Now let’s check in which Oracle memory region this memory address resides (SGA, PGA, UGA etc). I’m using my script fcha for this (Find CHunk Address). You should probably not run this script in busy production systems as it uses the potentially dangerous X$KSMSP fixed table:

SQL> @fcha 391513C4
Find in which heap (UGA, PGA or Shared Pool) the memory address 391513C4 resides...

WARNING!!! This script will query X$KSMSP, which will cause heavy shared pool latch contention
in systems under load and with large shared pool. This may even completely hang
your instance until the query has finished! You probably do not want to run this in production!

Press ENTER to continue, CTRL+C to cancel...

LOC KSMCHPTR   KSMCHIDX   KSMCHDUR KSMCHCOM           KSMCHSIZ KSMCHCLS   KSMCHTYP KSMCHPAR
--- -------- ---------- ---------- ---------------- ---------- -------- ---------- --------
SGA 39034000          1          1 permanent memor     3977316 perm              0 00

SQL>

Ok, these X$KSUSE (V$SESSION) records reside in a permanent allocation in SGA and my X$ query apparently just parsed & presented the information from there.

Now, let’s query something else, for example the “Soviet Union” view X$KCCCP:

SQL> SELECT addr, indx, inst_id, cptno FROM x$kcccp WHERE rownum <= 5;

ADDR           INDX    INST_ID      CPTNO
-------- ---------- ---------- ----------
F692347C          0          1          1
F692347C          1          1          2
F692347C          2          1          3
F692347C          3          1          4
F692347C          4          1          5

Ok, let’s see where do these records reside:

SQL> @fcha F692347C
Find in which heap (UGA, PGA or Shared Pool) the memory address F692347C resides...

WARNING!!! This script will query X$KSMSP, which will cause heavy shared pool latch contention
in systems under load and with large shared pool. This may even completely hang
your instance until the query has finished! You probably do not want to run this in production!

Press ENTER to continue, CTRL+C to cancel...

LOC KSMCHPTR   KSMCHIDX   KSMCHDUR KSMCHCOM           KSMCHSIZ KSMCHCLS   KSMCHTYP KSMCHPAR
--- -------- ---------- ---------- ---------------- ---------- -------- ---------- --------
UGA F6922EE8                       kxsFrame4kPage         4124 freeabl           0 00

SQL>

Wow, why does the X$KCCCP data reside in my session’s UGA? This is where the extra complication (and sophistication) of X$ fixed tables comes into play!

Some X$ tables do not simply read whatever is in some memory location, but they have helper functions associated with them (something like fixed packages that the ASM instance uses internally). So, whenever you query this X$, then first a helper function is called, which will retrieve the source data from whereever it needs to, then copies it to your UGA in the format corresponding to this X$ and then the normal X$ memory location parsing & presentation code kicks in.

If you trace what the X$KCCCP access does – you’d see a bunch of control file parallel read wait events every time you query the X$ table (to retrieve the checkpoint progress records). So this X$ is not doing just a passive read only presentation of some memory structure (array). The helper function will first do some real work, allocates some runtime memory for the session (the kxsFrame4kPage chunk in UGA) and copies the results of its work to this UGA area – so that the X$ array & offset parsing code can read and present it back to the query engine.

In other words, the ADDR column in X$ tables does not necessarily show where the source data it shows ultimately lives, but just where the final array that got parsed for presentation happened to be. Sometimes the parsed data structure is the ultimate source where it comes from, sometimes a helper function needs to do a bunch of work (like taking latches and walking linked lists for X$KSMSP or even doing physical disk reads from controlfiles for X$KCCCP access).

And more, let’s run the same query against X$KCCCP twice:

SQL> SELECT addr, indx, inst_id, cptno FROM x$kcccp WHERE rownum <= 5;

ADDR           INDX    INST_ID      CPTNO
-------- ---------- ---------- ----------
F69254B4          0          1          1
F69254B4          1          1          2
F69254B4          2          1          3
F69254B4          3          1          4
F69254B4          4          1          5

And once more:

SQL> SELECT addr, indx, inst_id, cptno FROM x$kcccp WHERE rownum <= 5;

ADDR           INDX    INST_ID      CPTNO
-------- ---------- ---------- ----------
F692B508          0          1          1
F692B508          1          1          2
F692B508          2          1          3
F692B508          3          1          4
F692B508          4          1          5

See how the ADDR column has changed between executions even though we are querying the same data! This is not because the controlfiles or the source data have somehow relocated. It’s just that the temporary cursor execution scratch area, where the final data structure was put for presentation (kxsFrame4kPage chunk in UGA), just happened to be allocated from different locations for the two different executions.

There may be exceptions, but as long as the ADDR resides in SGA, I’d say it’s the actual location of where the data lives – but when it’s in UGA/PGA, it may be just the temporary cursor scratch area and the source data was taken from somewhere else (especially when the ADDR constantly changes or alternates between 2-3 different variants when repeatedly running your X$ query). Note that there are X$ tables which intentionally read data from arrays in your UGA (the actual source data lives in the UGA or PGA itself), but more about that in the future.

This entry was posted in Oracle. Bookmark the permalink.

11 Responses to Oracle X$ tables – Part 1 – Where do they get their data from?

  1. Hi Tanel,

    Interesting post. So, this implies that for some X$ tables, (such as X$KCCCP), the ‘standard’ way of doing direct SGA attach memory access will not work, correct?

    -Mark

  2. olivier says:

    Tanel,
    is there any way to access memory structures without having to go through the sql engine ?
    Can we imagine having a C program attaching to SGA and reading (never writing, just read only access) information directly from SGA
    without having to go through latching/mutex protection stuctures ?
    Thanks
    Olivier

    • Tanel Poder says:

      Yep, there are plenty of tools that already do this (including Oracle’s libdsga used by OEM). Google for Direct SGA Access. When you read data structures potentially in-flux (as you should not take any latches nor write to SGA), your code should handle potential data corruption / inconsistent memory read situations.

  3. vikram rathour says:

    Hi Tanel,
    I have always followed your blogs. Thanks for sharing.
    However, it’s very difficult to find information of x$ views and description about them or their colums. Could you help if there is any source for this information.

    Thanks,
    Vikram

  4. Hi Tanel,

    Instead of query or fetching from x$tables, I hope we can get the shared memory address from sysresv, if we code kernel module and insmod to Linux kernel. It would enable us to fetch information at runtime (in-parallel to cpu/oracle process). Only we should make sure that we should pickup or pass on arguments to our custom module.
    I was trying to fetch in that way (from Operating System perspective), but unsuccessful, but getting shared memory from OS layer is bit difficult.

    - Thanks
    Pavan Kumar N

    • Tanel Poder says:

      No need to install any kernel mods, you can just mmap() the SGA segment to your process address space (you can use pmap or /proc/PID/maps to find the correct segments) and read the memory as if it was yours. That’s how all those direct SGA attach tools are doing it (google for “oracle direct SGA attach” for examples). But as I explained, some X$ tables require sophisticated code to walk through data structures, linked lists etc, before they produce data for reading by the X$ presentation code.

  5. Jun He says:

    Tanel, what’s x$ table for v$logmnr_content ? Also what does indx field from x$ksuse do ?

    • Tanel Poder says:

      Jun He, it’s x$logmnr_contents (you can use v$fixed_view_definition view or my v.sql script to query v$ view definitions – or just select from the v$ and check the execution plan).

      The INDX field in X$ tables is the sequence number of the fixed array element returned. So for X$KSUSE where the data is read directly from the ultimate source (without copying to UGA first), the INDX is the slot number of the X$KSUSE array. And the V$SESSION view shows it as “SID”. Similarly, the INDX in X$KSUPR is the Oracle PID column in V$PROCESS.

  6. Vini says:

    I’m using DBA_AUDIT_TRAIL to get a weekly report of users that connected to the DB. The AUD$ table doesn’t have the ksusepnm column (or PROGRAM in V$SESSION).
    As x$ksuse gets data directly from memory, and, apparently trail auditing is not storing this specific field – Is there a way to retrieve the program name, the same used in v$session, using audit trail?

    Thanks,

    Vini

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>