Verständnis von Redo-Log-Gruppe vs. Datei vs. Mitglied

In diesem Oracle-Tutorial erklären wir auf einfache Weise das Verständnis von Redo-Log-Gruppe vs. Datei vs. Mitglied.

Heute lernen wir das Konzept des Redo-Log-Puffers in Oracle kennen. In dem wir erfahren, was Redo Log Buffer ist, wie er funktioniert und welche Rolle er in der Oracle-Architektur spielt.

Wenn Sie die Oracle-Architektur verstehen möchten, ist es wirklich wichtig, die Funktionsweise des Redo-Log-Puffers zu verstehen. Der folgende Artikel hilft Ihnen auch bei der Bewältigung von Interviewfragen.

Verständnis von Redo-Log-Gruppe vs. Datei vs. Mitglied

Was ist ein Redo-Log-Puffer?

Es ist eine winzige Speicherzuweisung, die standardmäßig etwa 14 MB beträgt. Es ist ein Umlaufpuffer. Sobald es voll ist, beginnt es wieder von oben zu schreiben, es überschreibt die Daten, sobald es voll ist.

Was ist der Redo-Eintrag und der Änderungsvektor?

Die Oracle-Datenbankinstanz zeichnet alle DML/DDL-Transaktionen in Form von Redo-Einträgen in den Redo-Log-Puffer von SGA auf. Die einzelne Anweisung in einer Transaktion führt zu einem oder mehreren Redo-Einträgen. Diese alle Redo-Einträge werden gemeinsam als Änderungsvektor oder Redo-Vektor bezeichnet.

Jeder Redo-Eintrag besteht aus Redo-Anweisung und Undo-Anweisung, zum Beispiel:

TABELLE EMP

sql>delete empno from emp where deptno=10;

Im obigen Beispiel enthält die emp-Tabelle 3 Datensätze für deptno=10. Oracle erstellt also 3 Redo-Einträge für die obige Anweisung und diese Einträge werden im Redo-Log-Puffer aufgezeichnet. Diese 3 Redo-Einträge werden gemeinsam als Änderungsvektor oder Redo-Vektor bezeichnet.

Der Änderungsvektor ist nichts anderes als eine Anzahl betroffener Zeilen durch eine einzelne Operation. Der Redo-Log-Puffer erfasst die Transaktionen des Benutzers und erfasst auch den annullierenden Effekt (Rückgängig-Anweisung) für diese Transaktion.

Funktionsweise des LGWR-Prozesses

Da die Größe des Redo-Log-Puffers klein ist und nicht dynamisch wachsen kann, müssen diese aufgezeichneten Redo-Einträge periodisch in eine Online-Redo-Log-Datei auf die Platte geschrieben werden. Dies wird oft als Leeren des Redo-Log-Puffers bezeichnet, und die Aufgabe, diese Redo-Einträge auf die Festplatte zu schreiben, wird vom LGWR-Prozess erledigt.

Wann schreibt LGWR Redo-Einträge auf die Festplatte?

LGWR ist ziemlich aggressiv beim Schreiben dieser Einträge auf die Festplatte. Nachfolgend sind die Ereignisse aufgeführt, bei denen LGWR Redo-Einträge auf die Festplatte schreibt.

• Wenn die Puffergröße 1/3 voll ist
• Wenn 1 MB Änderungsvektoren im Redo-Log-Puffer verfügbar sind, die zum Schreiben ausstehen
• Alle 3 Sekunden
• Wann immer ein Kontrollpunkt auftritt
• Wenn ein Benutzer seine/ihre Transaktionen festschreibt

Ein Parameter zum Festlegen der Größe des Redo-Log-Puffers

log_buffer=x Bytes
Struktur des Redo-Log-Puffers

Die Redo-Architektur besteht aus 3 Dingen

1. Thread wiederholen (logisch)
2. Redolog-Gruppen (logisch)
3. Redolog-Member-Dateien (physisch)

1. Was ist der Redo-Log-Thread?

• Während der Erstellung wird eine Steuerdatei durch den Parameter „MAXINSTANCES“ angegeben.
• Ein Redo-Thread besteht aus Redo-Gruppen. Der Redo-Thread muss aktiviert sein, um funktionsfähig zu sein.
• In der RAC-Umgebung können Sie mit dem init.ora-Parameter „thread“ einen Redo-Thread an die jeweilige Instanz binden.

In einer Nicht-RAC-Datenbank würde es meistens einen Thread geben (Thread =1)

2. Die Redo-Log-Gruppe und ihren Status verstehen?

