Prozessarchitektur einer Oracle-Instanz: Prozesse und deren Aufgaben, Speicherstrukturen - Tobias Kaatz, Sebastian Schneemann Juni 2007
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Prozessarchitektur einer
Oracle-Instanz: Prozesse und deren
Aufgaben, Speicherstrukturen
Tobias Kaatz, Sebastian Schneemann
Juni 2007Die Instanziierung einer modernen Datenbank ist eine komplexe Angelegenheit. Die Zusammenhänge von globaler wie privater Speicherorganisation und den darauf arbeit- enden 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 6
2.1 Speicheraufbau im SGA . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Automatisches Speichermanagement . . . . . . . . . . . . . . . . . . . . 8
2.3 Die SGA-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Database Buffer Cache (DBBC) . . . . . . . . . . . . . . . . . . 10
2.3.2 Redo Log Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3 Shared Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.4 Large Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.5 Java Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.6 Streams Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 PGA - Program Global Areas 14
3.1 Inhalt des PGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Private SQL Area . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2 Session Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3 SQL Work Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Prozessstruktur einer Oracle-Instanz 16
4.1 Der Benutzer-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Die Oracle-Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1 Die Server-Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2 Die Hintergrundprozesse . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Die Geteilte Server Architektur (Shared Server Architecture) . . . . . . 22
4.3.1 Die Dispatcher Request und Response Queues . . . . . . . . . . 23
4.4 Die Exklusiv-Server Architektur (Dedicated Server Architecture) . . . . 25
4.5 Das Programm Interface (Program Interface) . . . . . . . . . . . . . . . 26
31 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 Speicherbere-
ichen, 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 Sys-
teme (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 Spe-
icher besitzt nur eine endliche Größe, was die maximale Anzahl parallel laufender
Instanzen wiederrum beschränkt. Der Aufbau und die Funktionweise der Speicher-
Architektur 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 Daten-
1 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
4Abbildung 1.1: Speicher Struktur von Oracle Datenbanken, Quelle: (Michele Cyran,
2005)
bank, in der Regel um SQL-Statements abzusetzen oder mit Hilfe von DML Ma-
nipulationen an der Datenbank vorzunehmen. Der Oracle Datenbankserver Code hat
zur Aufgabe, die Anfragen und Änderungen der mit den Anwendungen und Oracle-
Tools 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.
52 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 Struk-
turen 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 Daten-
bank, 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 Sende-
und Empfangsqueues und ein Teil des PGA im SGA gespeichert.
62.1 Speicheraufbau im SGA
Der SGA vereint eine Anzahl unterschiedlicher Speicherkomponenten. Diese werden
benötigt, da innerhalb der Instanz unterschiedliche Allokations-Konzepte verfolgt wer-
den. 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 Beein-
trä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.
72.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 Spe-
ichermanagement 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 Unterstruk-
turen 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 Oracle-
Datenbank-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 Speicher-
größ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 Daten-
bank verteilt nach Bedarf den Speicher, damit der gesamte SGA optimaler genutzt
werden kann.
Ein offensichtlicher Vorteil der Automatisierung ist die Vereinfachung des Konfigu-
rationsprozesses 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
8Tuning vorgenommen werden muss. Manuelles Konfigurieren kann möglicherweise be-
wirken, 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 bee-
influssen die System-Performance.
Die automatische SGA-Verwaltung beinhaltet einen Tuning-Algorithmus, der den work-
load 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 hard-
parses.
92.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 bein-
haltet 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.
102.3.2 Redo Log Buffer
Der redo log buffer beinhaltet Informationen über die auf der Datenbank vorgenomme-
nen Ä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 Nachricht-
en 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 Kontroll-
strukturen 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 Parser-
Baum) 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.
11Oracle allokiert Speicher vom Shared Pool zu dem Zeitpunkt an dem ein neues SQL-
Statement 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 Spe-
ichersegmente 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 al-
lokiert 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 Package-
Variablen 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 enthal-
ten 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 Architek-
turen
• I/O Server-Prozesse
• Oracle interne Backup- und Restore-Operationen
verwendet.
12Der 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 Performanceverbesserun-
gen 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.
133 PGA - Program Global Areas
Ein PGA ist ein Speicherbereich der, genau wie der SGA, Daten und Kontrollinforma-
tionen 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 Ora-
cle 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 verwen-
deten 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-Speicher-
Strukturen(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.
143.1.3 SQL Work Areas
Komplexe Queries erfordern auch einen großen Teil des Laufzeitspeichers um bearbeit-
et 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 ein-
schließlich der Speicherstrukturen des Operators im Speicher Platz finden.
154 Prozessstruktur einer Oracle-Instanz
Die meisten Datenbanken werden als Mehrbenutzersysteme betrieben. Dies setzt ein-
erseits eine strikte Trennung von sensiblen Bereichen der Anweisungen aus Sicherheit-
saspekten, 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 (un-
terer 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.)
164.1 Der Benutzer-Prozess
Wie in Abbildung 4.1 dargestellt, erzeugt jede Verbindung eines Nutzers mit Applika-
tionen 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. Kommunika-
tion ü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 aufge-
treten 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.
174.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 betriebssystem-
und 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 schaf-
fen. 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 Ring-
puffer realisiert. Der Log Writer Prozess stellt sicher, dass immer genügend Speich-
1 least recently used, Seiteverdrängungsstrategie für Speicher
18Abbildung 4.2: Hintergrundprozesse einer Oracle-Mehrbenutzer-Instanz, Quelle:
(Michele Cyran, 2005)
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.
19Ereignis Wirkung beim DBWn
Dirty-Liste ist voll DBWn schreibt Puffer weg
Kein freier Platz in LRU- DBWn schreibt Puffer aus LRU-Liste weg
Liste vorhanden
Zeitintervall von 3 Sek. DBWn schreibt Dirty-Puffer von LRU-Liste in Dirty-Liste.
Wird Schwellwert erreicht, werden Puffer auf Festplatte
geschrieben
Checkpoint erreicht 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 Sicher-
heit der Redo-Log-Files die mit Hilfe von Redundanz erreicht wird: Die Redo-Log-
Files können bei Bedarf in sogenannten mirrored groups“ organisiert werden. Alle
”
Mitglieder-Dateien enthalten den gleichen Zustand, da der LGWR bei einem Schreib-
prozess alle Mitglieder aktualisiert. Der Ausfall einzelner Dateien aus einer Gruppe
wird im System-Alert-Log vermerkt; die restlichen Mitglieder-Dateien werden weiter-
hin 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.
20Der Process Monitor Prozess (PMON)
Schlägt ein Benutzer-Prozess fehl, ist es die Aufgabe des PMON alle dadurch beende-
ten Prozesse erneut zu starten, bis sie nicht mehr gebraucht werden. Ist ein Benutzer-
Prozess beendet, gibt der PMON die nun nicht länger benötigten Ressourcen (beispiel-
sweise 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 Betriebssys-
temebene 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 Archiver-
Prozesse, 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 wieder-
herzustellen
21Weitere 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 Technolo-
gie, welche die Einschränkung, dass jeweils ein Server-Prozess genau einen Benutzer-
Prozess (vgl. Kapitel 4.2.1) bedienen kann, aufhebt. Statt dessen werden die Server-
Prozesse als sogeannte geteilte Server-Prozesse in einem Pool bereitgehalten und ord-
nen sich, sobald sie frei sind, dem nächsten hereinkommenden Benutzer-Prozess zu, in-
dem sie diesen aus einer Warteschlange herauslösen. Durch die Einsparung von Server-
Prozessen (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 Herun-
terfahren einer Instanz oder das Recovery von Daten. Jedoch kann sich ein Client falls
gewünscht durch die Angabe des Parameters "‘SERVER=DEDICATED"’ im Connecting-
String 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 entschei-
det anhand der vom Client übermittelten Informationen ob dieser einen Shared Server
nutzen kann. Ist dies der Fall übermittelt der Listener dem Client die Verbindungsin-
formationen 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 Vo-
raussetzung 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 let-
ztendlich 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 unter-
stützendem Verbindungsprotokoll. Durch die richtige Anzahl der Prozesse in einer
Instanz kann der Administrator aktiv einen Performance-Gewinn erreichen. Der Dis-
patcher 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 be-
nutzerrelevanten 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.
23Abbildung 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 Parame-
ter 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.
244.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)
254.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.
26Abbildungsverzeichnis
1.1 Speicher Struktur von Oracle Datenbanken, Quelle: (Michele Cyran, 2005) 5
4.1 Eine Oracle-Instanz, Quelle: (Michele Cyran, 2005) . . . . . . . . . . . . 16
4.2 Hintergrundprozesse einer Oracle-Mehrbenutzer-Instanz, Quelle: (Michele Cyran,
2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Prozesskommunikation bei einer Geteilten Server Architektur, Quelle:
(Michele Cyran, 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Prozesskommunikation bei einer Exklusiv-Server Architektur, Quelle:
(Michele Cyran, 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
27Literaturverzeichnis
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.
28Sie können auch lesen
