Knowledge

X$Tables

Introduction

Oracle database administrators involved in database analysis in general use queries based on the V$Views. These so called performance views are build mostly on X$Tables.
The X$Tables represent the internal C data structures of an Oracle database and make them readable from the outside. In the following, the structure of the Oracle SGA and the most important X$Tables needed for further analysis are introduced.

SGA Structure

SGA is an abbreviation for "Shared Global Area". As the name suggests, it deals with all the shared memory area of the processes (Unix) as well as threads (Windows). The SGA is created during the startup of an Oracle instance, as long as it takes place in the "NoMount" state and contains all of the necessary data for the operation. An Oracle instance is consistent with the sum of the process, as well as threads and the SGA. SGA steht als Abkürzung für „Shared Global Area“. Wie der Name bereits nahelegt, handelt es sich dabei um einen zwischen allen Prozessen (Unix), bzw. Threads (Windows) geteilten Speicherbereich.

Dieser wird bei dem Starten einer Oracleinstanz angelegt, solange sich diese noch im Zustand „NoMount“ befindet und enthält alle zum Betrieb notwendigen Daten. Eine Oracleinstanz entspricht der Summe der Prozesse, bzw. Threads und der SGA.

The allocation of through the parameter SGA_MAX_SIZE limits the storage capacity from the top and is dependent upon the Oracle version and the already existing operating systems at the start of the instance (in general, Windows-based systems) or appropriate to the current requirements during the runtime (in general, on Unix-based systems). The connected storage capacity allocated in one step is shown as a "Granule." The size of a granule depends either on the Oracle version, the operating system, or the value of SGA_MAX_SIZE. In Oracle 9i, a granule of < 128 Mb has a size of 4Mb, otherwise it is 16 Mb. In Oracle 10g, the limit for the use of 4Gb granules is 1 Gb and, depending on the operating system 8Mb (Windows) or 16 Mb (Unix), respectively. Die Allokierung der durch den Parameter SGA_MAX_SIZE nach oben hin beschränkten Speichermenge erfolgt in Abhängigkeit der Oracleversion und des verwendeten Betriebssystems bereits vollständig während des Starts der Instanz (i.A. bei windowsbasierten Systemen) oder entsprechend des aktuellen Bedarfs während der Laufzeit (i.A. bei unixbasierten Systemen).

Die in einem Schritt allokierte zusammenhängende Speichermenge wird als „Granule“ bezeichnet. Die Größe einer Granule hängt dabei wieder von der Oracleversion, dem Betriebssystem und dem Wert von SGA_MAX_SIZE ab. Unter Oracle 9i hatte eine Granule bei <128MB eine Größe von 4MB, sonst 16 MB. Unter Oracle 10g lag die Grenze für die Verwendung von 4GB Granulen bei 1GB und darüberhinaus in Abhängigkeit des Betriebssystems bei 8MB (Windows), bzw. 16MB (Unix).

The major areas of an SGA are: * Buffer Pool – Default/Keep/Recycle-Buffer, n-Size Blockbuffer (n = 2,4,8,16,32KB) * Shared Pool – Library Cache * Shared SQL-Area * Private SQL-Area (only on a shared server) * PL/SQL Procedures * Library Cache Handles – Dictionary Cache (Row Cache) – Control structures (Latches & Enques) * Redo Buffer * Large Pool (direct Path I/O, RMAN) * Java Pool * Streams Pool * Fixed Area (internal SGA references)

  • Buffer Pool
    – Default/Keep/Recycle-Buffer, n-Size Blockbuffer (n = 2,4,8,16,32KB)
  • Shared Pool
    – Library Cache
  • Shared SQL-Bereiche
  • Private SQL-Bereiche (nur bei Shared Server)
  • PL/SQL Prozeduren
  • Library Cache Handles
    – Dictionary Cache (Row Cache)
    – Kontrollstrukturen (Latches & Enques)
  • Redo Buffer
  • Large Pool (direct Path I/O, RMAN)
  • Java Pool
  • Streams Pool
  • Fixed Area (Referenzen SGA intern)