- Beim Erstellen einer Steuerdatei wird sie als Parameter „MAXLOGFILES“ angegeben.
-Eine Redo-Log-Gruppe ist eine Sammlung identischer Redo-Log-Mitgliedsdateien.
-Für eine bessere Fehlertoleranz ist es jedoch üblich, zwei Redo-Log-Member-Dateien in jeder Redo-Log-Gruppe zu führen.
-Wenn man verloren geht, hat es keine Auswirkungen. Die Redo-Log-Member-Dateien sind identisch (Spiegelkopien)
LGWR schreibt parallel an alle Mitglieder einer bestimmten Redo-Log-Gruppe
Zu jedem Zeitpunkt schreibt der LGWR-Prozess nur in eine Redo-Log-Gruppe. Die Redo-Log-Gruppe ist fest, was bedeutet, dass die Redo-Log-Mitgliedsdateien nicht dynamisch wachsen können.
Die Redo-Log-Gruppe, in die der LGWR-Prozess gerade schreibt, wird mit dem Status „aktuell“ angezeigt.
Sobald die Redo-Log-Gruppe voll ist, wechselt der LGWR-Prozess zur nächsten Redo-Log-Gruppe.
Die vorherige Gruppe zeigt den Status „AKTIV“ und nach einiger Zeit würde der Status „INAKTIV“ sein.
AKTUELL => AKTIV => INAKTIV => AKTUELL => AKTIV => INAKTIV …………………………………
AKTUELL Status bedeutet, dass Oracle gerade in diesen Puffer schreibt
AKTIV Checkpoint von Redo-Einträgen in diesem Puffer steht noch aus
INAKTIV Status bedeutet, dass das Redo-Log überprüft wurde und sofort überschrieben werden kann.
Sie können die Größe der einmal erstellten Redo-Log-Gruppe nicht ändern, aber Sie haben die Redo-Log-Gruppe immer gelöscht und mit unterschiedlichen Größen neu erstellt. Sie können die Redo-Log-Gruppe mit dem Status „AKTUELL“ oder „AKTIV“ nicht löschen.

Wie wechsle ich eine Redo-Log-Gruppe?

Normalerweise wechselt der LGWR automatisch zwischen den Redo-Log-Gruppen, aber Sie können mit dem Befehl manuell von einer Redo-Log-Gruppe zur anderen wechseln.

sql>alter system switch logfile ;

Jedes Mal, wenn LGWR eine neue Redo-Log-Gruppe aufnimmt, weist es dieser Redo-Log-Gruppe eine monoton steigende Nummer mit dem Namen „Log-Sequenznummer“ oder „Sequenznummer“ zu. Sie können die Metadaten der Redo-Log-Gruppen mit view abfragen:- v$log Redo-Log-Gruppen werden unter Verwendung der Blockgröße der physischen Festplatte geschrieben (Sektor von 512 Byte)

So fügen Sie eine neue Redo-Log-Gruppe hinzu

sql>alter database add logfile group 3 ('/path/to/member1.log', '/path/to/member2.log') size 100m reuse;

Hierin bedeutet Wiederverwendung, die Datei member1.log oder member2.log wiederzuverwenden, wenn sie bereits im selben Pfad existiert.

So löschen Sie eine Redo-Log-Gruppe

Sie können Redo-Log-Gruppen löschen, sofern der Status nicht CURRENT oder ACTIVE ist. Auch nach Anwendung dieses Befehls sollte die Anzahl der verfügbaren Redo-Log-Gruppen 2 oder mehr betragen.

sql>alter database drop logfile groups 3;

3. Redo Log-Mitgliedsdateien (physisch)

Beim Erstellen einer Steuerdatei wird sie durch den Parameter „MAXLOGMEMBERS“ angegeben. Die Redo-Log-Member-Dateien sind physisch auf Betriebssystemebene verfügbar. Die Größe der Datei wird zum Zeitpunkt der Erstellung der Redo-Log-Gruppe festgelegt.

Die Datei kann nicht dynamisch wachsen. LGWR schreibt parallel an alle Mitglieder einer bestimmten Redo-Log-Gruppe.
Mitgliedsdateien in der Redo-Log-Gruppe sind identisch. Sie können die Statusinformationen aus der Ansicht v$logfile

Wie füge ich ein neues Mitglied zu einer bestehenden Gruppe hinzu?

sql>alter database add logfile member '/path/to/new/member1.log' to group 3;

Sie können ein Mitglied aus der Gruppe entfernen, vorausgesetzt, es bleibt ein Mitglied übrig und der Gruppenstatus ist nicht aktuell

sql>alter database drop logfile member '/path/to/member_to_be_deleted.log';

Zum Abfragen der Redo-Log-Umschaltdetails
Sie können den v$log-Verlauf abfragen

sql>select count(*), trunc(first_time) from v$log_history;

Gruppe, um die Redo-Einträge zu überschreiben

Warum sehe ich „Checkpoint not complete“ in alert.log

Wenn LGWR an einer Redo-Log-Gruppe ankommt, um Redo-Einträge zu überschreiben, und wenn zu diesem Zeitpunkt ein Prüfpunkt dieser Gruppe ansteht, sehen Sie im Warnprotokoll die Meldung „Prüfpunkt nicht abgeschlossen“. Aus diesem Grund kann LGWR die Redo-Log-Gruppe nicht sofort überschreiben.

Daher löst Oracle den „Checkpoint“ aus, der fehlerhafte Puffer, die durch Redo-Einträge verursacht wurden, auf die Festplatte löscht. Erst danach kann LGWR den Redo-Puffer überschreiben. Das bedeutet, dass LGWR einige Zeit warten muss, was nicht gut ist. Um dies zu umgehen, fügen Sie entweder weitere Redo-Log-Gruppen hinzu und/oder erhöhen Sie die Größe der Redo-Log-Gruppen.

Wir hoffen, dass unsere obigen Details Ihnen helfen werden, Ihr Verständnis des Redo-Log-Puffers zu klären.

Dies ist das Ende des Tutorials, Verständnis von Redo-Log-Gruppe vs. Datei vs. Mitglied.