OPS: Verteiltes Szenario (SAP-Bibliothek - Datenbankverwaltung (Oracle) mit SAPDBA)

OPS: Verteiltes Szenario

Jede ORACLE-Instanz hat ein eigenes lokales Archivierungsverzeichnis. Dieses Verzeichnis sollte nicht auf einer gemounteten Platte liegen.

BRARCHIVE wird lokal auf den Rechnern aller ORACLE-Instanzen gestartet.

In diesem Fall arbeitet BRARCHIVE ähnlich wie unter einer Konfiguration ohne Parallel Server Option. BRARCHIVE sichert jeweils die Offline-Redo-Log-Dateien der lokalen Instanz. BRARCHIVE kann diese anhand der Thread-Nummer ( init<DBSID>.ora -Parmeter thread ), die jeder lokalen Instanz zugeordnet ist, ermitteln.

Falls im lokalen Archivierungsverzeichnis Offline-Redo-Log-Dateien anderer Instanzen anfallen, archiviert BRARCHIVE diese ebenfalls.

Jede ORACLE-Instanz hat eine eigene durch BRARCHIVE gesteuerte Datenträger-Verwaltung. Auf jedem Sicherungsband sind die Offline-Redo-Log-Dateien gesichert, die in dem lokalen Archivierungsverzeichnis der entsprechenden Instanz gefunden wurden (in Ausnahmefällen kann es sich dabei um Offline-Redo-Log-Dateien verschiedener Instanzen handeln). Die Zuordnung der Offline-Redo-Log-Dateien zu den einzelnen Instanzen ist aus den Dateinamen ersichtlich. Die Namenskonventionen werden durch die init<DBSID>.ora -Parameter log_archive_dest und log_archive_format vorgegeben.

log_archive_dest = /oracle/C11/saparch/C11arch

log_archive_format = %t_%s.dbf

%t - Threadnummer (zur Identifizierung der Instanz)

%s - Log-Sequenznummer

Der ORACLE-Platzhalter @ (für ORACLE_SID) darf im Namen einer Offline-Redo-Log-Datei nicht erscheinen, also auch weder in log_archive_dest noch in log_archive_format .

Die Archivierung der Offline-Redo-Log-Dateien kann entweder auf lokalen Bandstationen (an dem jeweiligen Rechner der Instanz angeschlossen, backup_dev_type = tape ) oder auf Bandstationen, die an dem Rechner der DDB-Instanz angeschlossen sind ( backup_dev_type = pipe ), durchgeführt werden.

Vorteile

Verwendung des BRARCHIVE ist so ähnlich wie bei Einsatz des Dienstprogramms bei einer Nicht-OPS-Konfiguration.

Nachteile

Auf den Rechnern aller Instanzen muß freier Plattenplatz zur Verfügung gestellt werden, damit die lokale ORACLE-Sicherung der Offline-Redo-Log-Dateien ins Archivierungsverzeichnis erfolgen kann.

BRARCHIVE muß jeweils für alle ORACLE-Instanzen gestartet werden.

Für jede Instanz muß ein eigener BRARCHIVE-Datenträger-Pool verwaltet werden.

Dieses Szenario wird von SAP nicht empfohlen. Siehe Besonderheiten des BRARCHIVE.

Der Einsatz von BRARCHIVE in der Form des verteilten Szenarios kann dann sinnvoll sein, wenn auf jeder ORACLE-Instanz sehr viele Offline-Redo-Log-Dateien anfallen, die jeweils einen Datenträger (Band) zum großen Teil füllen würden.

Weitere Bemerkungen

Die Offline-Redo-Log-Dateien werden benötigt, wenn die Datenbank wiederhergestellt werden muß. Recovery-Maßnahmen sollten nur von einem erfahrenen Administrator durchgeführt werden, der das OPS-spezifische Verhalten des Datenbanksystems in diesem Fall kennt.

Wenn die Offline-Redo-Log-Dateien zurückgeladen werden sollen, ist auf folgendes zu achten:

Die benötigten Offline-Redo-Log-Dateien müssen für jede Instanz separat zurückgeladen werden (mittels SAPDBA oder einem BRRESTORE-Aufruf). Zielverzeichnis ist dabei für die Offline-Redo-Log-Dateien aller Instanzen das Archivierungsverzeichnis der Instanz, von der aus das Recovery des Datenbanksystems gestartet werden soll. Starten Sie dann das Recovery (Informationen dazu finden Sie in der ORACLE-Dokumentation).