Oracle-Server Bestandteile

Oracle Server: DB-Instance + Datenbank

• Instance
  • System Global Area (SGA)
    • Shared Pool
      • Library Cache
      • Data Dictionary Cache
    • Database Buffer Cache
    • Redo Log Buffer
    • Java Pool
    • Large Pool
  • Background Process Structures
    • PMON
    • SMON
    • DBWR
    • LGWR
    • CKPT
    • Optionale Background-Prozesse
      • ARCn
• Datenbank
  • Database Files (Operating System Files)
    • Datafiles
    • Control Files
    • Redo Logfiles
• Other Key Files
  • Parameter Files
  • Password File
  • Archive Redo Logfiles
• User und Server Prozesse
  • Server Process - Program Global Area (PGA)
  • User Process
• Andere Prozesse
  • Advance Queuing
  • Real Application Clusters
  • Shared Server
  • Advanced Replication
  • ...

Instance

Man startet nie eine Datenbank. Man startet eine Instanz. Diese ermöglicht den Zugriff auf die Datenbank. Eine Instanz öffnet eine und nur eine Datenbank.

Eine Instanz muss beim Start initialisiert werden. Dadurch werden die Initialisierungsparameter festgelegt. Dies erfolgt durch ein SPFILE bzw. ein PFILE (siehe Parameter Files, Seite ).

System Global Area (SGA)

Beim Start einer Instanz wird Arbeitsspeicher für den SGA zugewiesen. SGA ist dynamisch anpassbar (ausser Gesamtgröße ). Das heißt die Instanz braucht nicht heruntergefahren zu werden um die SGA-Konfiguration zu ändern. SGA_MAX_SIZE definiert die maximale Größe der SGA.

     DB_CACHE_SIZE (BUFFER_CACHE)
+ SHARED_POOL_SIZE 
+   JAVA_POOL_SIZE 
+  LARGE_POOL_SIZE
------------------ 
<=    SGA_MAX_SIZE

Anzeige der Speicherzuweisung:

show sga;

Die Speicherzuweisung erfolgt schrittweise (Granulate). Die Granulat-Größe ist abhängig von der SGA-Größe (4MB bei SGA <128MB, ansonsten 16MB).

ALTER SYSTEM SET SGA_MAX_SIZE = xxxM;

Shared Pool:

Der Shared Pool speichert die zuletzt verwendeten SQL Statements und Datendefinitionen. SHARED_POOL_SIZE definiert die Größe des Buffers für shared SQL und PL/SQL (Default 16MB bei 32bit bzw. 64MB bei 64 bit).

Library Cache:

Der Library Cache speichert die zuletzt verwendeten PL/SQL-Statements (parsed SQL statements) mittels LRU-Algorithmus (Last Recently Used).

Data Dictionary Cache:

Der Data Dictionary Cache speichert die zuletzt verwendeten Objekte (Tabellen, Views, ...).

Database Buffer Cache:

Der Database Buffer Cache speichert die zuletzt verwendeten Kopien von Datenblöcken mittels LRU-Algorithmus. Der Database Buffer Cache besteht aus den Sub-Caches:
DB_CACHE_SIZE definiert die Größe des Cache für Standard-Blocks (Default 48MB bei UNIX bzw. 52 MB bei NT).
DB_KEEP_CACHE_SIZE ist die Größe des Keep Buffer Cache, welcher Blöcke zum Wiederverwenden speichert.
DB_RECYCLE_CACHE_SIZE ist die Größe des Recycle Cache, welcher nicht verwendete Blöcke aus dem Speicher entfernt.
DB_BLOCK_SIZE bestimmt die Primary Block Size.

Redo Log Buffer:

Der Redo Log Buffer ist ein Circular Buffer und speichert Änderungen von Datenblöcken. LOG_BUFFER definiert die Größe des Redo Log Buffer in Bytes.

Java Pool:

Der Java Pool ist optional und wird für Java verwendet. JAVA_POOL_SIZE definiert die Größe des Java Pools (Default 24MB).

Large Pool:

Der Large Pool ist ein optionaler Speicherbereich im SGA. Er wird für Session Memory verwendet bei Shared Server. Weitere Anwendungen sind I/O, Backup/Restore (RMAN), ... Der Large Pool verwendet kein LRU-Algorithmus. LARGE_POOL_SIZE definiert die Größe des Large Pools (Default 0). LARGE_POOL_SIZE ist nicht dynamisch.

