Datenbank mit RMAN-Backups aus Object Storage wiederherstellen

In diesem Artikel wird erläutert, wie Sie ein Recovery Manager-(RMAN-)Backup wiederherstellen, das in Object Storage gespeichert ist.

Voraussetzungen

Sie benötigen Folgendes:

  • Ein neues DB-System, in dem die Datenbank wiederhergestellt werden soll (siehe "Voraussetzungen" unten). Weitere Informationen finden Sie unter DB-Systeme erstellen - Überblick.
  • Das Oracle Database Cloud-Backupmodul muss auf dem DB-System installiert sein. Weitere Informationen finden Sie unter Backupmodul auf dem DB-System installieren in Datenbank mit RMAN in Object Storage sichern.

Voraussetzungen

Bei den unten stehenden Verfahren wird Folgendes vorausgesetzt:

  • Ein neues DB-System wurde zum Hosten der wiederhergestellten Datenbank erstellt. Auf dem neuen DB-System ist keine andere Datenbank vorhanden. Sie können eine Wiederherstellung auf einem DB-System durchführen, auf dem bereits Datenbanken vorhanden sind. Das wird jedoch in diesem Thema nicht behandelt.

  • Die ursprüngliche Datenbank ist nicht mehr vorhanden, nur das letzte RMAN-Backup liegt vor. Bei diesem Verfahren wird davon ausgegangen, dass das DB-System (einschließlich der Datenbank) nicht mehr vorhanden ist.

    Hinweis:

    Daten, die nicht im letzten Backup enthalten sind, gehen verloren.
  • Das Oracle Wallet und/oder die Verschlüsselungsschlüssel, die von der ursprünglichen Datenbank zum Zeitpunkt des letzten Backups verwendet wurden, sind verfügbar.
  • Das RMAN-Backup enthält eine Kopie der Kontrolldatei und der SPFILE des letzten Backups sowie alle Datendatei- und Archive-Logbackups, die für ein vollständiges Datenbank-Recovery erforderlich sind.
  • Beim Wiederherstellen wird kein RMAN-Katalog verwendet.

Verwandte Themen

Speicher auf dem DB-System einrichten

  1. Stellen Sie eine SSH-Verbindung zum DB-System her. 
    ssh -i <private_key_path> opc@<db_system_ip_address>
  2. Melden Sie sich als "opc" an, und wechseln Sie mit "sudo" zum Benutzer "root". Verwenden Sie sudo su - mit einem Bindestrich, um das Profil des Root-Benutzers aufzurufen. Dadurch wird der PATH auf das dbcli-Verzeichnis gesetzt (/opt/oracle/dcs/bin). 
    login as: opc
sudo su -
  3. Sie können ein vorhandenes leeres Datenbank-Home verwenden oder ein neues Home für die Wiederherstellung erstellen. Verwenden Sie zur Ausführung dieses Schritts die entsprechenden Befehle.

    Wenn Sie ein vorhandenes Datenbank-Home verwenden:

    • Verwenden Sie die Dbhome-Befehle, um die Datenbank-Homes aufzulisten. 

      dbcli list-dbhomes
      Ausgabe:
      ID                                       Name                 DB Version Home Location
---------------------------------------- -------------------- ---------- ---------------------------------------------
2e743050-b41d-4283-988f-f33d7b082bda     OraDB12102_home1     12.1.0.2   /u01/app/oracle/product/12.1.0.2/dbhome_1

    • Verwenden Sie die Datenbankbefehle, um sicherzustellen, dass das Datenbank-Home mit keiner Datenbank verknüpft ist.

    Verwenden Sie gegebenenfalls die Dbhome-Befehle, um ein Datenbank-Home für die Wiederherstellung zu erstellen.

  4. Verwenden Sie die Dbstorage-Befehle, um Verzeichnisse für DATA-, RECO- und REDO-Speicher einzurichten. Im folgenden Beispiel wird ACFS-Speicher mit 10 GB für die Datenbank "rectest" erstellt.
    dbcli create-dbstorage --dbname rectest --dataSize 10 --dbstorage ACFS

    Hinweis:

    Bei der Wiederherstellung einer Datenbank der Version 11.2 muss ACFS-Speicher angegeben werden.