Each is comprised of at least one granule. This serves, in particular, for each individual of the buffer pools, insofar as this storage is allocated. Should a conflict with the SHARED_POOL_SIZE be encountered, this will be ignored. The granules within a pool are bound with each other in the form of a double linked list. As the beginning and end reference, an imaginary granule number "0" will be referenced. Should the size of a pool not be a multiple of the granule size, then it will internally be rounded up appropriately. The first granule contains an array with a determined size, which contains a reference to all granules. This also clarifies the necessity of the different sizes of the used granules dependent upon the SGA sizings. Next to the references to all the granules, the first granule also contains the so-called "fixed area." In the fixed area, all SGA internal variables, SGA internal references and arrays for the administration of the individual sessions and all processes can be found. The size of these arrays can only be changed during the start of an instance, if the SGA is restarted. The last granule always includes the Redo Buffer and a list of system-specific entries. Jeder Pool umfasst dabei mindestens eine Granule. Dies gilt insbesondere auch für jeden einzelnen der Buffer Pools, sofern diesem Speicher zugewiesen wurde. Sollte dabei ein Konflikt mit dem Parameter SHARED_POOL_SIZE auftreten, so wird dieser missachtet.

Die Granulen innerhalb eines Pools sind untereinander in Form einer doppelt verketteten Liste verbunden. Als Anfangs- und Endreferenz wird dabei auf eine imaginäre Granule Nr. „0“ verwiesen. Sollte die Größe eines Pools nicht ein Vielfaches der Granulengröße sein, so wird intern entsprechend aufgerundet.

Die erste Granule enthält ein Array mit fester Größe, welches einen Verweis auf alle Granulen enthält. Dies erklärt auch die Notwendigkeit der unterschiedlichen Größe der verwendeten Granulen in Abhängigkeit des SGA Sizings.

Neben den Referenzen auf alle Granulen enthält die erste Granule noch die sogenannte „Fixed Area“. In der Fixed Area befinden sich alle SGA internen Variablen, SGA internen Referenzen und Arrays für die Verwaltung der einzelnen Sessions und aller Prozesse. Die Größe dieser Arrays kann nur im Rahmen des Durchstartens einer Instanz, wenn die SGA vollständig neu angelegt wird, verändert werden.

Die letzte Granule beinhaltet immer die Redo Buffer und eine Reihe systemspezifischer Einträge.

X$Tables

The X$Tables represent the internal data structure of the fixed area and therefore make it possible to use them for a systematic analysis of the SGA. The fundamental tables are: Die X$Tabellen bilden die internen Datenstrukturen der Fixed Area ab und ermöglichen davon ausgehend eine systematische Analyse der SGA.

Die grundlegenden Tabellen sind dabei: * X$KSMMEM -- 4 / 8 Byte Access to all SGA Addresses * X$KSMGE -- Tables with all granules * X$KSMSD -- Definition of all fixed area variables * X$KSMFSV -- Addresses of the fixed area variables * X$KQFVT -- Definition of all V$ & GV$Views * X$KQFVI -- Description of all V$ & GV$Views * X$KQFTA -- All X$Tables * X$KQFDT -- All derivative tables * X$KQFCO -- Column defitions of X$Tables

  • X$KSMMEM -- 4 / 8 Byte Zugriff zu allen Adressen der SGA
  • X$KSMGE -- Tabelle mit allen Granulen
  • X$KSMSD -- Definition aller Fixed Area Variablen
  • X$KSMFSV -- Adressen der Fixed Area Variablen

  • X$KQFVT -- Definitionen aller V$ & GV$Views
  • X$KQFVI -- Bezeichnung aller V$ & GV$Views

  • X$KQFTA -- Alle X$Tabellen
  • X$KQFDT -- Davon abgeleitete Tabellen
  • X$KQFCO -- Spaltendefinitionen der X$Tabellen

