Physische Speicherstrukturen

Die physischen Datenbankstrukturen einer Oracle-Datenbank können auf Betriebssystemebene angezeigt werden.

Physische Speicherstrukturen - Einführung

Ein Merkmal eines RDBMS ist die Unabhängigkeit logischer Datenstrukturen wie Tabellen, Views und Indizes von physischen Speicherstrukturen wie Dateien.

Da physische und logische Strukturen voneinander getrennt sind, können Sie die physische Speicherung von Daten verwalten, ohne den Zugriff auf logische Strukturen zu beeinträchtigen. Beispiel: Wenn Sie eine Datenbankdatei umbenennen, werden die darin gespeicherten Tabellen nicht umbenannt.

Eine Oracle-Datenbank ist eine Gruppe von Dateien, in denen Oracle-Daten im persistenten Speicher gespeichert werden. Ab Oracle Database 21c ist eine mehrmandantenfähige Containerdatenbank (CDB) die einzige unterstützte Architektur. Eine CDB enthält mindestens eine PDB.

In diesem Abschnitt werden die Datenbankdateien beschrieben, die generiert werden, wenn Sie eine CREATE DATABASE-Anweisung zum Erstellen einer CDB absetzen:

Eine Datenbankinstanz ist eine Gruppe von Speicherstrukturen, die Datenbankdateien in einer CDB verwalten. Die folgende Grafik zeigt die Beziehung zwischen der Instanz und den von ihr verwalteten Dateien.

Abbildung 1: Datenbankinstanz- und Datenbankdateien

Beschreibung der Abbildung cncpt223.gif

Siehe:

Mechanismen zum Speichern von Datenbankdateien

Für die Zuordnung und Verwaltung der Speicherung dieser Dateien stehen mehrere Mechanismen zur Verfügung.

Zu den Mechanismen gehören:

Eine Datenbank kann eine Kombination der vorhergehenden Speichermechanismen verwenden. Beispiel: Eine Datenbank könnte die Server Parameter File in einem herkömmlichen Dateisystem speichern, Datenbankdateien in PMEM Filestore speichern und dann die Redo Log-Dateien in einem Cluster File System archivieren.

Siehe:

Oracle Managed Files und benutzerverwaltete Dateien

Oracle Managed Files ist eine Dateibenennungsstrategie, mit der Sie Vorgänge in Bezug auf Datenbankobjekte und nicht auf Dateinamen angeben können. Beispiel: Sie können einen Tablespace erstellen, ohne die Namen der zugehörigen Datendateien anzugeben.

Mit Oracle Managed Files müssen Administratoren die Betriebssystemdateien in einer Datenbank nicht mehr direkt verwalten. Für Oracle ASM sind Oracle Managed Files erforderlich.

Hinweis: Diese Funktion hat keine Auswirkungen auf die Erstellung oder Benennung von administrativen Dateien wie Trace-Dateien, Auditdateien und Alertlogs.

Mit benutzerverwalteten Dateien verwalten Sie direkt die Betriebssystemdateien in der Datenbank. Sie treffen die Entscheidungen in Bezug auf Dateistruktur und Benennung. Beispiel: Wenn Sie einen Tablespace erstellen, legen Sie den Namen und Pfad der Tablespace-Datendateien fest.

Über Initialisierungsparameter geben Sie das Dateisystemverzeichnis für einen bestimmten Dateityp an. Mit dem Feature "Oracle Managed Files" wird sichergestellt, dass die Datenbank eine eindeutige Datei erstellt und löscht, wenn sie nicht mehr benötigt wird. Die Datenbank verwendet intern Standarddateisystemschnittstellen, um Dateien für Datendateien und temporäre Dateien, Kontrolldateien und Recovery-bezogene Dateien zu erstellen und zu löschen, die im Fast Recovery-Bereich gespeichert sind.

