Oracle X$ tables – Part 1 – Where do they get their data f
Oracle X$ tables – Part 1 – Where do they get their data from? by Tanel Poder Posted on January 10, 2014 It’s long-time public knowledge that X$ fixed tables in Oracle are just “windows” into Oracle’s memory. So whenever you query an
Oracle X$ tables – Part 1 – Where do they get their data from?
by
Tanel Poder
Posted on
January 10, 2014
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 <strong>391513C4</strong> 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 <strong>391513C4</strong> 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 --- -------- ---------- ---------- ---------------- ---------- -------- ---------- -------- <span><strong>SGA</strong></span> 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 <strong>F692347C</strong> 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 <strong>F692347C</strong> 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 --- -------- ---------- ---------- ---------------- ---------- -------- ---------- -------- <span><strong>UGA</strong></span> F6922EE8 <strong>kxsFrame4kPage</strong> 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 <strong>F69254B4</strong> 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 <strong>F692B508</strong> 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.
Related Posts
- Where is LOB data stored?
- Profiling trace files with preprocessor external tables in 11g and some parallel execution hacking
- Oracle In-Memory Column Store Internals – Part 1 – Which SIMD extensions are getting…
- Oracle Exadata Performance series – Part 1: Should I use Hugepages on Linux Database Nodes?
- When do Oracle Parallel Execution Slaves issue buffered physical reads – Part 2?

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics



To query the Oracle tablespace size, follow the following steps: Determine the tablespace name by running the query: SELECT tablespace_name FROM dba_tablespaces; Query the tablespace size by running the query: SELECT sum(bytes) AS total_size, sum(bytes_free) AS available_space, sum(bytes) - sum(bytes_free) AS used_space FROM dba_data_files WHERE tablespace_

Data import method: 1. Use the SQLLoader utility: prepare data files, create control files, and run SQLLoader; 2. Use the IMP/EXP tool: export data, import data. Tip: 1. Recommended SQL*Loader for big data sets; 2. The target table should exist and the column definition matches; 3. After importing, data integrity needs to be verified.

Uninstall method for Oracle installation failure: Close Oracle service, delete Oracle program files and registry keys, uninstall Oracle environment variables, and restart the computer. If the uninstall fails, you can uninstall manually using the Oracle Universal Uninstall Tool.

Oracle provides multiple deduplication query methods: The DISTINCT keyword returns a unique value for each column. The GROUP BY clause groups the results and returns a non-repetitive value for each group. The UNIQUE keyword is used to create an index containing only unique rows, and querying the index will automatically deduplicate. The ROW_NUMBER() function assigns unique numbers and filters out results that contain only line 1. The MIN() or MAX() function returns non-repetitive values of a numeric column. The INTERSECT operator returns the common values of the two result sets (no duplicates).

Oracle View Encryption allows you to encrypt data in the view, thereby enhancing the security of sensitive information. The steps include: 1) creating the master encryption key (MEk); 2) creating an encrypted view, specifying the view and MEk to be encrypted; 3) authorizing users to access the encrypted view. How encrypted views work: When a user querys for an encrypted view, Oracle uses MEk to decrypt data, ensuring that only authorized users can access readable data.

Use the ALTER TABLE statement, the specific syntax is as follows: ALTER TABLE table_name ADD column_name data_type [constraint-clause]. Where: table_name is the table name, column_name is the field name, data_type is the data type, and constraint-clause is an optional constraint. Example: ALTER TABLE employees ADD email VARCHAR2(100) Add an email field to the employees table.

There are three ways to view instance names in Oracle: use the "sqlplus" and "select instance_name from v$instance;" commands on the command line. Use the "show instance_name;" command in SQL*Plus. Check environment variables (ORACLE_SID on Linux) through the operating system's Task Manager, Oracle Enterprise Manager, or through the operating system.

Creating an Oracle table involves the following steps: Use the CREATE TABLE syntax to specify table names, column names, data types, constraints, and default values. The table name should be concise and descriptive, and should not exceed 30 characters. The column name should be descriptive, and the data type specifies the data type stored in the column. The NOT NULL constraint ensures that null values are not allowed in the column, and the DEFAULT clause specifies the default values for the column. PRIMARY KEY Constraints to identify the unique record of the table. FOREIGN KEY constraint specifies that the column in the table refers to the primary key in another table. See the creation of the sample table students, which contains primary keys, unique constraints, and default values.
