
BRARCHIVE wird auf den Rechnern aller ORACLE-Instanzen gestartet. Allerdings unterscheiden sich seine Aktivitäten in Abhängigkeit davon, ob es sich um den Rechner der DDB-Instanz handelt oder nicht.
Jede Nicht-DDB-Instanz kann über ein NFS-Mount auf das zentrale Archivierungsverzeichnis zugreifen.

Name des R/3-Systems: C11
Großes lokales Archivierungsverzeichnis auf der DDB-Instanz:
Das Verzeichnis
/oracle/C11/saparch zeigt über einen Link auf dieses große Archivierungsverzeichnis.Kleine, lokale Archivierungsverzeichnisse auf den Nicht-DDB-Instanzen:
/oracle/C11/saparchDas große Archivierungsverzeichnis wird auf jeder Nicht-DDB-Instanz mittels NFS-Mount angeschlossen unter:
/oracle/saparchglobalAngaben in
init<DBSID>.sapParameter
archive_copy_dir auf allen ORACLE-InstanzenAngaben in
init<DBSID>.ora :log_archive_dest = /oracle/C11/saparch/C11arch
log_archive_format = %t_%s.dbf
%t
%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 der Nicht-DDB-Instanzen verläuft wie folgt:
Archivierung auf Platte
Auf jeder Nicht-DDB-Instanz wird BRARCHIVE regelmäßig oder mit der Option
-f gestartet. Seine Aufgabe ist es, die auf der jeweiligen Instanz angefallenen Offline-Redo-Log-Dateien von dem lokalen Archivierungsverzeichnis in das NFS-gemountete zentrale Archivierungsverzeichnis zu kopieren (BRARCHIVE-Aufruf zum Archivieren der Offline-Redo-Log-Dateien auf Platte, Option -d disk ). Um den Erfolg der Operation zu überprüfen, sollten Sie die Option -w zur Verifikation der Sicherung verwenden (siehe obige Abbildung).
Dieser BRARCHIVE-Lauf sollte täglich mittels
Archivierung auf Band
Der auf dem Rechner der DDB-Instanz laufende BRARCHIVE archiviert die in dem zentralen Archivierungsverzeichnis gefundenen Offline-Redo-Log-Dateien (BRARCHIVE-Aufruf zum Archivieren der Offline-Redo-Log-Dateien auf Band, Option
-d tape ). Demzufolge werden die Offline-Redo-Log-Dateien aller ORACLE-Instanzen über dieses an den DDB-Rechner lokal angeschlossene Sicherungs-Gerät fortlaufend auf den/die Datenträger (Bänder) archiviert.Vorteile
Nachteile
·
Auf allen Nicht-DDB-Instanzen muß BRARCHIVE entweder regelmäßig oder mit der Option -f gestartet werden, damit die relativ kleinen Archivierungsverzeichnisse nicht überlaufen.
Dieses Szenario wird normalerweise von SAP installiert. Es sollte in Produktivsystemen generell verwendet werden, insbesondere immer dann, wenn auf allen Instanzen relativ häufig Offline-Redo-Log-Dateien anfallen (und daher mit der Option
-f gearbeitet wird, um einen "Archive Stuck" zu vermeiden).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 aller Instanzen, die auf Band archiviert wurden, können in das zentrale Archivierungsverzeichnis (i. allg. auf der DDB-Instanz liegend) zurückgeladen werden (mittels SAPDBA oder einem BRRESTORE-Aufruf). Überprüfen Sie jetzt unbedingt, ob sich in den Archivierungsverzeichnissen der anderen Instanzen Offline-Redo-Log-Dateien befinden, die noch nicht von BRARCHIVE in das Verzeichnis der zentralen Instanz kopiert worden sind (das heißt, die Archivierung auf Platte ist noch nicht gelaufen). Gegebenenfalls muß BRARCHIVE auf den einzelnen Instanzen gestartet werden, um fehlende Offline-Redo-Log-Dateien in das zentrale Archivierungsverzeichnis zu kopieren. Sie können dann das Recovery auf der zentralen Instanz starten (Informationen dazu finden Sie in der ORACLE-Dokumentation).