Prozessarchitektur einer Oracle Instanz: Prozesse

Prozessarchitektur einer Oracle Instanz:
Prozesse, Speicherstrukturen und
Logging
Reichmann, Chrisian
1. Juli 2008
1
Inhaltsverzeichnis
1 Einführung in die Thematik
3
2 Die Prozessarten
4
3
2.1
Der Benutzerprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Der Listenerprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Die Hintergrundprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.1
Der Archivierungsprozess ( ARCH )
. . . . . . . . . . . . . . . . . .
6
2.3.2
Der Checkpointprozess ( CKPT ) . . . . . . . . . . . . . . . . . . . .
7
2.3.3
Der Datenbank-Schreib-Prozess ( DBWR ) . . . . . . . . . . . . . . .
10
2.4
Der Redo-Log-Schreibprozess ( LGWR ) . . . . . . . . . . . . . . . . . . . .
12
2.5
PMON und SMON Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.6
Recoverer-Prozess ( RECO ) . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
System global area ( SGA )
14
3.1
Der DB-Block Buffer Pool ( Data Buffer Cache ) . . . . . . . . . . . . . . . .
15
3.2
Redo Log Puffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4 Literaturliste
21
1 Einführung in die Thematik
Sobald sich ein Nutzer mit einer Oracle-Datenbank ( im Folgenden mit DB abgekürzt ) verbindet
egal mit welcher Methode, ist eine Datenbankinstanz von Nöten, die den DB-Cache und die
Hintergrundprozesse verwaltet. Dabei können die Prozesse in einigen Betriebssystemen auch
Threads sein. Die Funktionsteilung der einzelnen Aufgaben ist Oracle spezifisch und bildet die
grundlegende Softwarestruktur der Oracle-Datenbank.
Es gibt fünf unterschiedliche Prozessarten:
1. Benutzerprozesse
2. Listenerprozesse
3. Dispatcherprozesse
4. Oracle-Serverprozess ( Kernel )
5. Oracle-Hintergrundprozesse
2 Die Prozessarten
2.1 Der Benutzerprozess
Jedes Programm mit einer Schnittstelle zum Oracle-Datenbankserver wird als Benutzerprozess
gesehen. Dieser Prozess wird meist auf dem lokalem Rechner des Benutzers oder auf einem
Applicationserver ausgeführt.
Die Aufgabe vom Benutzerprozess ist der Aufbau einer Verbindung mit dem Listenerprozess.
Um eine Session aufzubauen, muss der User seinen Benutzernamen und sein Passwort angeben.
2.2 Der Listenerprozess
Nachdem ein Listenerprozess eine “Connect”-Anfrage von einem Benutzerprozess ( im Folgenden mit Up ( userprocess ) abgekürzt ) erhalten hat, besitzt dieser die Aufgabe das Programm
von dem die Anfrage stammt, mit der DB zu verbinden. Der Verbindungsaufbau kann mit verschiedenen Methoden passieren:
• dedicated
Up direkt mit dem Serviceprozess verbunden
alle Requests werden vom Serverprozess beantwortet
diese Ausführung ist gut für viele Anfragen, die schnell beantwortet werden müssen
und auch auch aufwändig sind
• shared
Up direkt mit Dispatcherprozess verbunden
es werden mehrere Up mit einem Dispatcherprozess verbunden
gut bei vielen Nutzern auf einer Datenbank
2.3 Die Hintergrundprozesse
Die Hintergrundprozesse entscheiden sich von den bisher beschriebenen Prozessen durch ihre
Wirkungsreichweite, da alle Hintergrundprozesse ( Backgroundprocesses ) Systemweit wirken.
Aus Leistungsgründen werden bei einem Oracle-System im “Multiusermode” mehrere Prozesse
im Hintergrund verwaltet, die für einen fehlerlosen und sicheren Ablauf der Benutzerverbindungen sorge tragen. Die Anzahl der Hintergrundprozesse können je nach Betriebssystem und
Konfiguration des Oracle-Systems variiren. Auch innerhalb einer Instanz müssen nicht zu jedem
Zeitpunkt gleich viele Prozesse am Arbeiten sein. Die wichtigsten dieser Prozesse werden im
Folgendem erklärt.
2.3.1 Der Archivierungsprozess ( ARCH )
Der Archivierungsprozess ist aktiv, wenn das Oracle-System im “archive”-Modus arbeitet. Dieser Prozess ermöglicht als einziger ein Recovery nach einem Plattenfehler.
Der ARCH-Prozess archiviert alte Redo-Log Files an einen anderen Festplattenplatz, vom dem
aus dann die Log Files auf andere Medien gesichert werden können. Online-Redo-Log Files
werden erst dann wieder zum Schreiben freigegeben, wenn diese archiviert wurden.
Der Archivierungsprozess wird vom LGWR-Prozess aktiviert, wenn dieser einen Redo-Log Filewechsel durchführt. Der ARCH-Prozess erhält die Information, welche Redo-Log-Gruppe archiviert werden sollen. Die Redo-Log Datei kann erst dann wieder überschrieben werden, wenn
der ARCH-Prozess die Datei archiviert und wieder freigegeben hat.
Maximal können 10 Arch-Prozesse aktiv sein, diese Anzahl kann im laufenden Betrieb verändert werden.
Es können maximal fünf Zieladressen für das Wegschreiben der Dateien angegeben werden.
2.3.2 Der Checkpointprozess ( CKPT )
Ein Oracle-System bestimmt Checkpoints oder einen Recovery-Aufsetzpunkt, damit im Fall eines Fehlers die beschädigten Daten wiederhergestellt werden können. Die einfachste Methode
diese Ausfallsicherheit zu erreichen, ist das Zurückschreiben von DB-Blöcken, die noch im DBCache gehalten werden. Somit wird erreicht, dass alle Änderungen der DB-Blöcke auch in den
Datendateien wiedergefunden werden können. Als Zusatz wird im Control File und in den Headern der Datendateien die Kontrollpunktstruktur hinterlassen, so dass das Oracle-System eine
Instanzwiederherstellung1 anfertigen kann.
Es werden u.a. die höchste System Change Number ( SCN ) zum Kontrollpunktzeitpunkt und
die Redo Block Adresse ( RBA )2 in den Datendateikopf geschrieben.
Die Checkpointerstellung verursacht eine kurzzeitige hohe Systemauslastung, aber es kann dennoch ohne Einschänkungen auf dem DB-System weitergearbeitet werden. Es kommt auch nicht
zur Beendigung von anderen Prozessen, somit kann der CKPT-Prozess vollständig autark laufen.
Der bisher genannte Ablauf bei der Checkpointerstellung ist nicht der einzige Fall, der innerhalb einer Oracle-Instanz auftreten kann. Es wird zwischen Level 1 bis Level 3 Kontrollpunkten
unterschieden. Die folgende Tabelle zeigt die Auslöser und die Aktionen, die ausgeführt werden.
1
Instanzwiederherstellung( Crash-Recovery ): Wiederherstellung des DB-Caches und des Buffer-Caches nach dem
die DB-Instanz nicht ordnungsgemäß beendet wurde.
2
RBA gibt an, an welcher Stelle in der Redo-Log Datei der erste für ein Recovery relevante Redo-Block steht
Checkpoint-
- Auslöser
Aktionen
- Redo-Log Switch
Betrifft die gesamte Datenbank alle on-
Level
1
line Dateien der DB
- Shutdown normal, Immediate
Kontrollpunktstruktur wird in Header
der Daten- und Kontrolldateien geschrieben
- alter System switch log
2
- inkrementeller Checkpoint
Betrifft gesamte Datenbank
- keine externen Auslöser
Checkpoint ständig weitergeschrieben
- Erweiterung
des
Buffer-
Managements
DBWR schreibt DB-Blöcke zurürck
die länger im Buffer-Cache oder inaktiv sind
-
Kontrollpunktstruktur in Control-File
geschrieben
3
- Tablespace wird offline gesetzt
Betrifft nicht die gesamte Datenbank
normal oder immediate
- Datafile wird offline gesetzt nor-
Betrifft einzelne Files
mal oder immediate
- Tablespace wird von read-write
nach read only umgestellt
Kontrollpunktstruktur in alle betroffenen Dateiheader und Controlfiles geschrieben
Da es beim LRU Verfahren dazu kommen kann, dass einige DB-Blöcke nicht aus dem DBCache zurückgeschrieben werden, wird unabhängig davon die Verweildauer der einzelnen Blöcke gemessen, um auch diese zu sichern. Dieses Verfahren wird beim inkrementellen Checkpoint
verwendet. Mit Hilfe von dieser Eigenschaft kann dem Oracle-System eine Zeit vorgegeben werden, in der die Instanz-Recovery abgeschlossen ist, da die Dauer der Instanz-Wiederherstellung
abhängig von dem ältesten, veränderten Block ist.
Ein Kontrollpunkt ist ein Ansatzpunkt innerhalb eines Redo-Log-Files für die Instanzwiederher-
stellung, der angibt, von welcher Stelle die Wiederherstellung anfangen soll. Daher hängt die
Dauer des Recovery-Vorgangs davon ab, wie lange der alte Speicherstand her ist, da in der Zwischenzeit mehrere Veränderungen durchgeführt werden können, die wiederhergestellt werden
müssen.
Neben dem Checkpointprozess kümmert sich der DBWR-Prozess3 um die DB-Blöcke, welche
aus dem DB-Cache zurückgeschrieben werden müssen. Dennoch ist der Kontrollpunktprozess
von großer Wichtigkeit, dieser wird alle 3s aktiviert und schreibt die Checkpointstruktur in die
Header der Daten-Files und in die Kontrolldateien. Im Level eins und drei werden die Kontrollinformationen in alle beteiligten Dateien geschrieben, wohingegen bei Level zwei nur die
Kontrolldatei verändert wird.
3
DB Write Prozess
2.3.3 Der Datenbank-Schreib-Prozess ( DBWR )
Der DBWR-Prozess ist der einzige Prozess, der Daten aus dem DB-Cache auf die Platte schreiben kann. Er kann von mehreren Vorgängen ausgelöst werden.
• Freie Pufferanfrage
Ein Prozess signalisiert, dass der Buffer-Cache voll ist
• Timeout des Schreibprozesses
Wenn kein Prozess den DBWR-Prozess innerhalb einer Timeoutzeit von 3s aufruft,
wird er automatisch gestartet
• Kein freier Platz in der LRU4 -Liste
DBWR schreibt die Daten aus dem Puffer auf die Platte
• Ein Kontrollpunkt wurde erreicht
Vom Dirty Puffer in der LRU-Pufferliste in die Dirty-Liste geschrieben und von dort
auf Festplatte
Der Schreibprozess durchsucht die LRU-Liste5 nach veränderten Daten und kopiert gefundene
in die LRUW-Liste6 . Alle unveränderten werden in die LRU-Aux-Liste kopiert und können ab
sofort überschrieben werden. Alle Einträge in der LRUW-Liste werden vom DBWR-Prozess in
die DB-Dateien geschrieben. Anschließend werden die Listen auf den Stand der LRU-Aux-Liste
gesetzt.
Es gibt zwei verschiedene Arten von Anfragen an den Schreibprozess:
• Parallel Serveranfrage
Wenn eine Datenbankinstanz ein Datenblock aus einer anderen Instanz benötigt, wird
4
LRU: Last recently used eine Methode zur Speicherverwaltung
LRU-Liste: Speicherstruktur, in der die zuletzt angeforderten Daten stehen
6
LRUW-Liste: Speicherstruktur, in der die zuletzt veränderten angeforderten Daten stehen
5
der DBWR-Prozess vom LCK0-Prozess7 ausgelöst, und schreibt die Daten vom DBBuffer-Cache in die Datenbankdateien
• Anfrage vom Checkpointprozess
7
LCK0-Prozess: (Paralleler Lock Manager) Wenn das Oracle System auf Parallel Server Modus eingestellt ist, wird
dieser Prozess mitgestartet. Es kann bis zu 10 dieser Prozesse im Oracle-System geben
2.4 Der Redo-Log-Schreibprozess ( LGWR )
Der Redo-Log-Schreibprozess kümmert sich um das korrekte Schreiben der Redo-Blöcke aus
dem DB-Cache auf die Datenbankdateien und sichert, dass die Blöcke in die richtige Redo-LogGruppe geschrieben werden. Mit dem Start einer Oracle-Instanz wird dieser Prozess mitgestartet
und kann durch folgende Vorgänge ausgelöst werden:
• Ein Benutzerprozess beendet eine Transaktion mit einem “commit”
in diesem Fall wird durch den Serverprozess ein “Commitrecord” gebildet
der Record wird in den Redo-Log-Puffer geschrieben, dadurch wird der LGWRProzess ausgelöst
jetzt wird der Eintrag in die Redo-Log-Datei übertragen
• Wenn der Redo-Log-Puffer bis zu
1
gefüllt ist
3
schreibt der LGWR-Prozess alle Daten aus dem Redo-Log-Puffer in die Redo-LogDatei
die Änderungsdaten können aus mehreren Transaktionen stammen
• Wenn Redo-Log-Schreibprozess seit 3s nicht mehr ausgelöst wurde
• Wenn der DBWR-Prozess Daten zurückschreiben will, die sich noch im Redo-Log-Puffer
befinden
Sollte eine Redo-Log-Datei nicht mehr genügend Speicherplatz beinhalten, wird vom LGWRProzess der DBWR-Prozess ausgelöst. Es wird eine neue Redo-Log-Datei angelegt und ein Kontrollpunkt gesetzt. Alle Daten, die sich noch im Buffer befinden, werden, vom LGWR-Prozess
ausgewählt, durch den DBWR-Prozess in die DB-Files abgelegt. Nachdem alle Daten geschrieben wurden, kann die neue Redo-Log-File beschrieben werden.
2.5 PMON und SMON Prozess
Der Prozessmonitor- und Systemmonitor-Prozess übernehmen innerhalb des Oracle-Systems
Aufgaben, die automatisch im Hintergrund ausgeführt werden.
Der PMON-Prozess sucht nach Prozessen, die keinem Benutzerprozess mehr zugeordnet sind,
beendet diese und gibt die gesperrten Ressourcen wieder frei zur Wiederverwendung.
Der SMON-Prozess führt zum einen die Instanz-Recovery durch und zum anderen verwaltet er
globale Speicherbereiche von zusammenliegenden Abhängigkeiten ( Extends sind TablespaceAbhängigkeiten, die von eingestellten Storage-Einstellungen abhängig sind ). Diese treten jedoch nur bei dictonary managed tablespaces auf.
2.6 Recoverer-Prozess ( RECO )
Der Recoverer-Prozess hat die Aufgabe Fehler aufzulösen, die durch Verteiltetransaktionen hervorgerufen werden, z.B. wenn das zwei Phasen-Commit benutzt wird. Dazu verbindet sich der
Reco-Prozess mit der beteiligten Datenbank und wartet so lange bis alle angeforderten Daten
angekommen sind. Im Fehlerfall wird ein Rollback ausgeführt, so als ob es sich nur um eine
Einzeltransaktion handelt.
3 System global area ( SGA )
Wie jeder Prozess benötigt eine Oracle-Instanz Speicher. Der Hauptteil wird vom SGA vereinnamt. SGA steht für system global area und beinhaltet Verwaltungsinformationen für die benötigten Prozesse, zusätzlich wird die Kommunikation der einzelnen Prozesse über diesen Speicher
realisiert. Durch die Bereitstellung der Speicherstrukturen ist es erlaubt, dass mehrere Nutzer
auf das selbe Objekt lesend zugreifen. Durch diesen Aspekt wird dieser Speicher auch oft als
shared global area angesehen. SGA ist geteilt in die folgenden Bereiche:
• Data Buffer Cache
• Dictionary Cache
• Redo Log Puffer
• Shared SQL Pool
3.1 Der DB-Block Buffer Pool ( Data Buffer Cache )
In dem Buffer Cache werden DB-Blöcke gespeichert. Diese können Tabellen-, Rollbacksegmenteoder Index-Blöcke sein. Der Großteil der Prozesse bewirken Änderungen im DB-Buffer. Nur der
Serverprozess darf Daten von der Platte laden und in den Buffer schreiben lassen.
Der Buffer-Pool reduziert die Ladezeiten, die durch Plattenzugriffe entstehen, da alle Operationen im Buffer ausgeführt werden. Folgende Operationen sind möglich:
• Daten lesen oder verändern
• Daten einlesen vom Festplattenspeicher
• Zurückschreiben modifizierter DB-Blöcke
Um die Recovery-Zeit und Platz im Buffer zu schaffen ist die Operation, die für das Write-Back
verantwortlich ist, nicht an Transaktionen gebunden. Für die effiziente Nutzung dieses Speichers
gibt es die LRU8 - und die LRUW9 -Listen. Wobei jede dieser Listen nochmal in -Aux und -Main
unterschieden werden.
Die LRU-AUX Liste beinhaltet alle freien Puffer, die für neue DB-Einträge genutzt werden können. In der LRU-Main-Liste sind die Puffer enthalten, in denen Einträge stehen, dabei kann noch
zwischen modifizierten ( dirty ) und unveränderten ( clean ) Werten unterschieden werden. Auf
den ersten Stellen werden die meist benötigten DB-Blöcke gespeichert, demnach stehen an den
hintersten Stellen die nicht oft benutzten Blöcke.
Wenn eine Anfrage nach einem Datenblock gestellt wurde, wird immer als erstes im DB-Cache
geschaut, ob sich dieser schon im Cache befindet. Sollte dies nicht der Fall sein, liest der Serverprozess den gesuchten Block ein und sucht eine freie Speicherstelle in der LRU-AUX-Liste.
Wenn ein Platz gefunden ist, wird dieser Speicherbereich aus der LRU-Aux-Liste ausgetragen
und in die LRU-Main-Liste an mittlerer Position eingefügt. Erst nachdem eine weitere Operation auf diesem Speicherbereich ausgeführt wurde, wird er an die erste Stelle der Main-Liste
geschoben.
Da die LRU-Listen eine bestimmte Größe haben, muss der DBWR-Prozess dafür sorgen, dass
8
9
LRU: Last recently used
LRUW: Last recently used write
modifizierte “alte” Werte zurück in den DB-Dateien geschrieben werden. Dafür wird die LRUMain-Liste von hinten durchlaufen, um zum einen die unveränderten Werte in die LRU-AuxListe zu übertragen, so dass dieser wieder zum Beschreiben freigegeben ist, und zum anderen
die modifizierten Speicherblöcke in die LRUW-Main-Liste zu schreiben. Diese sind jetzt Kandidaten für den nächsten Schreibvorgang. Nachdem die Daten-Blöcke gespeichert sind, müssen
diese in die LRUW-Aux-Liste eingetragen und mit Hilfe von einem “Flag” als unmodifiziert
gekennzeichnet werden. Jetzt stehen die weggeschriebenen DB-Blöcke zum Schreiben bereit.
Ein großer Vorteil besteht in der Verfügbarkeit der Daten, da diese zwar gespeichert sind, aber
dennoch ihren ursprünglichen Wert beinhalten und somit immer noch direkt ausgelesen werden
können. Sollte diese Speicherstelle benötigt werden, kann sie jedoch überschrieben werden.
Diese Vorgehensweise hat sehr gute Laufzeiten, wenn es wenige Blöcke gibt, auf die sehr oft
zugegriffen wird. Sollte z.B. eine komplette Tabelle durchsucht werden, dann wäre dieses Prinzip ein Flaschenhals, da jeder Block an die erste Stelle eingefügt werden müsste. Da sonst alle
aktiven Einträge entfernt würden, werden bei Table-Scans die Einträge an das Ende der LRUMain-Liste angefügt10 .
Da auf Parallelität nicht verzichtet werden kann, wird eine Management verlangt, welches konkurierende Zugriffe verwaltet. Mit Hilfe von LRU-Latches11 wird realisiert, dass die Liste für
abhängige Zugriffe konsistent bleibt. Es gibt die Möglichkeit mehrere LRU-Latches in einem
System zu erstellen, das hat den Vorteil, dass mehrere LRU-Sets12 angelegt werden können.
In Hinblick auf die Performance wird der Buffer oft noch weiter aufgeteilt in unterschiedliche
Bereiche für unteschiedliche Aufgaben:
• Keep-Pool
Beinhaltet Tabellenindizes ähnlich dem “cache” Parameter
• Recycle-Pool
Eignet sich für die Indexverwaltung großer Tabellen mit wenig Wiederverwendbarkeit
10
Ausnahmen sind Tabellen die mit dem Parameter “cache” erstellt wurden, von diesen wird angenommen, dass
wenige Einträge vorhanden sind und diese oft benötigt werden
11
LRU-Latches: kurzzeitige Sperren der Listenstruktur
12
LRU-Sets: eine Liste besteht aus: LRU-Aux-, LRU-Main-, LRUW-Aux-, LRUW-Main-Liste
Für die Erstellung von den verschiedenen Puffern muss explizit ein Parametereintrag im
“init.ora’-File erfolgen. Die Größe des gesamten Speichersplatzes wird mit “DB BLOCK BUFFERS” festgelegt und die Größe der anderen Buffer jeweils mit “DB POOL KEEP” bzw. mit
“DB POOL RECYCLE”. So ergibt sich die Default-Buffergröße aus der Differenz von der Gesamtgröße mit der Summer der beiden Teilgrößen.
Ohne explizite Angabe des Buffers wird jedes Objekt im Default-Buffer eingelagert, dennoch
sollten alle Arten des Puffers genutzt werden, weil so die Performance verbessert werden kann,
da sie mehrere Verwaltungsobjekte benutzt und auch die Speicherbereiche effizienter genutzt
werden können.
Oft kann das Datenbanksystem auf das Einsatzgebiet abgestimmt werden. Es eignet sich z.B.
der einfache LRU-Algorithmus für OLTP13 -Anwendungen, wo hingegen dieser nicht sehr performant bei DSS14 -Anwendungen arbeitet. Folglich gibt es mehrer Profile, in denen eine Datenbank arbeiten kann:
Art der Anfragen
- Einstellung der Datenbank
Ausgewählte Datensätze werden ein- - Beste Möglichkeit ist den Defaultzeln mittels Index ermittelt, wobei wie-
Buffer zu verwenden, da jeder Eintrag
derholte Anfragen oft vorkommen
am Anfang der LRU-Main-Liste eingefügt wird.
Auslesen kompletter Tabellen mit ge- - Der Default-Puffer bietet sich an, da
ringer Wiederverwendung der Einträge
bei Table-Scans die Werte am Ende der
LRU-Liste angehangen werden
Die Göße des Buffers wird durch folgende Initialisierungsparameter in der “init.ora” Datei
festgelegt:
DB_BLOCK_SIZE
DB_BLOCK_BUFFERS
Data-dictionary-views in den die eingestellten Werte eingesehen werden können:
13
14
OLTP : Online transaction processing
DSS : decision support system
V$BUFFER_POOL
V$BUFFER_POOL_STATISTICS
Änderung der Anzahl von LRU-Latches zur Verwaltung des Buffers:
DB_BLOCK_LRU_LATCHES
[DEFAULT] = ANZ(CPU ) / 2
Einteilung des Buffer-Pools
DB_BLOCK_BUFFERS = WERT
BUFFER_POOL_KEEP = ( " BUFFERS = WERT1, LRU_LATCHES = WERT2" )
BUTTER_POOL_RECYCLE = ( " BUFFERS = WERT3, LRU_LATCHES
3.2 Redo Log Puffer
Aus Performance-Gründen werden alle Dateneinträge nicht direkt auf die Festplatte geschrieben, aber auch die Log-Einträge werden in einem Puffer zwischengespeichert. In der Hinsicht,
dass der Buffer-Cache sich für die Zwischenspeicherung nicht eignet, da der Datendurchsatz
vermindert werden würde, gibt es einen Redo-Log-Puffer in dem alle Redo-Informationen zwischengespeichert werden.
Um weniger Informationen speichern zu müssen, werden so genannte “change vectors” bestimmt und weggeschrieben. Demnach müssen zwei Operationen permanent auf dem RedoPuffer arbeiten. Der LGWR-Prozess schreibt Einträge aus dem Redo-Log-Puffer in die RedoLog-Dateien und die Oracle Serverprozesse schreiben die Änderungsdaten in den Pufferspeicher.
Eine Sperrenverwaltung wird wieder mittels Latches gelöst:
• redo_allocate_latch
Sperrt Speicherbereiche, für die Allokierung
Dieses Latch kann nur einmal vergeben werden und wird weitergereicht
Dieser Vorgang dauert wenige Taktzyklen, so dass es zu keinem Engpass kommt
• redo_copy_latch
Sperrt einzelne Bereiche, auf denen geschrieben werden soll
Die Anzahl des Latchen ist gleich der CPUs im System
Es wird nur ein kleiner Bereich gesperrt, somit sind parallele Vergaben möglich
Der Ablauf eines Schreibprozesses läuft aus Sicht der Sperren wie folgt ab. Zunächst wird vom
Serverprozess ein “redo_copy-Latch” angefordert, im darauf folgendem Schritt wird zusätzlich
das “redo_allocate-Latch” angefordert. Sobald beide Sperren gesetzt sind, beginnt die Allokierung des gewählten Speicherbereiches. Letztendlich wird nach der Reservierung des Speichers
dem Severprozess zugeteiltem “redo_allocate-Latch” dieser Speicherbereich übergeben, so dass
das Allokierung-Latch freigegeben werden kann. Anschließend wird der “Change-Vector” auf
diesen Bereich geschrieben und das “Copy-Latch” wieder freigegeben.
Das Festschreiben auf einen Plattenspeicher übernimmt letztendlich der LGWR-Prozess, der
durch folgende Maßnahmen aktiviert werden kann:
• eine Transaktion wird mit einem “Commit” beendet
• der Puffer ist mehr als
1
4
voll
• der LGWR-Prozess war länger als 3s inaktiv
• der DBWR-Prozess fordert Daten an, deren ”Chang-Vector“ noch nicht zurückgeschrieben wurden
Wenn ein Speicherbereich auf einem Festwertspeicher/Plattenspeicher geschrieben wurde, kann
dieser wieder im Redo-Log-Puffer benutzt werden
View, die eine Übersicht über die Latches gibt
v$latch
Festlegen der Größe des Redo-Log-Puffers in der init.ora-Datei, x gibt die Größe in Byte an.
LOG_BUFFER = x
4 Literaturliste
• http://www.sebastian-schneemann.de/userfiles/file/dbinstance.pdf
• ”Oracle“ 10g Von Lutz Fröhlich, Carsten Czarski, Klaus Maier; Pearson Education Verlag
• ”Oracle9i UNIX Administration Handbook“ by Oracle press, authored by Donald K. Burleson
• ”Oracle für den DBA“ von J. Ahrends, D. Lenz, P. Schwanke, G. Unbescheid ,Pearson
Education
• ”Oracle8 fà 14 r den DBA . Verwalten, optimieren, vernetzen “ von Herrmann, Lenz, Unbesch