In Oracle Managed Files werden vorhandene Funktionen nicht eliminiert. Sie können neue Dateien erstellen, während Sie alte Dateien manuell verwalten. Daher kann eine Datenbank eine Mischung aus Oracle Managed Files und benutzerverwalteten Dateien enthalten.

Siehe:

Oracle Automatic Storage Management (Oracle ASM)

Oracle ASM ist eine leistungsstarke Speicherlösung mit einfacher Verwaltung für Oracle AI Database-Dateien. Oracle ASM ist ein Volume Manager und stellt ein Dateisystem bereit, das ausschließlich für die Verwendung durch die Datenbank entwickelt wurde.

Oracle ASM bietet mehrere Vorteile gegenüber herkömmlichen Dateisystemen und Storage Managern, darunter:

Um Oracle ASM zu verwenden, weisen Sie partitionierte Datenträger für Oracle AI Database mit Voreinstellungen für Striping und Mirroring zu. Oracle ASM verwaltet den Festplattenspeicher und verteilt die I/O-Last auf alle verfügbaren Ressourcen, um die Performance zu optimieren, ohne dass eine manuelle I/O-Optimierung erforderlich ist. Beispiel: Sie können die Größe der Festplatte für die Datenbank erhöhen oder Teile der Datenbank auf neue Geräte verschieben, ohne die Datenbank herunterfahren zu müssen.

Oracle ASM-Speicherkomponenten

Oracle AI Database kann eine Datendatei als Oracle ASM-Datei in einer Oracle ASM-Datenträgergruppe speichern. Innerhalb einer Plattengruppe stellt Oracle ASM eine Dateisystemschnittstelle für Datenbankdateien bereit.

Die folgende Abbildung zeigt die Beziehungen zwischen Speicherkomponenten in einer Datenbank, die Oracle ASM verwendet. Das Diagramm zeigt die Beziehung zwischen einer Oracle ASM-Datei und einer Datendatei, obwohl Oracle ASM andere Dateitypen speichern kann. Die Fußnotation der Krähe stellt eine Eins-zu-Viele-Beziehung dar.

Abbildung 2: Oracle ASM-Komponenten

Beschreibung der Abbildung cncpt267.gif

In Abbildung 14-2 werden die folgenden Oracle ASM-Konzepte dargestellt:

Siehe auch: Oracle Automatic Storage Management Administrator's Guide, um mehr über Oracle ASM zu erfahren

Oracle ASM-Instanzen

Eine Oracle ASM-Instanz ist eine spezielle Oracle-Instanz, die Oracle ASM-Datenträger verwaltet.

Sowohl die Oracle ASM- als auch die Datenbankinstanzen benötigen gemeinsamen Zugriff auf die Datenträger in einer Oracle ASM-Datenträgergruppe. Oracle ASM-Instanzen verwalten die Metadaten der Plattengruppe und stellen den Datenbankinstanzen Informationen zum Dateilayout bereit. Datenbankinstanzen leiten I/O an Oracle ASM-Datenträger weiter, ohne eine Oracle ASM-Instanz zu durchlaufen.

Eine Oracle ASM-Instanz basiert auf derselben Technologie wie eine Datenbankinstanz. Beispiel: Eine Oracle ASM-Instanz verfügt über eine System Global Area (SGA) und Hintergrundprozesse, die denen einer Datenbankinstanz ähnlich sind. Eine Oracle ASM-Instanz kann jedoch keine Datenbank mounten und führt weniger Aufgaben aus als eine Datenbankinstanz. In Abbildung 14-3 ist eine Einzelknotenkonfiguration mit einer Oracle ASM-Instanz und zwei Datenbankinstanzen dargestellt, die jeweils mit einer anderen Einzelinstanzdatenbank verknüpft sind. Die Oracle ASM-Instanz verwaltet die Metadaten und stellt die Speicherplatzzuweisung für die Oracle ASM-Dateien bereit, in denen die Daten für die beiden Datenbanken gespeichert sind. Eine Oracle ASM-Datenträgergruppe verfügt über vier Oracle ASM-Datenträger, die andere über zwei Datenträger. Beide Datenbankinstanzen können auf die Datenträgergruppen zugreifen.