According to the used naming conventions, "KS" stands for "Kernal Service" and "KQ" for "Kernel Query." Further information concerning the compostion of the table descriptions can be found at the metalinkj in the Note:22241.1: „List of X$ Tables and how the names are derived“. Through X$Table's possibility for direct access, information is made accessible which is otherwise not available. A good example for this is the so-called "hidden parameters," the description of which usually begins with a "_". Entsprechend der verwendeten Namenskonventionen steht dabei „KS“ für „Kernel Service“ und „KQ“ für „Kernel Query“.

Weitergehende Informationen bzgl. der Zusammensetzung der Tabellenbezeichnungen finden sich bei Metalink in der Note:22241.1: „List of X$ Tables and how the names are derived“.

Durch die direkte Zugriffsmöglichkeit auf die X$Tabellen werden Informationen zugänglich gemacht, die anderweitig nicht verfügbar sind. Ein gutes Beispiel hierfür sind die sogenannten „Hidden Parameter“, deren Bezeichnung meistens mit einem „_“ beginnt.

X$KSPPI

X$KSPPSV

All parameters can now be calculated through the following queries: Alle Parameter können nun durch die folgende Abfrage ermittelt werden:

select * from X$KSPPI P, X$KSPPSV V
where P.INDX = V.INDX and P.INST_ID = V.INST_ID

With the above table, both the columns ADDR and INDX are purely virtual, meaning that they are created directly at the runtime. It is typical that the information for multiple X$Tables is shared and the corresponding Join goes over the virtual INDX column. Bei den obigen Tabellen sind die beiden Spalten ADDR und INDX rein virtuell, d.h. diese werden direkt zur Laufzeit erzeugt. Es ist genauso typisch, dass die Information auf mehrere X$Tabellen verteilt ist und der entsprechende Join über die virtuelle INDX-Spalte geht.

A further area of use for the X$Tables are requests for the monitoring of use. An example of this would be the logging of all events, which is determinged in the wait time for the individual sessions. This could look as follows, for example: Ein weiterer Anwendungsbereich der X$Tabellen sind Abfragen zur Überwachung der Anwendung. Ein Beispiel hierfür wäre die Erfassung aller Events, welche Wartezeiten bei den einzelnen Sessions verursachen. Dieser könnte z.B. wie folgt aussehen:

select sid,seq#,event,p1,p2,p3 from V$SESSION

The columns used in this request are found in the tables X$KSUSECST and X$KSLED. The linkage follows here from the event number in X$KSUSECST against the INDX number in X$KSLED: Die in dieser Abfrage verwendeten Spalten befinden sich in den beiden Tabellen X$KSUSECST und X$KSLED. Die Verknüpfung erfolgt hier über die Eventnummer in X$KSUSECST gegen die INDX-Nummer in X$KSLED:

select F.INDX,F.KSUSSOPC,D.KSLEDNAM
from X$KSUSECST F,X$KSLED D
where F.KSUSSOPC > 0 and F.KSUSSTIM = 0
    and D.INST_ID = F.INST_ID and D.INDX = F.KSUSSOPC

SGA Scanner

The execution of queries based on V$Views and/or X$Tables could impact the performance of the Oracle database instance. In addition it is very important to keep the execution time as short as possible as SGA Scanners are the only possible To allow the execution of the resulting request as often as possible, even without impairment of the Oracle database instance, SGA scanners with Java the use of SGA scanners implemented with JNA is offered. Da die daraus resultierende Abfrage möglichst oft und ohne eine Beeinträchtigung der Applikation ausgeführt werden sollte, bietet sich die Verwendung eines mit Java unter Verwendung von JNA implementierten SGA-Scanners an.

KnowledgeBanner
QueryAdvisor trial.
QueryAdvisor in 30 Seconds

QueryAdvisor quote.
QueryAdvisor support forum.
QueryAdvisor Twitter channel.
social icons Facebook Twitter Blogspot RSS