Datenbankwiederherstellung und -Recovery ausführen

  1. Stellen Sie eine SSH-Verbindung zum DB-System her, melden Sie sich als "opc" an, und wechseln Sie dann zum Benutzer "oracle".
    sudo su - oracle
  2. Erstellen Sie einen Eintrag in /etc/oratab für die Datenbank. Verwenden Sie dieselbe SID wie die der ursprünglichen Datenbank.
    db1:/u01/app/oracle/product/12.1.0.2/dbhome_1:N
  3. Legen Sie die Umgebungsvariablen ORACLE_HOME und ORACLE_SID mit dem Utility "oraenv" fest.
    . oraenv
  4. Rufen Sie die DBID der ursprünglichen Datenbank ab. Diese kann aus dem Dateinamen der controlfile des automatischen Backups auf dem Backupmedium ermittelt werden. Der Dateiname enthält eine Zeichenfolge mit der DBID. Das typische Format der Zeichenfolge ist c-DDDDDDDDDDDD-YYYYMMDD-NN. Dabei ist DDDDDDDDDDDD die DBID, YYYYMMDD das Datum, an dem das Backup erstellt wurde, und NN eine Folgenummer, durch die der Dateiname eindeutig wird. Die DBID in den folgenden Beispielen lautet 1508405000. Ihre DBID weicht davon ab.

    Verwenden Sie die folgende Curl-Syntax, um eine allgemeine Abfrage von Object Storage auszuführen. Die rot gekennzeichneten Parameter sind die Parameter, die Sie bei der Installation des Backupmoduls angegeben haben, wie unter Backupmodul auf dem DB-System installieren in Datenbank mit RMAN in Object Storage sichern beschrieben. 

    curl -u '<user_ID>.com:<auth_token>' -v https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

    Informationen zum Suchen des Regionsnamens finden Sie unter Regionen und Availability-Domains.

    Beispiel:

    curl -u 'djones@mycompany.com:1cnk!d0++ptETd&C;tHR' -v https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/myobjectstoragenamespace

    Verwenden Sie die folgende Syntax, um die DBID aus dem Kontrolldateinamen abzurufen:

    curl -u '<user_id>.com:<auth_token>' -v https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>/<bucket_name>?prefix=sbt_catalog/c-

    Beispiel:

    curl -u 'djones@mycompany.com:1cnk!d0++ptETd&C;tHR' -v https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/myobjectstoragenamespace/dbbackups/?prefix=sbt_catalog/c-

    In der Beispielausgabe unten ist 150840505000 die DBID.

    {
    "bytes": 1732,
    "content_type": "binary/octet-stream",
    "hash": "f1b61f08892734ed7af4f1ddaabae317",
    "last_modified": "2016-08-11T20:28:34.438000",
    "name": "sbt_catalog/c-1508405000-20160811-00/metadata.xml"
}
  5. Führen Sie RMAN aus, und stellen Sie eine Verbindung zur Zieldatenbank her. Sie müssen keine pfile oder spfile erstellen und keine Backup-controlfile verwenden. Diese werden in den folgenden Schritten wiederhergestellt. Beachten Sie, dass für die Zieldatenbank (not started) angegeben wird. Das ist normal und an dieser Stelle zu erwarten.
    rman target /
    Ausgabe:
    Recovery Manager: Release 12.1.0.2.0 - Production on Wed Jun 22 18:36:40 2016
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
connected to target database (not started)
  6. Legen Sie die DBID mit dem oben ermittelten Wert fest.
    set dbid 1508405000;
  7. Führen Sie den folgenden Befehl aus. Wenn die Server Parameter File nicht verfügbar ist, versucht RMAN, die Instanz mit einer Dummy-Server-Parameter-File zu starten. Die Fehler ORA-01078 und LRM-00109 sind normal und können ignoriert werden.
    STARTUP NOMOUNT
    startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/initdb1.ora'
 