Abbildung 3: Oracle ASM-Instanz und -Datenbankinstanzen

Beschreibung der Abbildung cncpt266.gif

Siehe auch: Oracle Automatic Storage Management Administrator's Guide, um mehr über Oracle ASM zu erfahren

Oracle Persistent Memory Filestore (PMEM-Filestore)

PMEM ist Byte-adressierbarer persistenter Speicher. In Oracle Persistent Memory Filestore (PMEM Filestore) können Datendateien, Online Redo Log-Dateien und Kontrolldateien gespeichert werden.

Abfragen können Byte direkt aus PMEM lesen, ohne zuerst Blöcke in den Datenbankpuffercache zu migrieren. Dieser leistungsstarke Mechanismus vermeidet Datenredundanz und unnötiges I/O. Hinweis: Ein PMEM-Dateispeicher kann keine Tracedateien, Auditdateien oder Serverparameterdateien speichern. Die unterstützten Dateitypen für PMEM ähneln den Typen für Oracle ASM.

Direkt zugeordneter Puffercache

In der herkömmlichen Speicherpyramide sitzt PMEM zwischen DRAM, das nicht persistent ist, und Flash, das persistent ist (nicht flüchtig).

Abbildung 4: Speicherpyramide

Beschreibung der Abbildung pmem.png

Der Datenbankpuffercache befindet sich in DRAM. Oracle-Prozesse haben direkten byteadressierbaren Zugriff auf Blöcke in einem PMEM-Dateispeicher, die dem Datenbankpuffercache zugeordnet sind. Der Zuordnungsmechanismus wird automatisch aufgerufen, wenn Sie eine Datendatei in einem PMEM-Dateispeicher speichern.

Oracle AI Database verwendet einen internen Algorithmus, um zu entscheiden, ob Datenblöcke aus dem PMEM-Dateispeicher in DRAM migriert werden. Typische Gründe für die Migration sind DML-Änderungen, Lesekonsistenz und schnellerer Zugriff für Hot Data Blöcke.

Siehe auch: "DRAM- und PMEM-Puffer"

Dateisystemschnittstelle für PMEM Filestore

PMEM Filestore implementiert ein Protokoll namens Filesystem in Userspace (FUSE).

Mit FUSE können nicht privilegierte Betriebssystembenutzer, wie der Eigentümer der Oracle AI Database-Software, Dateisysteme sowie die darin enthaltenen Verzeichnisse und Dateien erstellen und verwalten. Beispiel: Sie können die Befehle cp, rm und ls verwenden.

Ein typisches Dateisystem verwendet Raw Storage als Backing-Speicher, während PMEM Filestore Speicher aus einer nativen Betriebssystemdatei in einem PMEM DAX-Dateisystem bezieht. Diese Datei wird als Backing-Datei bezeichnet und ist als Datei im Betriebssystem sichtbar. PMEM Filestore unterteilt den Speicher innerhalb der Sicherungsdatei und stellt ihn als lokales Dateisystem dar.

Siehe:

Benutzeroberfläche für PMEM Filestore

Um einen PMEM-Filestore zu erstellen, verwenden Sie den Befehl CREATE PMEM FILESTORE.

Der PMEM-Filestore wird automatisch gemountet, nachdem er erstellt wurde. Der PMEM-Dateispeicher wird unter dem angegebenen Einhängepunkt angezeigt, als wäre er ein natives Dateisystem.

Der Initialisierungsparameter PMEM_FILESTORE gibt einen PMEM-Dateispeicher an, den die Datenbankinstanz automatisch mountet, wenn sie gestartet wird. Der Parameter wird auf ein geordnetes Zeichenfolgenpaar gesetzt. Die erste Zeichenfolge in der Parameterwerteliste ist das Verzeichnis, in dem PMEM Filestore gemountet ist. Die zweite Zeichenfolge ist die Sicherungsdatei.

