Prozessarchitektur einer Oracle-Instanz: Prozesse und deren
Werbung
Prozessarchitektur einer Oracle-Instanz: Prozesse und deren Aufgaben, Speicherstrukturen Tobias Kaatz, Sebastian Schneemann Juni 2007 Die Instanziierung einer modernen Datenbank ist eine komplexe Angelegenheit. Die Zusammenhänge von globaler wie privater Speicherorganisation und den darauf arbeitenden Prozessen wird am Beispiel von Oracle 10g behandelt. Diese internen Details, die für den Datenbanknutzer in der Regel transparent ablaufen, werden in einen Rahmen eingeordnet, der von der Verbindung eines Client-Programms, über die Bearbeitung der Anfrage, bis zum Versand der Antwort zurück an den Client reicht. Inhaltsverzeichnis 1 Einführung in den Instanz-Begriff 4 2 SGA - System Global Area 2.1 Speicheraufbau im SGA . . . . . . . . . 2.2 Automatisches Speichermanagement . . 2.3 Die SGA-Komponenten . . . . . . . . . 2.3.1 Database Buffer Cache (DBBC) 2.3.2 Redo Log Buffer . . . . . . . . . 2.3.3 Shared Pool . . . . . . . . . . . . 2.3.4 Large Pool . . . . . . . . . . . . 2.3.5 Java Pool . . . . . . . . . . . . . 2.3.6 Streams Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7 8 10 10 11 11 12 13 13 3 PGA - Program Global Areas 3.1 Inhalt des PGA . . . . . . 3.1.1 Private SQL Area 3.1.2 Session Memory . 3.1.3 SQL Work Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 14 14 14 15 4 Prozessstruktur einer Oracle-Instanz 4.1 Der Benutzer-Prozess . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Die Oracle-Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Die Server-Prozesse . . . . . . . . . . . . . . . . . . . . . 4.2.2 Die Hintergrundprozesse . . . . . . . . . . . . . . . . . . . 4.3 Die Geteilte Server Architektur (Shared Server Architecture) . . 4.3.1 Die Dispatcher Request und Response Queues . . . . . . 4.4 Die Exklusiv-Server Architektur (Dedicated Server Architecture) 4.5 Das Programm Interface (Program Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 17 17 18 18 22 23 25 26 . . . . . . . . . . . . . . . . . . . . 3 . . . . . . . . . . . . 1 Einführung in den Instanz-Begriff Verbindet sich ein Nutzer mit Hilfe von Applikationen wie dem SQLWorksheet, SQLPlus oder auch einer Anwendung auf JDBC1 -Basis, wie dem SQL-Developer, unter Angabe einer SID mit einem Datenbank-Server, wird der Kontakt zur entsprechenden Instanz hergestellt. Eine Oracle-Instanz ist eine Sammlung von Prozessen und Speicherbereichen, kontrolliert vom DBMS2 . Jede Instanz wird durch die so genannte ORACLE_SID (kurz SID) identifiziert. Werden nun Daten mit Hilfe der Instanz in die Datenbank eingegeben, werden diese nicht in allein einer Datei gespeichert. Alle großen heute existierenden Datenbank Systeme (DBS) unterteilen die Datenbanken in mehrere Dateien um auch das Speichern gößerer Datenmengen mit möglichst geringem Zeitaufwand zu realisieren, ohne dabei an dateisystemabhängige Grenzen hinsichtlich der maximalen Dateigröße zu stoßen. Zusätzlich dazu werden, zumindest bei Oracle, weitere Dateien einbezogen, in denen Informationen über die Struktur der gespeicherten Daten, sogenannte Meta-Daten, enthalten sind. Operationen auf den beschriebenen Datenbanken können nur durchgeführt werden, wenn genügend Speicher vorhanden ist, in den die benötigten Daten geladen werden können. Dort kann dann die gewünschte Aktion ausgeführt werden. Auch dieser Speicher besitzt nur eine endliche Größe, was die maximale Anzahl parallel laufender Instanzen wiederrum beschränkt. Der Aufbau und die Funktionweise der SpeicherArchitektur einer Oracle-Instanz wird für den globalen Speicher (SGA) in Kapitel 2 und für den privaten Speicher in Kapitel 3 erläutert. Neben der Speicherorganisation spielen verschiedene Prozesse, die in der Regel für den Benutzer transparent im Hintergrund ausgeführt werden, eine zentrale Rolle während des Betriebs einer Oracle-Instanz. Diese Prozesse unterteilt man im allgemeinen in • Anwendungen und Oracle-Tools (Client)und • Oracle Datenbankserver Code (Server). Die Anwendungen und Oracle-Tools dienen zur Interaktion des Nutzers mit der Daten1 Java Database Connectivity, Java-Schnittstelle zur Herstellung einer vereinheitlichten Verbindung zu unterschiedlichen Datenbank-Systemen 2 Database Management System, neben den Nutzdaten (der Datenbank) zweiter großer Bestandteil eines Datenbank-Systems, Verwaltungssoftware 4 Abbildung 1.1: Speicher Struktur von Oracle Datenbanken, Quelle: (Michele Cyran, 2005) bank, in der Regel um SQL-Statements abzusetzen oder mit Hilfe von DML Manipulationen an der Datenbank vorzunehmen. Der Oracle Datenbankserver Code hat zur Aufgabe, die Anfragen und Änderungen der mit den Anwendungen und OracleTools erzeugten Statements zu interprätieren und schließlich auszuführen. Die hierfür notwendigen Prozesse werden in Kapitel 4 erläutert. Eine Datenbank-Instanz ist aber nur dann nötig, wenn auf die Datenbank zugegriffen werden muss. Eine Datenbank kann prinzipiell auch ohne Instanzen bestehen und sogar Daten beinhalten. Die Instanzen können abhängig vom DBS und den lokalen Gegebenheiten auf dem Server variieren. Sämtliche Eigenschaften einer neuen Instanz werden zum Zeitpunkt der Initialisierung anhand der Initialisierung-Parameter festgelegt. Diese Parameter sind in einer speziellen Datei eingetragen und können vom Datenbank-Administrator (DBA) angepasst werden. 5 2 SGA - System Global Area Jeder Start einer Oracle Instanz bewirkt, dass Speicher allokiert wird. Ein erheblicher Teil dessen wird vom SGA eingenommen. Wenn die Instanz wieder geschlossen wird, wird der Speicherbereich automatisch an das Betriebssystem (OS) zurückgegeben“. ” SGA ist die Bezeichnung für eine Gruppierung von mehreren shared memory Strukturen die Daten und Kontrollinformationen beinhalten. Diese Zusammensetzung ermöglicht, dass mehrere Nutzer, die auf die selbe Instanz zugreifen, gleichzeitig auf die im SGA hinterlegten Daten zugreifen können. Dabei können alle Nutzer vom SGA lesen und manche Prozesse der Instanz können auch schreibend auf dem SGA operieren. Die Eigenschaft des Multi-User-Zugriffs hat dem SGA auch die Interpetation shared global area eingebracht. Der SGA ist unterteilt in verschiedene Datenstrukturen: • Database buffer cache • Redo log buffer • Shared pool • Java pool • Large pool (nicht unbedingt benötigt) • Streams pool • Data dictionary cache • Weitere Informationen Nicht alle Bereiche des SGA sind für den Nutzer-Zugriff bestimmt. Der geschlossene Bereich wird auch fixed SGA genannt und beinhaltet Statusinformationen der Datenbank, die von den Hintergrundprozessen benötigt werden. Zusätzlich werden ermöglicht der SGA sowohl einen Datenaustausch zwischen Prozessen als auch Informationen über die Locks. Wird vom System eine Shared server Architektur verwendet, dann werden die Sendeund Empfangsqueues und ein Teil des PGA im SGA gespeichert. 6 2.1 Speicheraufbau im SGA Der SGA vereint eine Anzahl unterschiedlicher Speicherkomponenten. Diese werden benötigt, da innerhalb der Instanz unterschiedliche Allokations-Konzepte verfolgt werden. Gemein haben aber alle Komponenten, dass sie Speicher in sogenannten granules reservieren und wieder freigeben. Innerhalb der Oracle Datenbank werden also den jeweiligen Teilen des SGA auch eine gerade Anzahl von granules zugewiesen, auch wenn die Addition der Größen dann den eigentlichen Speicherbedarf übersteigt. Die Größe der granules wird durch die tatsächliche Größe des SGA bestimmt. In den meisten Fällen aber wird eine granule-Größe von 4MB bei einem Gesamt-SGA von 1GB festgelegt. Größere SGAs haben meist 16MB große granules. Bei manchen Plattformen/Systemen variieren aber diese Angaben. Auf 32-bit Windows-Systemen ist sind die granules für SGAs größer als 1GB nur 8MB groß. Vergleichbar mit anderen Anwendungen ist es auch bei den Oracle-Datenbanken von Vorteil, wenn der gesamte SGA auch in den echten Speicher passt und kein Virtueller Speicher verwendet werden muss. Andernfalls kann es zu erheblichen Beeinträchtigungen für das ganze DBS kommen. Zusätzlich zu dem Umfang des SGA hat auch die jeweilige Zuteilung des Speichers zu den einzelnen Teilen des SGA einen Einfluss auf die Performance. 7 2.2 Automatisches Speichermanagement In der letzten Zeit wurde in dem Speichermanagement der Oracle-Datenbanken eine folgenreiche Änderung durchgeführt. Bis vor Einführung der Version 10g musst der DBA eine große Anzahl von Initialisierungs-Parametern des SGA selbst festlegen. Nun ist es aber möglich, die Einstellung dieser Werte dem DBS zu überlassen, was das Speichermanagement stark vereinfacht. Es reicht nun aus, allein die Gesamtgröße des SGA mit Hilfe des Parameters SGA_TARGET festzulegen. Die Oracle-Datenbank weist dann dynamisch den einzelnen Unterstrukturen ihren Speicher zu und ermöglicht damit eine effektivere Speichernutzung. Betroffen von der Automatisierung sind die meistgenutzten Bereiche des SGA. Hauptsächlich sind dies: • Der shared pool, • der Java pool, • der large pool, • der Puffer-Cache und • der Streams cache Die Belastung jeder dieser automatisch angepassten Komponenten wird von der OracleDatenbank-Instanz überwacht. Die Instanz benutzt interne Views und Statistiken um mit deren Hilfe die beste Anpassung der Parameter zu ermitteln. Dabei werden nicht nur kurzzeitige Veränderungen, sondern auch Langzeittrends in Betracht gezogen. Wenn sich der workload verändert, kann dann darauf reagiert werden und die somit die optimale Performance wieder hergestellt werden. Einen beträchtlichen Unterschied zu der manuellen Speicherzuweisung ist, dass durch das automatische Speichermanagement es nun auch möglich ist, dass die Speichergrößen der Komponenten flexibel angelegt sind und an die jeweilige Belastung angepasst werden können ohne dass der DBA in die Konfiguration eingreifen muss. Die Datenbank verteilt nach Bedarf den Speicher, damit der gesamte SGA optimaler genutzt werden kann. Ein offensichtlicher Vorteil der Automatisierung ist die Vereinfachung des Konfigurationsprozesses dadurch, dass nur ein Parameter festgesetzt werden muss. Dadurch werden auch die sonst häufiger auftretenden out of memory“-Fehlermeldungen bis zu ” dem Zeitpunkt, an dem das gesamte System an die Speichergrenzen stößt, vermieden. Das automatische SGA-Management kann die Leistungsfähigkeit der Datenbank entschieden verbessern ohne, dass andere Ressourcen benötigt werden oder spezielles 8 Tuning vorgenommen werden muss. Manuelles Konfigurieren kann möglicherweise bewirken, dass SQL-Queries auf Grund ihrer Größe vermehrt neu in den Shared-Pool geladen werden müssen. Diese sogenannten hard parses sind sehr aufwändig und beeinflussen die System-Performance. Die automatische SGA-Verwaltung beinhaltet einen Tuning-Algorithmus, der den workload beobachtet und im Falle einer starken Belastung dann auch den Shared-Pool vergrößern kann. Dieses Vorgehen fürt dann zu einer starken Verminderung der hardparses. 9 2.3 Die SGA-Komponenten 2.3.1 Database Buffer Cache (DBBC) Im DBBC werden Kopien einzelner Datenblöcke der Datenbank, welche aus den Dateien der Datenbank gelesen wurden, abgelegt. Alle Benutzerprozesse welche gemeinsam mit einer Instanz verbunden sind, teilen sich den Zugang zu dem DBBC. Der DBBC ist, wie auch der Shared SQL Chache, logisch in multiple sets (ermöglichen Mehrfachzugriff) unterteilt, was Probleme mit Multi-Prozessor-Systemen minimieren soll. Organisation des DBBC Die Puffer des Caches werden in Form von zwei Listen organisiert: die write list (Schreibe-Liste) und die last recently used list (LRU - zuletzt benutzte Elemente). Die write list beinhaltet sogenannte dirty bufers, welche Daten beinhalten, die verändert wurden aber noch nicht zurück auf die Platte geschrieben wurde. Die LRU-Liste beinhaltet freie Puffer, pinned buffers und dirty buffers, welche noch nicht in die write list bewegt wurden. Freie Puffer beinhalten hier keine nutzbaren Daten und es ist möglich, diese zu benutzen wohingegen auf die pinned buffers schon zugegriffen wird. Wenn ein Prozess auf einen Puffer zugreif, dann wird dieser an die most recently used (MRU)-Stelle am Ende der LRU-Liste gesetzt. Zum ersten Zeitpunkt, an dem ein Oracle-Benutzer-Prozess ein bestimmtes Datum anfordert, sucht er danach im DBBC. Im Falle eines chache hit (Datum wird im Cache gefunden), kann sofort mit dem Lesen direkt aus dem Speicher begonnen werden. Falls des Datum nicht im DBBC vorliegt (cache miss) muss der zugehörige Datenblock von Platte in einen Puffer des DBBC gelesen werden, was den Zugriff verlangsamt. Vor dem Einlesen eines Datenblocks in den Cache muss ein freier Puffer gefunden werden. Die LRU-Liste wird so lang nach einem freien Puffer durchsucht bis dieser gefunden oder das Ende der Liste erreicht ist. Falls bei der Suche ein dirty buffer gefunden wurde, wird dieser in die write list verschoben und die Suche fortgesetzt. Falls ein freier Puffer vom Prozess gefunden wurde, werden die Daten in diesen geladen und der Puffer dann an die MRU-Stelle der LRU-Liste verschoben. Wir kein freier Puffer gefunden und das Ende der LRU-Liste erreicht, dann stoppt der Prozess die Durchsuchung der Liste und veranlasst, dass dirty buffer in die write list Übernommen werden. 10 2.3.2 Redo Log Buffer Der redo log buffer beinhaltet Informationen über die auf der Datenbank vorgenommenen Änderungen. Diese Informationen werden in speziellen redo entries gespeichert. Redo entries enthalten Informationen, welche benötigt werden, um Änderungen durch INSERT, UPDATE, DELETE, CREATE, ALTER oder DROP - Operationen rückgängig zu machen. Auch werden sie, wenn nötig, zum Recovery eingesetzt. Redo entries werden von Oracle Datenbank Prozessen aus dem Benutzerspeicher in den redo log buffer im SGA gespeichert. Die Einträge im Puffer sind sequentiell und andauernd gespeichert und ein Hintergrundprozess des DBS schreibt den Puffer in die aktive redo log -Datei auf der Festplatte. 2.3.3 Shared Pool Der shared pool beinhaltet den library cache, den dictionary cache, puffer für Nachrichten für parallele Ausführungen (parallel execution messages) und Kontrollstrukturen. Library Cache Der Library Cache beinhaltet die geteilten SQL-Bereiche (shared SQL areas), private SQL-Bereiche (private SQL areas), PL/SQL-Prozeduren und -Pakete und Kontrollstrukturen sowie auch Locks und die sogenannten library cache handles. Damit diese Bibliothek für alle Nutzer zugäglich ist, wurde sie in den shared pool des SGA platziert. Shared SQL Areas und Private SQL Areas Shared SQL Areas und Private SQL Areas Innerhalb einer Datenbank wird ein SQL-Statement durch einen geteilten oder öffentlichen Teil, die Shared SQL Area, und einen persönlichen oder privaten Teil, die Private SQL Area repräsentiert. Im Falle einer Mehrfachausführung eines SQL-Statements ist es durch diese Aufteilung möglich, dass alle Nutzer auf den öffentlichen Teil zugreifen können. Somit ist nur noch eine separate Kopie des privaten Teils für jeden Nutzer nötig. Shared SQL Area Ein öffentlicher SQL-Bereich beinhaltet den parse tree (den ParserBaum) und den Ausführungsplan eines SQL-Statements. Da die öffentlichen Bereiche mehrfach gleichzeitig verwendet werden können, spart Oracle mit diesem Konzept viel Speicher ein. 11 Oracle allokiert Speicher vom Shared Pool zu dem Zeitpunkt an dem ein neues SQLStatement geparst wird, um dort den öffentlichen SQL-Bereich unterzubringen. Dabei hängt die Speichergröße von der jeweiligen Komplexität des Statements ab. Falls der benötigte Speicherplatz nicht zur Verfügung steht, ist es möglich, dass andere Speichersegmente nach einem modifizierten LRU-Algorithmus deallokiert werden können, um die Ausführung des Statements zu garantieren. PL/SQL Program Units Oracle behandelt PL/SQL-Programmeinheiten (Prozeduren, Funktionen, Packages, anonyme Blöcke und Datenbank-Trigger) größtenteils auf die selbe Weise, auf die auch individuelle SQL-Statements behandelt werden. Oracle allokiert ein öffentliches Gebiet (shared area) im Speicher, um dort die geparsten und kompilierten Programmeinheiten vorzuhalten. Ein privater Bereich wird allokiert, um dort für die jede Sitzung spezielle Werte einschließlich lokale, globale und PackageVariablen sowie Puffer für die Ausführung von SQL. Individuelle SQL-Statements, welche in einer PL/SQL-Programmeinheit enthalten sind, werden auf die im vorherigen Abschnitt beschriebene Weise bearbeitet (mit einem öffentlichen und einem privaten Bereich). Dictionary Cache Das data dictionary ist eine Sammlung von Datenbank-Tabellen und Views welche Informationen über die Datenbank, ihre Struktur und ihre Nutzer. Das data dictionary wird mehrfach beim parsen eines SQL-Statements aufgerufen. Dies geschieht so oft, dass für die Informationen zwei spezielle Orte im Speicher dafür vorgesehen sind. Der eine Bereich wird data dictionary cache bzw. row cache genannt, da er die Daten nicht als Puffer, sondern als Zeilen (die ganze Blöcke von Daten enthalten können) beinhaltet. Der zweite Bereich ist der library cache. Auf beide Prozesse können die Nutzer uneingeschränkt zugreifen. 2.3.4 Large Pool Der DBA hat die Möglichkeit, einen optionalen Bereich im Speicher, den sogenannten large pool, bereitzustellen. Dieser zeichnet sich durch einen großen Speicherumfang aus und wird gewöhnlicherweise für • die Speicherung der Sitzungsdaten für beispielsweise die Shared Server Architekturen • I/O Server-Prozesse • Oracle interne Backup- und Restore-Operationen verwendet. 12 Der Large Pool kann teilweise Funktionen anderer Pools des SGA übernehmen. Falls beispielsweise Sitzungsdaten für Shared-Server-Systeme gespeichert werden sollen, kann der Pool zum Cachen des öffentlichen SQL eingesetzt werden, was Performanceverbesserungen bewirkt. Zusätzlich wird der Speicher für Backup/Restore, I/O-Prozesse und parallele Puffer in Puffern zu je mehreren hundert Kilobyte allokiert. Dadurch ist der Large Pool besser für Prozesse mit einen größeren Speicherbedarf geeignet, als der Shared Pool. 2.3.5 Java Pool Der Java Pool wird im Server-Speicher benutzt, um alle für eine Session spezifischen Java-Codes und Daten innerhalb einer JVM zu speichern. Dabei kann der Java Pool, abhängig vom Modus des Oracle Servers, auf unterschiedliche Weise verwendet werden. 2.3.6 Streams Pool In einer einzelnen Datenbank kann man Speicherplatz für Oracle Streams festlegen. Dieser wird auch der Streams Pool genannt. Falls kein Stream Pool definiert wurde, wird dieser bei der ersten Benutzung von Oracle Streams eingerichtet. 13 3 PGA - Program Global Areas Ein PGA ist ein Speicherbereich der, genau wie der SGA, Daten und Kontrollinformationen eines Serverprozesses enthält. Der Unterschied zum SGA liegt in der Freigabe des Bereiches. Der PGA ist ungeteilt. Er wird zur Startzeit eines Prozesses von Oracle erstellt. Nur allein dieser Prozess kann auf seinen“ PGA zugreifen und es ist nur ” möglich mit Oracle-Code der für diesen Prozess arbeitet auf den Bereich zuzugreifen. 3.1 Inhalt des PGA Mit der Unterteilung des PGA verhält es sich wie mit der Klassifizierung des SGA. Die Anzahl und Funktion der einzelnen Komponenten hängt von der jeweils verwendeten Server-Architektur ab. Allgemein ist aber eine Unterteilung in die folgenden Komponenten möglich. 3.1.1 Private SQL Area Dies ist das Gegenstück zum Shared SQL Area im SGA. Der Private SQL Area enthält Daten wie Bindungsinformationen(meist persistente Daten) oder Laufzeit-SpeicherStrukturen(meist nach Ausführung wieder freigegeben). Jede Sitzung, welche sich mit einem SQL-Statement befasst, besitzt auch ein Private SQL Area. Jeder Nutzer, der das selbe Statement absendet, erhält seinen eigenen Private SQL Area aber alle Nutzer greifen auf den selben Shared SQL Area zu. 3.1.2 Session Memory Session Memory wird allokiert um die Sitzungsvariablen (also alle Informationen über Nutzer und Art der Sitzung) vorzuhalten. Falls dem System eine Shared-Server-Architektur zu Grunde liegt, ist dieser Speicherbereich nicht privat, sondern öffentlich. 14 3.1.3 SQL Work Areas Komplexe Queries erfordern auch einen großen Teil des Laufzeitspeichers um bearbeitet zu werden. Somit werden speicherintensiven Operatoren wie • Sortierbasierten Operatoren (z.B. order by) • Hash-Join • Bitmap merge • Bitmap create eigene Arbeitsgebiete zugewiesen. Die Größe der einzelnen Gebiete kann von außen kontrolliert und verändert werden. Dabei ist es optimal, wenn alle Eingabedaten einschließlich der Speicherstrukturen des Operators im Speicher Platz finden. 15 4 Prozessstruktur einer Oracle-Instanz Die meisten Datenbanken werden als Mehrbenutzersysteme betrieben. Dies setzt einerseits eine strikte Trennung von sensiblen Bereichen der Anweisungen aus Sicherheitsaspekten, anderseits jedoch eine Zusammenfassung möglichst vieler Arbeitsschritte aus Performancegründen voraus. Oracle hat dieser Überlegung mit einer Reihe von Prozessen Rechnung getragen, um beiden Paradigmen möglichst effektiv begegnen zu können. Dies spiegelt sich unter anderem in der Anzahl der Prozesse wieder: Abbildung 4.1: Eine Oracle-Instanz, Quelle: (Michele Cyran, 2005) Die Abbildung 4.1 zeigt eine Oracle-Instanz mit mehreren geöffneten Nutzer-Sitzungen (oberer Bereich: user processes) und verschiedenen Oracle Hintergrundprozessen (unterer Bereich: oracle processes). Sowohl Nutzer- als auch Systemprozesse greifen i. a. lesend wie schreibend auf die SGA zu. (Diese Abbildung kann je nach verwendetem Betriebssystem und/oder Oracle-Einstellungen differieren.) 16 4.1 Der Benutzer-Prozess Wie in Abbildung 4.1 dargestellt, erzeugt jede Verbindung eines Nutzers mit Applikationen oder Oracle-Tools einen Benutzer-Prozess. Dieser besteht aus zwei ähnlichen aber dennoch zu unterscheidenden Punkten. Zum einen der • Verbindung und zum anderen der • Session. Mit Verbindung ist hier die Herstellung eines Kommunikationspfades zwischen Client und Server im physikalischen Sinne (als Interprozesskommunikation bzw. Kommunikation über ein Netzwerk wie beispielsweise das Internet) gemeint. Hinter dem Begriff der Session verbirgt sich eine tatsächliche Nutzerverbindung, bei der sich der Nutzer mit Hilfe einer Nutzername/Passwort-Kombination authentifizieren muss. Üblich ist es, dass mehrere Sessions über eine oder mehrere Verbindungen aufgebaut werden. 4.2 Die Oracle-Prozesse Die Oracle-Prozesse werden in zwei Kategorien unterteilt. Zum einen die • Server-Prozesse und zum anderen in • Hintergrund-Prozesse (Background-Prozesse). Beide Typen von Oracle-Prozessen schreiben während ihrer Ausführung anfallende, wichtige Informationen in eine Prozess-Trace-Datei. Die in chronologischer Ordnung abgelegten Informationen umfassen interne Fehler die während der Verarbeitung aufgetreten sind inklusive Speicherabbilder und Parameterlisten. Diese Hinweise helfen dem Administrator bei der Lokalisierung und Beseitigung des Fehlerverursachers. Weiterhin existiert pro Datenbank ein alert.log“-File, das über die gesamte Daten” bank betreffende Fehler berichtet. Hierzu zählen zum Beispiel der Fehler ORA-60“, ” der auf ein Deadlock hinweist, oder der Fehler ORA-1578“, der einen defekten Block ” meldet. Aber auch alle administrativen Operationen wie beispielsweise das Anlegen oder Löschen von Tabellen, das Ausführen eines ALTER“-Befehls oder das Herunter” fahren von Instanzen werden hier vermerkt. Die regelmäßige Überwachung der Prozess-Trace-Dateien und des alert.log sollte eine hochpriorisierte Aufgabe eines Datenbank-Administrators darstellen. 17 4.2.1 Die Server-Prozesse Für jeden Benutzer-Prozess (vgl. Kapitel 4.1) erzeugt Oracle einen dazugehörenden Server-Prozess. Nur über diesen ist die Kommunikation mit der Oracle-Instanz möglich. Als Aufgaben für den Server-Prozess ergeben sich somit • das Parsen und Ausführen von SQL-Statements, • die Bereitsstellung von Daten der Festplatte im SGA falls notwendig und • das Ausliefern der Anfrage-Resultate in einem geeigneten Format an den Client. 4.2.2 Die Hintergrundprozesse Ein Oracle-System im Mehrbenutzerbetrieb greift aus Performancegründen auf eine Vielzahl von Hintergrundprozessen zurück, um den konfliktfreien und sicheren Ablauf aller Nutzerverbindungen sicherzustellen. Die Anzahl der Prozesse ist betriebssystemund konfigurationsabhängig und kann ebenso während des Lebenszyklus (Zeitraum zwischen dem Starten und Herunterfahren) einer Instanz variieren. Die Abbildung 4.2 zeigt eine Oracle-Instanz im Mehrbenutzerbetrieb. Im folgenden werden die genannten Prozesse näher erläutert. Die Database Writer Prozesse (DBWn) Die Aufgabe der Database Writer Prozesse besteht darin, schmutzige“ (geänderte) ” Blöcke aus dem Database Buffer Cache zurück in die Datendateien zu schreiben. Dabei 1 liegt der LRU -Algorithmus zu Grunde und liefert die Dateien, am längsten nicht benötigt wurden, die sogenannten kalte Seiten“(cold buffers). Der DBWn schreibt ” kalte, schmutzige Seiten zurück, um freien Pufferplatz für die Server-Prozesse zu schaffen. Wie das n“ in DBWn bereits erahnen läßt, lassen sich mehrere (bis zu zehn) ” unabhängige Database Writer Prozesse auf einem Datenbanksystem starten, was zu enormen Geschwindigkeitsvorteilen führen kann. Das Zurückschreiben der Blöcke kann unter anderem durch die in Tabelle 4.1 genannten Ereignisse ausgelöst werden. Der Log Writer Prozess (LGWR) Der Log Writer Prozess schreibt jede Änderung die am Redo-Log-Puffer durchgeführt wurde in die Redo-Log-Dateien auf der Festplatte. Der Redo-Log-Puffer ist als Ringpuffer realisiert. Der Log Writer Prozess stellt sicher, dass immer genügend Speich1 least recently used, Seiteverdrängungsstrategie für Speicher 18 Abbildung 4.2: Hintergrundprozesse einer (Michele Cyran, 2005) Oracle-Mehrbenutzer-Instanz, Quelle: er für neue Einträge im Puffer zur Verfügung steht, indem er fortlaufend Einträge wegschreibt. Der LWGR schreibt das Redo-Log-File wenn entweder • ein Benutzer-Prozess eine Transaktion mittels commit“ quittiert ” oder der Redo-Log-Puffer • drei Sekunden lang nicht schrieben wurde, oder • der Puffer zu einem Drittel gefüllt ist, oder (falls notwendig), • ein DBWn-Prozess seine modifizierte Puffer wegschreibt. 19 Ereignis Dirty-Liste ist voll Kein freier Platz in LRUListe vorhanden Zeitintervall von 3 Sek. Checkpoint erreicht Wirkung beim DBWn DBWn schreibt Puffer weg DBWn schreibt Puffer aus LRU-Liste weg DBWn schreibt Dirty-Puffer von LRU-Liste in Dirty-Liste. Wird Schwellwert erreicht, werden Puffer auf Festplatte geschrieben Dirty Puffer von LRU-Liste in Dirty-Liste und dann auf Festplatte schreiben Tabelle 4.1: Mögliche Ereignisse und deren Wirkung auf den DBWn Im Gegensatz zum DBWn ist nur ein LGWR-Prozess vorgesehen. Da hier selten Performance-Engpässe beim Schreiben entstehen, liegt das Augenmerk auf Sicherheit der Redo-Log-Files die mit Hilfe von Redundanz erreicht wird: Die Redo-LogFiles können bei Bedarf in sogenannten mirrored groups“ organisiert werden. Alle ” Mitglieder-Dateien enthalten den gleichen Zustand, da der LGWR bei einem Schreibprozess alle Mitglieder aktualisiert. Der Ausfall einzelner Dateien aus einer Gruppe wird im System-Alert-Log vermerkt; die restlichen Mitglieder-Dateien werden weiterhin aktualisiert. Der Ausfall oder die Nicht-Erreichbarkeit der gesamten Gruppe führt hingegen zur Unterbrechung der Redo-Log-Funktionalität. Der Checkpoint Prozess (CKPT) Die Aufgabe des Checkpoint Prozesses ist es die Header der Datendateien auf der Festplatte mit den Details eines Checkpoints zu aktualisieren, wann immer ein solcher auftritt. Der System Monitor Prozess (SMON) Der System Monitor Prozess hat hauptsächlich verwaltende Aufgaben. So ist dieser für die Zusammenlegung von freien benachbarten Segmenten zuständig, ebenso wie für die Freigabe von nicht mehr benötigten Bereichen in temporären Tablespaces. Außerdem ist er für ein eventuelles Recovery beim Hochfahren der Instanz verantwortlich. Andere Prozesse dürfen den SMON aufrufen, wenn diese auf seine Fähigkeiten zurückgreifen müssen. 20 Der Process Monitor Prozess (PMON) Schlägt ein Benutzer-Prozess fehl, ist es die Aufgabe des PMON alle dadurch beendeten Prozesse erneut zu starten, bis sie nicht mehr gebraucht werden. Ist ein BenutzerProzess beendet, gibt der PMON die nun nicht länger benötigten Ressourcen (beispielsweise Sperren oder andere Prozesse) frei, damit diese wieder anderen Aufgaben zur Verfügung stehen. Auch ist der PMON für die Überwachung der Dispatcher-Prozesse (vgl. Kapitel 4.3) zuständig. Wie der System Monitor Prozess kann auch der PMON selbstständig überprüfen ob er benötigt wird und ebenso kann er von anderen Prozessen gestartet werden. Der Recoverer Prozess (RECO) Der Recoverer Prozess ist auf einem Oracle-System nur vorhanden, wenn dieses verteilte Transaktionen unterstützt. Schlägt die Durchführung einer verteilten Transaktion fehlt, versucht der RECO selbstständig die Wiederholung bis diese gelingt oder mit einem endgültigen Fehlerbericht endet. Der Job Queue Prozesse Die Job Queue Prozesse können als eine Art Scheduler verstanden werden, die von Benutzern dazu verwendet werden können, regelmäßig wiederkehrende Aufgaben zu erledigen, beispielsweise die tägliche Ausführung einer PL/SQL-Prozedur. Ein Job Queue Prozess in einer Oracle-Instanz ist somit mit einem Cron-Job auf Betriebssystemebene vergleichbar. Die Archiver Prozesse (ARCn) Die Archiver Prozesse sind auf dem Oracle-System nur verfügbar, wenn die Datenbank im sogenannten Archive-Log-Modus 2 läuft. Die Aufgabe der bis zu zehn ArchiverProzesse, die bei Bedarf durch den Log Writer Prozess (vgl. Seite 18) gestartet werden können, besteht darin, beim Wechsel von einem Redo-Log-File zum nächsten, das alte auf ein vorher definiertes (externes) Medium zu verschieben. 2 Modus der es gestattet, im Bedarfsfall einen sehr zeitnahen Zustand der Datenbank wiederherzustellen 21 Weitere Prozesse Neben den genannten Hintergrund-Prozesse können in einer Oracle-Instanz verschiedene weitere Prozesse auftreten. Hier soll auf weiterführende Literatur, besonders auf (Michele Cyran, 2005) und (Steve Fogel, 2006) verwiesen werden. 4.3 Die Geteilte Server Architektur (Shared Server Architecture) Hinter dem Begriff der Geteilten Server Architektur versteckt sich eine Technologie, welche die Einschränkung, dass jeweils ein Server-Prozess genau einen BenutzerProzess (vgl. Kapitel 4.2.1) bedienen kann, aufhebt. Statt dessen werden die ServerProzesse als sogeannte geteilte Server-Prozesse in einem Pool bereitgehalten und ordnen sich, sobald sie frei sind, dem nächsten hereinkommenden Benutzer-Prozess zu, indem sie diesen aus einer Warteschlange herauslösen. Durch die Einsparung von ServerProzessen (und damit Speicher) gegenüber einem dedizierten Server, ist der geteilte Server in der Lage mehr Clients zu bedienen. Gleichzeitig ergibt sich aber durch die Nutzer der Shared Server Technologie eine Einschränkung: Einige administrative Aufgaben lassen sich über diese Architektur nicht lösen, weil ein Benutzer-Prozess zu verschiedenen Zeitpunkten von verschiedenen Server Prozessen bedient werden könnte. Zu diesen Aufgaben gehören etwa das Herunterfahren einer Instanz oder das Recovery von Daten. Jedoch kann sich ein Client falls gewünscht durch die Angabe des Parameters "‘SERVER=DEDICATED"’ im ConnectingString jederzeit auf einen dedizierten Server Prozess verbinden lassen. Durch die Verteilung werden jedoch zusätzliche Prozesse benötigt. Diese umfassen den • Network Listener Prozess, • mindestens einen Dispatcher Prozess und • mindestens einen Shared Server Prozess. Versucht sich ein Client mit einer Instanz zu verbinden, nimmt beim Geteilten Server Betrieb zunächst der Network Listener Prozess die Anfrage entgegen. Dieser entscheidet anhand der vom Client übermittelten Informationen ob dieser einen Shared Server nutzen kann. Ist dies der Fall übermittelt der Listener dem Client die Verbindungsinformationen des Dispatcher Prozesses, der • das Verbindungsprotoll des Client unterstützt und 22 • zur Zeit die wenigste Auslastung hat. Der Client verbindet sich nun, für den Benutzer vollkommen transparent, ein zweites Mal mit der Instanz, diesesmal jedoch über den vermittelnden Dispatcher Prozess. Eine grafische Darstellung des Zusammespiels dieser Prozesse enthält die Abbildung 4.2 (S. 19). Bringt der Client die für die Verbindung zu einem Shared Server benötigten Voraussetzung nicht mit, versucht der Listener ihm eine Verbindung zu einem Dedizierten Server herzustellen. 4.3.1 Die Dispatcher Request und Response Queues Möchte ein Client ein SQL-Statement an die Instanz absetzen, legt der für ihn zuständige Dispatcher Prozess diese Anfrage zunächst in die sogenannte Request Queue. Diese Warteschlange, die nach dem first-in-first-out“-Prinzip organisiert ist, steht zentral ” in der SGA bereit und wird regelmäßig von allen freien Shared Server Prozessen auf Anfragen überprüft. Hat ein freier Shared Server Prozess die Anfrage aufgenommen und mit Hilfe der Datenbank abgearbeitet, stellt er das Ergebnis in die ebenfalls im SGA organisierte Response Queue. Im Gegensatz zur Request Queue existiert eine Ergebnis-Warteschlagen für jeden Dispatcher Prozess. Dieser liefert das Ergebnis letztendlich an den Benutzer-Prozess zurück. In Abbildung 4.3 zeigt diesen Ablauf in graphischer Form. Die Dispatcher Prozesse (Dnnn) Der Datenbank-Administrator kann für die Clientanmeldung an einem Shared Server System mehrere Dispatcher Prozesse anlegen, mindestens jedoch einen pro zu unterstützendem Verbindungsprotokoll. Durch die richtige Anzahl der Prozesse in einer Instanz kann der Administrator aktiv einen Performance-Gewinn erreichen. Der Dispatcher Prozess vermittelt die Benutzer-Prozesse an die Shared Server Prozesse. Der Shared Server Prozess (Snnn) Ein Shared Server Prozess bedient im allgemeinen mehrere Clients (nacheinander). Ebenso ist es möglich, dass ein Benutzer-Prozess im Laufe seines Lebenszyklus von unterschiedlichen Shared Server Prozessen bedient wird. Das hat zur Folge, dass die benutzerrelevanten Daten nicht wie beim Dedizierten Server Prozess in der PGA abgelegt werden können, da hier nur der jeweilige Prozess selbst lesen kann. Aus diesem Grund sind bei der Verteilten Server Architektur die benutzerspezifischen Daten in der SGA abgelegt, um sie verschiedenen Server Prozessen bereitstellen zu können. 23 Abbildung 4.3: Prozesskommunikation bei einer Geteilten Server Architektur, Quelle: (Michele Cyran, 2005) Im Gegensatz zu anderen Prozessen läßt sich die Anzahl der Shared Server Prozesse durch den Administrator nur bedingt steuern. Dieser kann mit Hilfe der Parameter SHARED_SERVERS und MAX_SHARED_SERVERS zwar die Grenzen der Prozessanzahl vorgeben, die tatsächlich zu einem Zeitpunkt existierenden Ausprägungen bestimmt das Oracle-System anhand der Länge der Warteschlagen für Ein- und Ausgänge der Anfragen selbst. 24 4.4 Die Exklusiv-Server Architektur (Dedicated Server Architecture) Die Dedicated Server Architektur stellt das Gegenteil zur Shared Server Architektur dar. Die Kommunikation eines Benutzer-Prozesses erfolgt hier immer über den gleichen Server Prozess. Da dieser die Client-Anfragen immer an die Datenbank weiterreicht, spricht man von einem exklusiven Server Prozess (auch Shadow Prozess genannt). Dieser Ablauf ist in Abblildung 4.4 dargestellt. Abbildung 4.4: Prozesskommunikation bei einer Exklusiv-Server Architektur, Quelle: (Michele Cyran, 2005) 25 4.5 Das Programm Interface (Program Interface) Wie in Abbildung 4.4 dargestellt, bildet die Programm Schnittstelle die Verbindung zwischen der Anwendungssoftware auf Clientseite und dem Datenbank-System auf Serverseite. Die Aufgaben dieser Schicht sind • Sicherheitsaspekte, indem der direkte Zugriff auf die SGA durch Benutzer-Prozesse verhindert werden soll, • Datenformatierung und Formatumwandlung zur reibungslosen Kommunikation sowie die • Ausgabe von Systemmeldungen wie Fehlernachrichten. Die Programm Interface Schnittstelle besteht aus diesen Bestandteilen: • Oracle call interface (OCI) oder der Oracle runtime library (SQLLIB) • Clientseitige Codebausteine in der User-Applikation (UPI) • diverser protokollspezifischer Software (Oracle Net Service drivers) • Betriebssystemeigenen Kommunikationsschnittstellen • Serverseitigen Codebausteinen in der Oracle-Umgebung (OPI) Wird eine Verbindung von einem Client über einen Benutzer-Prozess zu einem Server über einen Server Prozess hergestellt, werden in der Regel alle Schichten durchlaufen. 26 Abbildungsverzeichnis 1.1 Speicher Struktur von Oracle Datenbanken, Quelle: (Michele Cyran, 2005) 4.1 4.2 Eine Oracle-Instanz, Quelle: (Michele Cyran, 2005) . . . . . . . . . . . . 16 Hintergrundprozesse einer Oracle-Mehrbenutzer-Instanz, Quelle: (Michele Cyran, 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Prozesskommunikation bei einer Geteilten Server Architektur, Quelle: (Michele Cyran, 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Prozesskommunikation bei einer Exklusiv-Server Architektur, Quelle: (Michele Cyran, 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3 4.4 27 5 Literaturverzeichnis JP Polk Michele Cyran, Paul Lane. Oracle Database Concepts, 10g Release 2 (10.2) : B14220-02. Oracle Corp., Redwood City, CA, 2005. Paul Lane Steve Fogel. Oracle Database Administrator’s Guide 10g Release 2 (10.2) : B14231-02. Oracle Corp., Redwood City, CA, 2006. 28