starting Oracle instance without parameter file for retrieval of spfile
Oracle instance started
 
Total System Global Area    2147483648 bytes
 
Fixed Size                     2944952 bytes
Variable Size                847249480 bytes
Database Buffers            1254096896 bytes
Redo Buffers                  43192320 bytes
  8. Stellen Sie die Server Parameter File aus dem automatischen Backup wieder her.

    SBT_LIBRARY ist die Library, die bei Installation des Backupmoduls mit dem Parameter -libDir angegeben wurde. Beispiel: /home/oracle/lib/.

    OPC_PFILE ist die Datei, die bei Installation des Backupmoduls mit dem Parameter -configfile angegeben wurde. Beispiel: /home/oracle/config. 

    set controlfile autobackup format for device type sbt to '%F';
run {
  allocate channel c1 device type sbt PARMS  'SBT_LIBRARY=/home/oracle/lib/libopc.so, SBT_PARMS=(OPC_PFILE=/home/oracle/config)';
  restore spfile from autobackup;
}
  9. Erstellen Sie das Verzeichnis für audit_file_dest. Das Standardverzeichnis lautet /u01/app/oracle/admin/$ORACLE_SID/adump. Sie können die von der ursprünglichen Datenbank verwendete Einstellung anzeigen, indem Sie in der SPFILE nach der Zeichenfolge audit_file_dest suchen.
    strings ${ORACLE_HOME}/dbs/spfile${ORACLE_SID}.ora | grep audit_file_dest
*.audit_file_dest='/u01/app/oracle/admin/db1/adump'
 
mkdir -p /u01/app/oracle/admin/db1/adump
  10. Wenn das Block Change Tracking in der ursprünglichen Datenbank aktiviert war, erstellen Sie das Verzeichnis für die Block-Change-Tracking-Datei. Das Verzeichnis wird unter db_create_file_dest erstellt. Durchsuchen Sie die spfile nach dem Namen des Verzeichnisses.
    strings ${ORACLE_HOME}/dbs/spfile${ORACLE_SID}.ora | grep db_create_file_dest
*.db_create_file_dest='/u02/app/oracle/oradata/db1'
 
mkdir -p /u02/app/oracle/oradata/db1/<$ORA_UNQNAME if available or database name>/changetracking
  11. Starten Sie die Instanz mit der wiederhergestellten Server Parameter File neu.
    STARTUP FORCE NOMOUNT;
  12. Stellen Sie die Kontrolldatei aus dem automatischen RMAN-Backup wieder her, und mounten Sie die Datenbank. 
    set controlfile autobackup format for device type sbt to '%F';
run {
  allocate channel c1 device type sbt PARMS 'SBT_LIBRARY=/home/oracle/lib/libopc.so, SBT_PARMS=(OPC_PFILE=/home/oracle/config)';
  restore controlfile from autobackup;
  alter database mount;
}
  13. Stellen Sie die Datenbank wieder her.
    RESTORE DATABASE;
RECOVER DATABASE;
  14. RMAN führt das Recovery mit archivierten Redo-Logs aus, bis keine mehr gefunden werden. Es ist normal, dass ein ähnlicher Fehler wie unten gezeigt auftritt, wenn RMAN das letzte archivierte Redo-Log im Backup eingespielt hat und keine weiteren Logs finden kann.
    unable to find archived log
archived log thread=1 sequence=29
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 06/28/2016 00:57:35
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 29 and starting SCN of 2349563
  15. Öffnen Sie die Datenbank mit "resetlogs".
    ALTER DATABASE OPEN RESETLOGS;

Das Recovery ist abgeschlossen. Die Datenbank enthält alle festgeschriebenen Transaktionen gemäß dem letzten gesicherten archivierten Redo-Log.