V$PMEM_FILESTORE zeigt Metadaten zu einem PMEM-Filestore. Beispiel: Sie können den Verzeichnispfad des Mount Points, den Dateipfad für die Sicherungsdatei und die Filestore-Größe anzeigen.

Siehe auch: Im Oracle AI Database Administrator's Guide erfahren Sie, wie Sie einen PMEM-Dateispeicher erstellen und verwalten.

Übersicht über Datendateien

Auf Betriebssystemebene speichert Oracle AI Database Daten in Strukturen, die als Datendateien bezeichnet werden. Jede Oracle-Datenbank, ob CDB oder PDB, muss mindestens eine Datendatei aufweisen.

Verwendung von Datendateien

Oracle AI Database speichert Tablespace-Daten physisch in Datendateien.

Jedes nicht partitionierte Schemaobjekt und jede Partition eines Objekts wird in einem eigenen Segment gespeichert, das nur zu einem Tablespace gehört. Beispiel: Die Daten für eine nicht partitionierte Tabelle werden in einem einzelnen Segment gespeichert, das wiederum in einem Tablespace gespeichert wird. Tablespaces und Datendateien sind eng miteinander verknüpft, weisen jedoch wichtige Unterschiede auf:

Die folgende Abbildung zeigt die Beziehung zwischen Tablespaces, Datendateien und Segmenten.

Abbildung 5: Datendateien und Tablespaces

Beschreibung der Abbildung cncpt037.gif

Siehe:

Permanente und temporäre Datendateien

Ein permanenter Tablespace enthält persistente Schemaobjekte. Objekte in Permanent Tablespaces werden in Datendateien gespeichert.

Ein temporärer Tablespace enthält Schemaobjekte nur für die Dauer einer Session. Lokal verwaltete Temporary Tablespaces verfügen über temporäre Dateien (Temp-Dateien), bei denen es sich um spezielle Dateien handelt, die zum Speichern von Daten in Hash-, Sortier- und anderen Vorgängen entwickelt wurden. Temp-Dateien speichern auch Ergebnissatzdaten, wenn nicht genügend Speicherplatz im Speicher vorhanden ist.

Temp-Dateien ähneln permanenten Datendateien, mit folgenden Ausnahmen:

Siehe:

Online- und Offlinedatendateien

Jede Datendatei ist entweder online (verfügbar) oder offline (nicht verfügbar).

Sie können die Verfügbarkeit einzelner Datendateien oder temporärer Dateien ändern, indem Sie sie offline setzen oder online stellen. Die Datenbank kann erst auf Offlinedatendateien zugreifen, wenn sie online gesetzt wurden.

Sie können Datendateien aus vielen Gründen offline setzen, einschließlich Offlinebackups oder Blockbeschädigungen. Die Datenbank setzt eine Datendatei automatisch offline, wenn sie nicht in die Datenbank geschrieben werden kann.

Wie eine Datendatei ist auch ein Tablespace offline oder online. Wenn Sie eine Datendatei in einem Online Tablespace offline setzen, bleibt der Tablespace selbst online. Sie können alle Datendateien eines Tablespace vorübergehend nicht verfügbar machen, indem Sie den Tablespace selbst offline setzen.

Ab Oracle Database 12c können Sie mit der Anweisung ALTER DATABASE MOVE DATAFILE eine Onlinedatendatei von einer physischen Datei in eine andere verschieben, während die Datenbank geöffnet ist, und auf die Datei zugreifen. Mit dieser Technik können Sie die folgenden Ziele erreichen:

Siehe:

Datendateistruktur

Oracle AI Database erstellt eine Datendatei für einen Tablespace, indem der angegebene Speicherplatz plus der Overhead für den Datendatei-Header zugewiesen wird. Das Betriebssystem, unter dem Oracle AI Database ausgeführt wird, ist dafür verantwortlich, alte Informationen und Autorisierungen aus einer Datei zu löschen, bevor sie der Datenbank zugewiesen werden.

Der Datendatei-Header enthält Metadaten zur Datendatei, wie Größe und Checkpoint-SCN. Jeder Header enthält eine absolute Dateinummer, mit der die Datendatei in der Datenbank eindeutig identifiziert wird, und eine relative Dateinummer, mit der eine Datendatei in einem Tablespace eindeutig identifiziert wird.

Wenn Oracle AI Database zum ersten Mal eine Datendatei erstellt, wird der zugewiesene Festplattenspeicher formatiert, enthält jedoch keine Benutzerdaten. Die Datenbank reserviert jedoch den Speicherplatz, um die Daten für zukünftige Segmente des zugehörigen Tablespace zu speichern. Wenn die Daten in einem Tablespace wachsen, verwendet Oracle AI Database den freien Speicherplatz in den Datendateien, um Extents für das Segment zuzuweisen.

Die folgende Abbildung veranschaulicht die verschiedenen Arten von Speicherplatz in einer Datendatei. Extents werden entweder verwendet, was bedeutet, dass sie Segmentdaten enthalten, oder frei, was bedeutet, dass sie wiederverwendet werden können. Mit der Zeit können durch das Aktualisieren und Löschen von Objekten in einem Tablespace leere Speicherbereiche entstehen, die einzeln nicht groß genug sind, damit sie für neue Daten wiederzuverwenden sind. Dieser Typ von leerem Speicherplatz wird als fragmentierter freier Speicherplatz bezeichnet.

Abbildung 6: Speicherplatz in einer Datendatei

Beschreibung der Abbildung cncpt273.gif

Siehe auch: Oracle AI Database Administrator's Guide enthält Informationen zum Anzeigen von Datendateiinformationen.

Überblick über Kontrolldateien

Die Kontrolldatei der Datenbank ist eine kleine Binärdatei, die nur einer CDB zugeordnet ist.

Jede CDB verfügt über eine eindeutige Kontrolldatei, obwohl mehrere identische Kopien zulässig sind. PDBs verfügen nicht über separate Kontrolldateien.

Verwendung von Kontrolldateien

Oracle AI Database verwendet die Kontrolldatei, um Datenbankdateien zu suchen und den Status der Datenbank allgemein zu verwalten.

Eine Kontrolldatei enthält Informationen wie die folgenden:

Die Kontrolldatei dient folgenden Zwecken:

Oracle AI Database liest und schreibt während der Datenbanknutzung kontinuierlich in die Kontrolldatei und muss zum Schreiben verfügbar sein, wenn die Datenbank geöffnet ist. Beispiel: Beim Recovery einer Datenbank werden die Namen aller in der Datenbank enthaltenen Datendateien aus der Kontrolldatei gelesen. Andere Vorgänge, wie das Hinzufügen einer Datendatei, aktualisieren die in der Kontrolldatei gespeicherten Informationen.

Siehe:

Mehrere Kontrolldateien

Mit Oracle AI Database können mehrere identische Kontrolldateien gleichzeitig geöffnet und in dieselbe Datenbank geschrieben werden. Durch das Multiplexen einer Kontrolldatei auf verschiedenen Platten kann die Datenbank Redundanz erreichen und so einen Single Point of Failure vermeiden. Hinweis: Oracle empfiehlt, mehrere Kopien von Kontrolldateien auf einer anderen Festplatte zu verwalten.

Wenn eine Kontrolldatei nicht mehr verwendet werden kann, schlägt die Datenbankinstanz fehl, wenn sie versucht, auf die beschädigte Kontrolldatei zuzugreifen. Wenn andere Kopien der aktuellen Kontrolldatei vorhanden sind, können Sie die Datenbank erneut mounten und ohne Medien-Recovery öffnen. Wenn jedoch alle Kontrolldateien einer Datenbank verloren gehen, verläuft die Datenbankinstanz nicht erfolgreich, und ein Media Recovery ist erforderlich. Das Media Recovery ist nicht einfach, wenn ein älteres Backup einer Kontrolldatei verwendet werden muss, da keine aktuelle Kopie verfügbar ist.

Siehe:

Kontrolldateistruktur

Informationen zur Datenbank werden in verschiedenen Abschnitten der Kontrolldatei gespeichert. Jeder Abschnitt enthält eine Gruppe von Datensätzen zu einem Aspekt der Datenbank.

Beispiel: Ein Abschnitt in der Kontrolldatei verfolgt Datendateien und enthält eine Gruppe von Datensätzen, eine für jede Datendatei. Jeder Abschnitt ist in mehreren logischen Kontrolldateiblöcken gespeichert. Datensätze können Blöcke innerhalb eines Abschnitts umfassen.

Die Kontrolldatei enthält die folgenden Datensatztypen:

Sie können die dynamischen Performance-Views (auch als V$-Views bezeichnet) abfragen, um die in der Kontrolldatei gespeicherten Informationen anzuzeigen. Beispiel: Sie können V$DATABASE abfragen, um den Datenbanknamen und die DBID abzurufen. Die Informationen in der Kontrolldatei können jedoch nur von der Datenbank geändert werden.

Das Lesen und Schreiben der Kontrolldateiblöcke unterscheidet sich vom Lesen und Schreiben von Datenblöcken. Bei der Kontrolldatei liest und schreibt Oracle AI Database direkt von der Platte in die Programm-Global Area (PGA). Jeder Prozess weist eine bestimmte Menge seines PGA-Speichers für Kontrolldateiblöcke zu.

Siehe:

Überblick über das Online Redo Log

Die wichtigste Struktur für das Recovery ist das Online-Redo-Log, das aus zwei oder mehr vorab zugewiesenen Dateien besteht, in denen Änderungen an der Datenbank gespeichert werden, sobald sie auftreten. Die Online Redo Log-Datensätze ändern sich in den Datendateien.

Online-Redo-Log verwenden

Die Datenbank verwaltet Online Redo Log-Dateien zum Schutz vor Datenverlust. Insbesondere ermöglichen die Online Redo Log-Dateien nach einem Instanzfehler Oracle AI Database, festgeschriebene Daten wiederherzustellen, die noch nicht in die Datendateien geschrieben wurden.

Serverprozesse schreiben jede Transaktion synchron in den Redo-Logpuffer, den der LGWR-Prozess dann in das Online-Redo-Log schreibt. Der Inhalt des Online-Redo-Logs umfasst nicht festgeschriebene Transaktionen sowie Anweisungen zur Schema- und Objektverwaltung.

Wenn die Datenbank Änderungen an den Undo-Segmenten vornimmt, schreibt die Datenbank diese Änderungen auch in die Online Redo Logs. Folglich enthält das Online Redo Log immer die Undo-Daten für permanente Objekte. Sie können die Datenbank so konfigurieren, dass alle Undo-Daten für temporäre Objekte in einem temporären Undo-Segment gespeichert werden. Dadurch wird Speicherplatz gespart und die Performance verbessert, oder die Datenbank kann sowohl permanente als auch temporäre Undo-Daten im Online-Redo-Log speichern.

Oracle AI Database verwendet das Online-Redo-Log nur für das Recovery. Administratoren können Online Redo Log-Dateien jedoch über eine SQL-Schnittstelle im Oracle LogMiner-Utility abfragen. Redo Log-Dateien sind eine nützliche Quelle historischer Informationen über die Datenbankaktivität.

Siehe:

Schreiben von Oracle AI Database in das Online-Redo-Log

Das Online-Redo-Log für eine Datenbankinstanz wird als Redo-Thread bezeichnet.

In Einzelinstanzkonfigurationen greift nur eine Instanz auf eine Datenbank zu, sodass nur ein Redo Thread vorhanden ist. In einer Oracle Real Application Clusters-(Oracle RAC-)Konfiguration greifen jedoch mehrere Instanzen gleichzeitig auf eine Datenbank zu, wobei jede Instanz einen eigenen Redo-Thread aufweist. Ein separater Redo Thread für jede Instance vermeidet Zugriffskonflikte bei einer einzelnen Gruppe von Online Redo Log-Dateien.

Ein Online Redo Log besteht aus zwei oder mehr Online Redo Log-Dateien. Oracle AI Database erfordert mindestens zwei Dateien, um sicherzustellen, dass eine Datei immer zum Schreiben verfügbar ist, falls die andere Datei gerade gelöscht oder archiviert wird.

Siehe auch: Oracle Real Application Clusters Administration and Deployment Guide enthält Informationen zu Online-Redo-Loggruppen in Oracle RAC

Online Redo Log-Switches

Oracle AI Database verwendet jeweils nur eine Online-Redo-Logdatei, um Datensätze zu speichern, die aus dem Redo-Logpuffer geschrieben wurden.

Die Online Redo Log-Datei, in die der Log Writer-Prozess (LGWR) aktiv schreibt, wird als aktuelle Online Redo Log-Datei bezeichnet.

Ein Log-Switch wird ausgeführt, wenn die Datenbank das Schreiben in eine Online-Redo-Logdatei stoppt und mit dem Schreiben in eine andere beginnt. Normalerweise erfolgt ein Switch, wenn die aktuelle Online Redo Log-Datei voll ist und das Schreiben fortgesetzt werden muss. Sie können jedoch Log Switches so konfigurieren, dass sie in regelmäßigen Abständen stattfinden, unabhängig davon, ob die aktuelle Online Redo Log-Datei gefüllt ist, und Log Switches manuell erzwingen.

Log Writer schreibt zyklisch in Online Redo Log-Dateien. Wenn Log Writer die letzte verfügbare Online Redo Log-Datei ausfüllt, schreibt der Prozess in die erste Log-Datei und startet den Zyklus neu. In Abbildung 14-7 wird das zirkuläre Schreiben des Redo-Logs dargestellt.

Abbildung 7: Wiederverwendung von Online Redo Log-Dateien

Beschreibung der Abbildung admin054.gif

Die Zahlen in Abbildung 14-7 zeigen die Reihenfolge, in der LGWR in jede Online Redo Log-Datei schreibt. Die Datenbank weist jeder Datei eine neue Logsequenznummer zu, wenn Log Switches und Log Writer mit dem Schreiben in die Datei beginnen. Wenn die Datenbank eine Online Redo Log-Datei wiederverwendet, erhält diese Datei die nächste verfügbare Log-Folgenummer.

Gefüllte Online Redo Log-Dateien können je nach Archivierungsmodus wiederverwendet werden:

In einigen Fällen kann Log Writer daran gehindert werden, eine vorhandene Online Redo Log-Datei wiederzuverwenden. Für das Instanz-Recovery ist eine aktive Online-Redo-Logdatei erforderlich, bei der keine inaktive Online-Redo-Logdatei für das Instanz-Recovery erforderlich ist. Außerdem wird möglicherweise gerade eine Online Redo Log-Datei gelöscht.

Siehe:

Mehrere Kopien von Online Redo Log-Dateien

Oracle AI Database kann automatisch zwei oder mehr identische Kopien des Online-Redo-Logs an separaten Speicherorten verwalten.

Eine Online-Redo-Loggruppe besteht aus einer Online-Redo-Logdatei und ihren redundanten Kopien. Jede identische Kopie ist Mitglied der Online Redo Log-Gruppe. Die einzelnen Gruppen sind durch Zahlen definiert, zum Beispiel Gruppe 1, Gruppe 2 usw.