Background Process Structures

Beim Start einer Instanz werden die Background-Prozesse gestartet.

PMON:

Fehlerhafte Prozesse im PGA werden durch den Process Monitor (PMON) aufgeräumt mittels:

• Zurückrollen der Transaktion
• Freigeben von Locks
• Freigeben anderer Resourcen.
• Neustart von toten Dispatchern.

SMON:

Bei einem Crash können keine Informationen des SGA auf die Festplatten geschrieben werden. In diesem Fall führt der System Monitor (SMON) ein automatisches Instanz-Recovery durch. Dies beinhaltet folgende Schritte:

1. Daten, die nicht vom Database Buffer Cache in die Database Files geschrieben wurden, werden aus den Redo Logs gelesen und in die Database Files geschrieben.
2. Öffnen der Datenbank, so dass User sich einloggen können. Daten, die nicht durch abgebrochene Transaktionen gesperrt sind (Locks), stehen zur Verfügung.
3. Transaktionen ohne abschließendes COMMIT werden zurückgerollt.

Der SMON führt auch Speicherverwaltungsaufgaben durch.

• Benachbarte Bereiche in den Database Files werden zusammengefasst.
• Temporäre Segmente werden in den Database Files freigegeben.

DBWRn:

Der Database Writer schreibt Dirty Buffers von dem Database Buffer Cache in die Database Files. Er verzögert dies aber bis eines der folgenden Ereignisse eintritt:

• Ein Checkpoint wird gesetzt.
• Der Bedarf an Dirty Buffer übersteigt einen Grenzwert.
• Timeout
• Ein Real Application Cluster (RAC) Ping Request erfolgte.
• Ein Tablespace wird offline gesetzt.
• Ein Tablespace wird read only gesetzt.
• Eine Tabelle wird mit DROP oder TRUNCATE gelöscht.
• ALTER TABLESPACE tablespace name BEGIN BACKUP;

LGWR:

Der Log Writer (LGWR) schreibt sequentiel vom Redo Log Buffer in die Redo Log Files wenn eines der folgenden Ereignisse eintritt:

• COMMIT
• Der Redo Log Buffer 1/3 voll ist.
• Wenn mehr als 1MB an Änderungen im Redo Log Buffer sind.
• Alle drei Sekunden.
• Bevor der DBWR schreibt.

Da Redo Files für das Recovery benötigt werden, bestätigt der LGWR einen COMMIT-Befehl erst nach dem erfolgreichen Schreiben in die Redo Logs. In den Redo Logs wird jeweils der gesamte Datensatz geschrieben. Der LGWR kann den DBWR beeinflussen, dass dieser in die Datafiles schreibt.

CKPT:

Alle drei Sekunden schreibt der CKPT-Prozess Daten in die Control-Files, um die Stellen in den Redo Logs zu kennzeichnen, bei denen ein Recovery beginnen muss. Diese Daten nennt man Checkpoints. Erfolgt ein Log Switch wird auch ein Checkpoint geschrieben.

Checkpoints werden aus folgenden Gründen iniziiert:

• Um sicherzustellen, das die modifizierten Datenblocks regelmäßig auf die Fetplatten geschrieben werden.
• Zur Verringerung des Zeitaufwandes beim Instanz-Recovery.
• Zur Sicherstellung, das bei einem Shutdown alle committeten Daten in die Database Files geschrieben werden.

Beachte: Der CKPT schreibt keine Datenblocks auf die Festplatten oder Redo-Blocks in die Redo-Logs.

Optionale Background-Prozesse

ARCn:

Von den optionalen Background-Prozessen wird hier nur der ARCn besprochen. Der ARCn dient zum Erstellen der Archive Log-Files. Die Archive Log dienen dem Offline-Recovery.

Die Online Redo Logs werden nacheinander geschrieben. Wenn es drei Redo Log Files gibt, wird erst in die erste Datei geschrieben. Ist diese voll, wird in die zweite Datei geschrieben. Ist das zweite Redo Log File voll, wird in die dritte Redo Log Datei geschrieben. Ist die dritte Datei voll, beginnen die Schreiboperationen wieder bei der ersten Datei. Die ursprünglichen Informationen der ersten Datei gehen dabei verloren. Um dies zu verhindern, gibt es die Möglichkeit vollgeschriebene Redo Log Files zu archivieren. Man nennt diese dann Offline Redo Logs bzw. Archive Logs und den Prozess der dies steuert den Archiver (ARCn). Die Offline Redo Logs sollten auf eine separaten Platte gespeichert werden und von dort aus gesichert werden.

