X$Tabellen und SGA Scanner

Transkript

1 X$Tabellen und SGA Scanner Dipl.-Inform. Frank Beutelschiess BzYxS.com Frankfurt/Berlin Schlüsselworte: X$Tabellen, V$Views, SGA, SGA-Scanner, Performance Views, Buffer Cache, Redo Log, Shared Pool, Large Pool Einleitung Die X$Tabellen bilden die internen Datenstrukturen einer Oracle-Datenbank nach außen sicht- und damit auslesbar ab. Die von Datenbankadministratoren oft verwendeten V$Views, auch Performance Views genannt, bauen auf diesen weitgehendst auf. Im Rahmen dieses Vortrags wird der Aufbau der SGA und die wichtigsten X$Tabellen vorgestellt. Abgerundet wird das Thema durch den Bauplan eines SGA-Scanners, welche den direkten Zugriff auf die Inhalte der SGA, auch bei einer nicht mehr mit normalen Mitteln erreichbaren Oracle-Instanz, ermöglicht. Die Darstellung basiert auf der Verwendung von Oracle 9i oder höher. Aufbau der 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 Oracle-Instanz angelegt, solange sich diese noch im Zustand NoMount befindet und enthält alle zum Betrieb notwendigen Daten. Eine Oracle-Instanz entspricht der Summe der Prozesse, bzw. Threads und der SGA. Abb. 1: Einbettung der SGA

2 Die Allokierung der durch den Parameter SGA_MAX_SIZE nach oben hin beschränkten Speichermenge erfolgt in Abhängigkeit der Oracle-Version 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 Oracle-Version, 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). Die wesentlichen Bereiche einer SGA sind: 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) 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.

3 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. Abb. 2: Aufeinanderfolge der einzelnen Granulen X$Tabellen 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 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 Entsprechend der verwendeten Namenskonventionen steht dabei KS für Kernel Service und KQ für Kernel Query.

4 Weitergehende Informationen bzgl. der Zusammensetzung der Tabellenbezeichnungen finden sich bei Metalink in der Note: : 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 - Kernel/Service/Parameter/ParameterInfo Abb. 3: Inhalt der Tabelle X$KSPPI X$KSPPSV - Kernel/Service/Parameter/SystemValues Abb. 4: Inhalt der Tabelle X$KSPPSV 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 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. 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 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

5 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. SGA-Scanner Die grundlegende Funktionsweise eines SGA-Scanners besteht in dem direkten Auslesen und anschließendem Interpretierens des von der SGA allokierten Speichers. Naturgemäß verbietet sich jegliches Zurückschreiben, da dies nicht zuletzt auch aufgrund der fehlenden Synchronisation zwischen den Datenbankprozessen und dem SGA-Scanner, schnell zu Inkonsistenzen bis hin zu dem Crash der Instanz führen würde. Der Vorteil eines direkten Auslesens liegt einerseits in der hohen Geschwindigkeit und andererseits in der Vermeidung möglicher Latch Contentions innerhalb der Oracle-Instanz. Ein kontinuierlicher Zugriff auf das Data Dictionary unter Verwendung eines FullTableScans kann sehr schnell zu erheblichen Problemen in der Anwendung führen. Abb. 5: FullTableScan auf das Data Dictionary Der Nachteil besteht einerseits in der Notwendigkeit den SGA-Scanner physisch auf der zugrundeliegenden Hardware zu installieren und andererseits in den vielen kleinen Detailproblemen bei der Umsetzung. Diese reichen von der korrekten Konvertierung von Datentypen (signed/unsigned, Little/Big Endian), Pointerlängen (32/64 Versionen) bis hin zu der fehlenden offiziellen Dokumentation der X$Tabellen, geschweige denn der SGA internen Variablen und Arrays. Da sich die Realisierung der jeweiligen Prozesse unter Windows und Unix sehr stark unterscheiden, konzentriere ich mich an dieser Stelle auf die Windowsversion. Es gibt unter Windows einen Prozess Oracle.exe. Die eigentlichen Datenbankprozesse sind in Form einzelner Threads innerhalb dieses Prozesses aktiv. Es bietet sich deshalb folgende Vorgehensweise an: Liste aller laufenden Prozesse erzeugen: <Psapi>.EnumProcesses(*pProcessIds, ) Die Prozesse der Liste einzeln öffnen: <Kernel32>.OpenProcess(0x410,,dwProcessId) Den Namen des Prozesses ermitteln und gegen Oracle.exe vergleichen: <Psapi>.GetModuleBaseName(hProcess,,lpBaseName, ) Falls es nicht Oracle.exe war schließen und den nächsten Eintrag bearbeiten:

6 <Kernel32>.CloseHandle(hObject) Falls es Oracle.exe war mit diesem Handle den Speicherbereich auslesen: <Kernel32>.ReadProcessMemory(hProcess, lpbaseaddress,lpbuffer, ) Nach dem Auslesen muss der Handle wieder geschlossen werden: <Kernel32>.CloseHandle(hObject) Die noch fehlende Adresse bzgl. des auszulesenden Speicherbereichs und dessen Länge kann wie folgt ermittelt werden: select min(addr),max(addr),count(*) from X$KSUSECST Abb. 6: Zusammenspiel Hauptspeicher / SGA-Scanner / CPU-Belastung Die Erfahrung zeigt, dass bei Scangeschwindigkeiten mit bis zu 100 Scans/s keine nennenswerte CPU Belastung auftritt. Geschwindigkeiten bis zu 1000 Scans/s sind möglich. Schlusswort Die Erforschung der SGA ist ein weites und interessantes Feld mit vielen sinnvollen Anwendungsmöglichkeiten. Ich lade deshalb gerne alle Interessierten ein, eigene Experimente auf der Basis der von mir implementierten Javaklassen durchzuführen. Eine kurze an die unten angegebene Adresse genügt und ich sende diese gerne zurück. Kontaktadresse:

7 Dipl.-Inform. Frank Beutelschiess Am Wehr 1 D Liederbach/Ts. Telefon: +49(0) Fax: +49(0) Frank.Beutelschiess@BzYxS.com Internet: