Prozessarchitektur einer Oracle Instanz: Prozesse
Werbung
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