Die Verwaltung mehrerer Member einer Online Redo Log-Gruppe schützt vor dem Verlust des Redo Log. Idealerweise sollten sich die Speicherorte der Member auf separaten Platten befinden, sodass der Ausfall einer Platte nicht zum Verlust des gesamten Online Redo Log führt.

In Abbildung 14-8 sind A_LOG1 und B_LOG1 identische Mitglieder von Gruppe 1, während A_LOG2 und B_LOG2 identische Mitglieder von Gruppe 2 sind. Jedes Mitglied in einer Gruppe muss dieselbe Größe haben. LGWR schreibt gleichzeitig in Gruppe 1 (die Mitglieder A_LOG1 und B_LOG1), schreibt dann gleichzeitig in Gruppe 2 (die Mitglieder A_LOG2 und B_LOG2), schreibt dann in Gruppe 1 usw. LGWR schreibt niemals gleichzeitig an Mitglieder verschiedener Gruppen.

Abbildung 8: Mehrere Kopien von Online Redo Log-Dateien

Beschreibung der Abbildung cncpt270.gif

Hinweis: Oracle empfiehlt, dass Sie das Online-Redo-Log spiegeln. Der Verlust von Logdateien kann katastrophal sein, wenn eine Wiederherstellung erforderlich ist. Beim Multiplexen des Online-Redo-Logs muss die Datenbank die I/O-Anzahl erhöhen, die sie durchführt. Je nach System kann sich diese zusätzliche E/A auf die Gesamtperformance der Datenbank auswirken.

Siehe:

Archivierte Redo-Logdateien

Eine archivierte Redo-Logdatei ist eine Kopie eines gefüllten Mitglieds einer Online-Redo-Loggruppe.

Eine archivierte Redo Log-Datei wird nicht als Teil der Datenbank betrachtet. Es handelt sich vielmehr um eine Offlinekopie einer von der Datenbank erstellten Online Redo Log-Datei, die in ein benutzerdefiniertes Verzeichnis geschrieben wird.

Archivierte Redo Log-Dateien sind ein wesentlicher Bestandteil einer Backup- und Recovery-Strategie. Sie können archivierte Redo-Logdateien für folgende Zwecke verwenden:

Der Vorgang zum Generieren einer archivierten Redo-Logdatei wird als Archivierung bezeichnet. Diese Operation ist entweder automatisch oder manuell. Dies ist nur möglich, wenn sich die Datenbank im ARCHIVELOG-Modus befindet.

Eine archivierte Redo Log-Datei enthält die Redo-Einträge und die Log-Folgenummer des identischen Members der Online Redo Log-Gruppe. Unter "Mehrere Kopien von Online-Redo-Logdateien" sind die Dateien A_LOG1 und B_LOG1 identische Mitglieder von Gruppe 1. Wenn sich die Datenbank im ARCHIVELOG-Modus befindet und die automatische Archivierung aktiviert ist, archiviert der Archiver-Prozess (ARCn) eine dieser Dateien. Wenn A_LOG1 beschädigt ist, kann der Prozess B_LOG1 archivieren. Das archivierte Redo Log enthält eine Kopie jeder Redo Log-Gruppe, die seit der Aktivierung der Archivierung vorhanden war.

Siehe:

Struktur des Online-Redo-logs

Online-Redo-Logdateien enthalten Redo-Datensätze.

Ein Redo-Datensatz besteht aus einer Gruppe von Änderungsvektoren, von denen jede eine Änderung an einem Datenblock beschreibt. Beispiel: Bei einer Gehaltsaktualisierung in der Tabelle employees wird ein Redo-Datensatz generiert, der Änderungen am Datensegment-Block für die Tabelle, den Undo-Segmentdatenblock und die Transaktionstabelle der Undo-Segmente beschreibt.

Die Redo-Datensätze enthalten alle relevanten Metadaten für die Änderung, einschließlich der folgenden:

Siehe auch: "Überblick über Datenblöcke"