Die Voreinstellung ist NOARCHIVELOG, dass heisst es werden keine Archive Logs geschrieben. Dies sollte unbedingt auf den ARCHIVELOG Mode geändert werden.

Datenbank

Database Files - Die physikalische Struktur

Die Datenbank Dateien, auch Operating System Files genannt, speichern physikalisch die Datenbank-Informationen. Sie stellen auch ein Recovery bei Fehlern sicher.

Datafiles:

Die Datafiles enthalten die aktuellen Daten der Datenbank.

Control Files:

Die Control Files ermöglichen die Überprüfung und Sicherstellung der Datenbank-Integrität.

Redo Logfiles:

Die Redo Logfiles enthalten Informationen über die letzten Änderungen und dienen zur Online-Sicherung bzw. -Recovery. Beim Online Recovery braucht die Datenbank nicht heruntergefahren werden. Redo Logfiles sind keine Log Files im herkömmlichen Sinn. Sie sind Binärdateien.

Logische Struktur einer Datenbank

Eine Datenbank enthält mindestens einen Tablespace. Ein Tablespace enthält einen oder mehrere Segmente. Ein Segment besteht aus Extents. Extents bestehen aus Blöcken. Blöcke sind die kleinste Einheit für Lese- und Schreiboperationen.

Datenbank
  Tablespace
    Segment
      Extent
        Block

Die Standard-Blockgröße ist 8k (DB_BLOCK_SIZE). Diese sollte der Betriebssystem-Blockgröße entsprechen. Die Blockgröße wird bei der DB-Erstellung festgelegt und kann später nicht geändert werden.

Other Key Files

Parameter Files - (S)PFile:

Die Parameterfiles initialisieren die Instanz beim Start (siehe Seite ).

Password File:

Mit Hilfe des Password Files erfolgt die Authentifizierung von Usern.

Archive Redo Log Files:

Archive Redo Log Files sind archivierte Redo Log Dateien. Sie werden nicht mehr beschrieben und können gesichert werden. Sie dienen dem Offline-Recovery.

User- und Server Prozesse

Die User- und Server-Prozesse ermöglichen das Ausführen von SQL-Statements. User-Prozesse nehmen nie direkten Kontakt zur Instanz auf. Dazu wird ein Server-Prozess gestartet. Für diese Zeit wird also eine Session erzeugt.

Dedicated Server vs. Shared Server:

Man unterscheidet eine eins-zu-eins Korrespondenz zwischen User- und Server-Prozess (Dedicated Server Connection) oder eine n-zu-eins Korrespondenz (Shared Server Connection).

Dedizierte Server-Konfiguration:

Bei der dedizierten Server-Konfiguration ist jedem Benutzer-Prozess ein eigenen Server-Prozess zugeordnet. Wird eine neue Benutzer-Verbindung zur Datenbank hergestellt, so wird für diesen Benutzerprozess ein Server-Prozess zur Verfügung gestellt. Dieser Server-Prozess dient einzig und allein diesem einen Benutzer-Prozess. Falls der Benutzer-Prozess Freiraum hat, so ist auch der zugehörige Server-Prozess beschäftigungslos.

Shared Server:

Die Shared Server Konfiguration wird seltener benutzt. Verwendung findet diese bei Internet-Datenbank-Konfigurationen. Siehe Seite .

Server Process - Program Global Area (PGA)

Der Listener-Prozess registriert Verbindungswünsche von User-Prozessen. Server Prozesse werden dann auf Verlangen von User-Prozessen gestartet und führen stellvertretend dessen SQL-Statements aus und liefert die Ergebnisse an den User-Prozess. Der Server Process läuft auf der Maschine, auf der auch die Instanz läuft. Dabei wird für jeden User ein Dispatcher erstellt. Prioritäten kann man dabei nicht zuweisen. Wenn ein Server-Prozess startet, wird ihm Arbeitsspeicher zugewiesen. Diesen nennt man Program Global Area (PGA). Nach dem Beenden des User-Prozesses wird der PGA wieder freigegeben. Der PGA besteht aus diesen Komponenten:

• Private SQL Area
  • Persistent Area
  • Run-Time Area
• Session Memory
• SQL Work Areas

User Process

Der User-Prozess läuft meist auf der lokalen Maschine des Benutzers bzw. auf einem Applikationsserver.