Prozessarchitektur einer Oracle Instanz: Prozesse, Speicherstrukturen und Logging

Transkript

1 Prozessarchitektur einer Oracle Instanz: Prozesse, Speicherstrukturen und Logging Reichmann, Chrisian 1. Juli

2 Inhaltsverzeichnis 1 Einführung in die Thematik 3 2 Die Prozessarten Der Benutzerprozess Der Listenerprozess Die Hintergrundprozesse Der Archivierungsprozess ( ARCH ) Der Checkpointprozess ( CKPT ) Der Datenbank-Schreib-Prozess ( DBWR ) Der Redo-Log-Schreibprozess ( LGWR ) PMON und SMON Prozess Recoverer-Prozess ( RECO ) System global area ( SGA ) Der DB-Block Buffer Pool ( Data Buffer Cache ) Redo Log Puffer Literaturliste 21

3 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

4 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.

5 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

6 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 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.

7 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 DB- Cache 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 Instanzwiederherstellung 1 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

8 Checkpoint- - Auslöser Aktionen Level 1 - Redo-Log Switch Betrifft die gesamte Datenbank alle online 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- DBWR schreibt DB-Blöcke zurürck Managements 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 normal Betrifft einzelne Files 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 DB- Cache 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-

9 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-Prozess 3 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

10 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 LRU 4 -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-Liste 5 nach veränderten Daten und kopiert gefundene in die LRUW-Liste 6. 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 5 LRU-Liste: Speicherstruktur, in der die zuletzt angeforderten Daten stehen 6 LRUW-Liste: Speicherstruktur, in der die zuletzt veränderten angeforderten Daten stehen

11 der DBWR-Prozess vom LCK0-Prozess 7 ausgelöst, und schreibt die Daten vom DB- Buffer-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

12 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-Log- Gruppe 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 LGWR- Prozess 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-Log- Datei 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 LGWR- Prozess 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.

13 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 Tablespace- Abhä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.

14 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

15 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 LRU 8 - und die LRUW 9 -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 LRU: Last recently used 9 LRUW: Last recently used write

16 modifizierte alte Werte zurück in den DB-Dateien geschrieben werden. Dafür wird die LRU- Main-Liste von hinten durchlaufen, um zum einen die unveränderten Werte in die LRU-Aux- Liste 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 LRU- Main-Liste angefügt 10. Da auf Parallelität nicht verzichtet werden kann, wird eine Management verlangt, welches konkurierende Zugriffe verwaltet. Mit Hilfe von LRU-Latches 11 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-Sets 12 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

17 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 BUF- FERS 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 OLTP 13 -Anwendungen, wo hingegen dieser nicht sehr performant bei DSS 14 -Anwendungen arbeitet. Folglich gibt es mehrer Profile, in denen eine Datenbank arbeiten kann: Art der Anfragen Ausgewählte Datensätze werden einzeln mittels Index ermittelt, wobei wiederholte Anfragen oft vorkommen Auslesen kompletter Tabellen mit geringer Wiederverwendung der Einträge - Einstellung der Datenbank - Beste Möglichkeit ist den Default- Buffer zu verwenden, da jeder Eintrag am Anfang der LRU-Main-Liste eingefügt wird. - Der Default-Puffer bietet sich an, da 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 OLTP : Online transaction processing 14 DSS : decision support system

18 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

19 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 Redo- Puffer arbeiten. Der LGWR-Prozess schreibt Einträge aus dem Redo-Log-Puffer in die Redo- Log-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.

20 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 $ l a t c h Festlegen der Größe des Redo-Log-Puffers in der init.ora-datei, x gibt die Größe in Byte an. LOG_BUFFER = x

21 4 Literaturliste 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ã 1 4r den DBA. Verwalten, optimieren, vernetzen von Herrmann, Lenz, Unbesch