Partielle Offline-Backups mit RMAN als Fallback-Methode

By | 30. September 2019

Wer essentielle Änderungen am Oracle Datenbank-Kern vornimmt, z.B. durch ein Datenbankupgrade, benötigt eine gute Fallback-Strategie, um im Fehlerfall wieder die Datenbank in den Ursprungszustand zu versetzen. Dabei bieten sich verschiedene Verfahren an. Man kann, sofern vorhanden, auf ein regulär laufendes Backup zurückgreifen, eine extra Online- oder Offline-Vollsicherung oder, wenn es sich um eine virtuelle Maschine handelt, vorher u.U. einen Snapshot des Datenbankservers machen. Auch das Setzen eines Guaranteed Restore Points, um mittels Flashback Database Technik wieder zurück zu kommen, ist eine hervorragende Methode, wenn man die Enterprise Edition im Einsatz hat, die Datenbank im Archivelog Mode betrieben wird und der Parameter COMPATIBLE nach dem Upgrade noch nicht auf den Wert der aktuellen Version gesetzt worden ist.

Von einem Upgrade ohne eine getestete Fallback-Methode ist dringend abzuraten. In diesem Beitrag möchte ich eine von mir favorisierte Fallback-Methode vorstellen, die ich verwende, wenn ich nur eine Standard Edition vor mir habe oder die Datenbank sich im Noarchivelog Mode befindet.

Partielle Offline Backups

Bei einem Upgrade oder Patching werden nicht sämtliche Daten einer Datenbank verändert. Es werden nur Daten des „Datenbank-Kerns“ und eventuell einiger optionalen Oracle Komponenten verändert. Diese befinden sich in erster Linie in den Repository-Tablespaces SYSAUX und SYSTEM. Wenn es sich um eine ältere Datenbank handelt, dann liegen die Repository-Daten auch manchmal noch in weiteren Tablespaces wie XDB, ODM, DRSYS oder TOOLS. Bei einem Upgrade oder Patching werden jedoch keine Benutzer- und Anwendungsdaten, die z.B. im Tablespace USERS oder anderen benutzerdefinierten Anwendungs-Tablespaces liegen, verändert!
Partial Backuop
Genau diesen Umstand macht sich die Fallback-Methode „Partielles Offline Backup“ zu nutze. Da Benutzerdaten bei einem Upgrade nie geändert werden, brauchen diese auch nicht zum Zweck der Wiederherstellung eines gescheiterten Upgrades gesichert werden. Ganz so einfach ist es jedoch nicht. Will man sicherstellen, dass eine Wiederherstellung der Datenbank erfolgreich ist, muss man dafür sorgen, dass alle Datenbankdateien, sprich die wiederhergestellten und die noch vorhandenen „Benutzerdaten“-Datenbankdateien auch wieder untereinander konsistent sind. Man erreicht dies, indem man die Tablespaces mit den Benutzer-/Anwendungsdaten vor der Offline-Sicherung in den READ ONLY Modus setzt. Dadurch werden diese vor Änderungen im Datafile-Header geschützt.

Der Oracle Database Upgrade Assistant 19c (DBUA) bietet diese Methode übrigens auch unter „Select Recovery Options“ mit der Option „Use RMAN Backups“ und „Create New Partial Offline Backup with User Tablespaces  set to R/O“an, wenn man sein Upgrade mit diesem durchführen und diesem auch die Sicherung überlassen möchte.

Vorteile:

1. Der benötigte Platz für die Sicherungsdateien ist sehr gering, da keine Benutzerdaten gesichert werden.
2. Die Dauer der Sicherung und einer Wiederherstellung (Fallback) ist sehr kurz, da keine Benutzerdaten gesichert werden.

Insbesondere Datenbanken, die sehr viele Benutzerdaten beinhalten, profitieren von dieser Methode. Je höher der Anteil der Benutzerdaten im Verhältnis zu den Repository-Daten, desto größer der Vorteil. Da man die Downtime bei einem Upgrade in der Regel so gering wie möglich halten möchte, ist es sehr hilfreich, wenn der Anteil der Zeit, die eine vorherige Sicherung benötigt, so gering wie möglich ist. Vollsicherungen von sehr großen Datenbanken können unter Umständen Stunden dauern – eine Wiederherstellung aus einer Vollsicherung ebenso lange.
Aufgrund des geringen Platzbedarfes einer Partiellen Sicherung, ist es meistens möglich, dass man als Ziel für die RMAN-Sicherungsdateien ein Verzeichnis im lokalen Filesystem wählen kann. Ein Filesystem mit dem erforderlichen Freiplatz von nur wenigen Gigabyte lässt sich in der Regel leicht finden.

Flussdiagramm Partielle Offline Backups als Fallback-Strategie

Beispiel Upgrade von Oracle 12.1 auf 19.3

Durchführung von Partiellen RMAN Offline Backups

Zeitpunkt: Unmittelbar vor einem Upgrade

Man kann zwar auch Offline-Backups durch manuelles Kopieren der notwendigen Datenbankdateien, Redologs und Controlfiles durchführen (User-Managed-Backup), ich bevorzuge allerdings die Nutzung des Oracle Recovery Managers (RMAN). Das Risiko, damit eine unbrauchbare Sicherung zu erstellen, ist weitaus geringer. Bei einer Sicherung durch Kopieren muss man selber dafür sorgen, dass man alle notwendigen Dateien erwischt.

Im nachfolgenden Beispiel wird eine partielle Sicherung einer Datenbank MYDB durchgeführt. Ein RMAN-Recovery Catalog wird nicht genutzt. Die Scripte funktionieren ab der Oracle Version Oracle 11.2.0.4.

 

A.) Benutzerdaten-Tablespaces auf READ ONLY setzen

Als DBA Users die erforderlichen SQL-Statements für das Ändern der Benutzerdaten-Tablespaces generieren. Bitte beachten, dass bei einer Multitenant-Datenbank in jeder PDB die Benutzerdaten-Tablespaces auf READ ONLY zu setzen sind.

sqlplus system /
set linesize 130
set pagesize 0
set feedback off
set verify off

select 'alter tablespace '||tablespace_name||' read only;' from dba_tablespaces
where tablespace_name not in ('TOOLS','ODM','XBD','SYSAUX','DRSYS','SYSTEM')
and tablespace_name not in
(
select distinct tablespace_name
from dba_segments 
where owner in ('AUDSYS','CTXSYS','DVSYS','LBACSYS','MDSYS','ORDDATA','ORDSYS','WMSYS','XDB')
)
and contents != 'UNDO'
and status = 'ONLINE'
and contents != 'TEMPORARY';

Mit den generierten SQL-Befehlen die Benutzerdaten-Tablespaces auf READ ONLY setzen:

SQL> alter tablespace APPTBLS read only;
SQL> alter tablespace USERS read only;

Tablespace-Status anzeigen:

SQL> select TABLESPACE_NAME, STATUS, CONTENTS from dba_tablespaces;
SYSTEM                         ONLINE    PERMANENT
SYSAUX                         ONLINE    PERMANENT
UNDOTBS1                       ONLINE    UNDO
TEMP                           ONLINE    TEMPORARY
USERS                          READ ONLY PERMANENT
APPTBLS                        READ ONLY PERMANENT

 

B.) Offline RMAN-Sicherung durchführen

Als Backupziel wir das lokale Verzeichnis /u01/backup/ genutzt. Es ist aber auch möglich, sofern ASM im Einsatz ist, als Backupziel eine ASM Diskgroup zu nutzen.

rman target /
run
{
shutdown immediate;
startup mount;
sql "create restore point BEFORE_UPGRADE";
allocate channel ch1 device type disk;
set nocfau;
backup database SKIP READONLY format "/u01/backup/datafile_bckp_%d_%T_%U" TAG BEFORE_UPGRADE;
backup spfile format "/u01/backup/spfile_bckp_%d_%T_%U" TAG BEFORE_UPGRADE;
backup current controlfile format "/u01/backup/cntrlfile_bckp_%d_%T_%U" TAG BEFORE_UPGRADE;
sql "create pfile=''/u01/backup/pfile_backup.ora'' from spfile";
sql "alter database open";
}

Der Backup-Parameter SKIP READ ONLY bewirkt, dass die READ ONLY Tablespaces nicht mitgesichert werden. Das Setzen eines Restore-Points und des Tags „BEFORE_UPGRADE“ macht eine spätere Wiederherstellung dieser Sicherung komfortabler.

 

Datenbankupgrade

Das Datenbank-Upgrade nach der Sicherung mit einer preferierten Methode durchführen.

 

Benutzerdaten-Tablespace wieder auf READ WRITE setzen

Nur wenn das Upgrade erfolgreich war und das zuvor durchgeführte Backup nicht mehr benötigt wird, sollten die Benutzerdaten-Tablespaces wird auf READ WRITE gesetzt werden, damit die Benutzer und Anwendungen wieder Änderungen durchführen können.

Achtung: Nachdem die Benutzerdaten-Tablespaces wieder auf READ WRITE gesetzt worden ist, ist das Partielle Offline Backup für eine Wiederherstellung der Datenbank nicht mehr nutzbar!

sqlplus system /
SQL> alter tablespace USERS read write;
SQL> alter tablespace TPCCTAB read write;

Tablespace-Status anzeigen:

SQL> select tablespace_name, status, contents from dba_tablespaces;
TABLESPACE_NAME                STATUS    CONTENTS
------------------------------ --------- ---------
SYSTEM                         ONLINE    PERMANENT
SYSAUX                         ONLINE    PERMANENT
UNDOTBS1                       ONLINE    UNDO
TEMP                           ONLINE    TEMPORARY
USERS                          ONLINE    PERMANENT
APPTBLS                        ONLINE    PERMANENT     

Datenbank öffnen

SQL> alter database open;

 

Wiederherstellung aus einem Partiellen RMAN Offline Backup

Wenn das Upgrade fehlgeschlagen ist, kann man das zuvor erstellte partielle Offline Backup verwenden, um die Datenbank wieder in den Ursprungszustand zurückzuversetzen.
Die Wiederherstellung der Datenbank aus einem Partiellen RMAN Offline Backup mit RMAN unterscheidet sich im Prinzip nicht zu einer Wiederherstellung aus einem Vollbackup mit anschließendem unvollständigen Recovery.

 

A.) Backupdateien und Restorepoint anzeigen

Die Datenbank muss dazu mindestens im MOUNT-Status sein.

rman target /
RMAN> list backuppiece TAG BEFORE_UPGRADE;
List of Backup Pieces
BP Key  BS Key  Pc# Cp# Status      Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
20      20      1   1   AVAILABLE   DISK        /u01/backup/cntrlfile_bckp_MYDB1_20190929_0oud02in_1_1
19      19      1   1   AVAILABLE   DISK        /u01/backup/spfile_bckp_MYDB1_20190929_0nud02im_1_1
18      18      1   1   AVAILABLE   DISK        /u01/backup/datafile_bckp_MYDB1_20190929_0mud02ij_1_1
17      17      1   1   AVAILABLE   DISK        /u01/backup/datafile_bckp_MYDB1_20190929_0lud02i5_1_1

Die angezeigten Pfade für das Spfile- und das Controlfile-Backup sollten notiert werden, da sie im weiteren Verlauf benötigt werden.

Restore Point anzeigen:

RMAN> list restore point all;
SCN              RSP Time            Type       Time                Name
---------------- ------------------- ---------- ------------------- ----
1049971                                         29.09.2019 15:31:17 BEFORE_UPGRADE

 

B.) Umgebungsvariablen setzen

Die Wiederherstellung  muss aus dem ursprünglichen Oracle Home erfolgen, sprich, die ORACLE_HOME und PATH Umgebungsvariable müssen auf das alte ORACLE HOME referenzieren, wenn RMAN aufgerufen wird.

Beispiel Linux:

export ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH

 

C.) Server Parameterfile wiederherstellen

Die Wiederherstellung des Spfiles ist nur notwendig, wenn dies im Rahmen des Upgrades verändert worden ist. Dies kann eigentlich nur passieren, wenn das Spfile nicht lokal im ORACLE_HOME/dbs Verzeichnis, sondern in einem Shared-Storage liegt.

Da RMAN nicht das Spfile,  mit dem eine aktive Datenbankinstanz gestartet wurde, überschreiben kann, muss die Datenbank temporär mit dem bei der Sicherung generierten Pfile gestartet werden.  Vor der Wiederherstellung muss man den genauen Pfad des Spfiles kennen, da diese nicht immer im Standard-Pfad liegen. Den aktuellen Pfad kann man man sich mit  show parameter spfile anzeigen lassen, wenn der Instance noch läuft. Alternativ steht der Pfad aber auch im Alert.log.

Besipiele mögliche Pfade Spfile:

Filesystem-Pfad:  /u01/app/oracle/product/12.1/dbhome_1/dbs/spfileDB12.ora
ASM-Pfad und Verwendung Alias-Name:  +DATA/DB12/spfileDB12.ora
ASM-Pfad und Verwendung OMF-Name:  +DATA/DB12/PARAMETERFILE/spfile.269.1020880561

rman target /
run 
{
startup force nomount pfile='/u01/backup/pfile_backup.ora';
restore spfile to "+DATA/DB12/spfileDB12.ora" from "/u01/backup/spfile_bckp_MYDB1_20190929_0nud02im_1_1";
}
using target database control file instead of recovery catalog


Oracle instance started

Total System Global Area     810053632 bytes
Fixed Size                     2257600 bytes
Variable Size                260050240 bytes
Database Buffers             541065216 bytes
Redo Buffers                   6680576 bytes

Starting restore at 29-SEP-19
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=39 device type=DISK

channel ORA_DISK_1: restoring spfile from AUTOBACKUP /u01/backup/spfile_bckp_MYDB1_20190929_0nud02im_1_1
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 29-SEP-19

 

D.) Datenbank mit wiederhergestelltem Spfile starten

RMAN> startup force nomount;
Oracle instance started

Total System Global Area     626327552 bytes

Fixed Size                     2291472 bytes
Variable Size                499124464 bytes
Database Buffers             117440512 bytes
Redo Buffers                   7471104 bytes

Bei Verwendung ASM und RAC bzw. Oracle Restart ab Version 12c: Hier kann es notwendig sein, den Pfad des Spfile im Anschluss mit dem srvctl-Utility auf den ASM-Aliasnamen zu setzen, da möglicherweise der OMF-Namen eingetragen ist und dieser nicht mehr passt.

Anzeige der aktuellen Konfiguration: srvctl config database -d DB12
Beispiel Anpassung Pfad auf Alias-Name des Spfiles: srvctl modify database -d DB12 -spfile ‚+DATA/DB12/spfileDB12.ora‘

 

E.) Controlfiles wiederherstellen

RMAN> restore controlfile from "/u01/backup/cntrlfile_bckp_MYDB1_20190929_0oud02in_1_1";
Starting restore at 29-SEP-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=39 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u02/oradata/MYDB1/control01.ctl
output file name=/u02/oradata/MYDB1/control02.ctl
Finished restore at 29-SEP-19

 

F.) Datenbank mit wiederhergestellten Controlfiles mounten

RMAN> alter database mount;

 

G.) Datenbank wiederherstellen

RMAN> restore database from tag=BEFORE_UPGRADE;
Starting restore at 29-SEP-19
Starting implicit crosscheck backup at 29-SEP-19
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=39 device type=DISK
Crosschecked 3 objects
Finished implicit crosscheck backup at 29-SEP-19

Starting implicit crosscheck copy at 29-SEP-19
using channel ORA_DISK_1
Finished implicit crosscheck copy at 29-SEP-19

searching for all files in the recovery area
cataloging files...
no files cataloged

using channel ORA_DISK_1

skipping datafile 4; already restored to file /u02/oradata/MYDB1/users01.dbf
skipping datafile 5; already restored to file /u02/oradata/MYDB1/apptbls01.dbf
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u02/oradata/MYDB1/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u02/oradata/MYDB1/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u02/oradata/MYDB1/undotbs01.dbf
channel ORA_DISK_1: reading from backup piece /u01/backup/datafile_bckp_MYDB1_20190929_0lud02i5_1_1
channel ORA_DISK_1: piece handle=/u01/backup/datafile_bckp_MYDB1_20190929_0lud02i5_1_1 tag=BEFORE_UPGRADE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 29-SEP-19

Bemerkung: Da keine Benutzerdaten wiederhergestellt werden, nimmt die Wiederherstellung  sehr wenig Zei in Anspruch. Wie man in der Ausgabe sehen kann, werden die Benuzterdaten-Tablepaces überprungen.

 

H.) Datenbank recovern

RMAN> recover database until restore point BEFORE_UPGRADE;
Starting recover at 29-SEP-19
using channel ORA_DISK_1
datafile 4 not processed because file is read-only
datafile 5 not processed because file is read-only

starting media recovery
media recovery complete, elapsed time: 00:00:00

Finished recover at 29-SEP-19

Die Nutzung des Restore-Points verhindert, dass die Datenbank nur bis zum Zeitpunkt vor dem Upgrade recovert wird.

 

J.) Datenbank mit RESETLOGS öffnen

RMAN> alter database open resetlogs;

 

K.) Die Benutzerdaten-Tablespaces wieder in den READ-Write Modus versetzen

sqlplus system /
SQL> alter tablespace USERS read write;
SQL> alter tablespace APPTBLS read write;

L.) Sonstige Änderungen rückgängig machen

Möglicherweise müssen noch weitere vom Upgrade Assistent durchgeführte Änderungen rückgängig gemacht werden. Bei Windows könnten z.B. die Oracle Services bereits geändert oder bei einem Linuxsystem die /etc/oratab modifiziert  worden sein.

 

Löchen des Partiellen RMAN Offline Backup

Wenn das Partielle Offline Backup nicht mehr benötigt wird, weil das Upgrade erfolgreich war und es ausgeschlossen ist, dieses für eine Wiederherstellung noch einmal zu benötigen, kann es wie folgt gelöscht werden.

rman target /
RMAN> delete backup tag BEFORE_UPGRADE;
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=7 device type=DISK

List of Backup Pieces
BP Key  BS Key  Pc# Cp# Status      Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
17      17      1   1   AVAILABLE   DISK        /u01/backup/datafile_bckp_MYDB1_20190929_0lud02i5_1_1
18      18      1   1   AVAILABLE   DISK        /u01/backup/datafile_bckp_MYDB1_20190929_0mud02ij_1_1
19      19      1   1   AVAILABLE   DISK        /u01/backup/spfile_bckp_MYDB1_20190929_0nud02im_1_1

Do you really want to delete the above objects (enter YES or NO)? YES

deleted backup piece
backup piece handle=/u01/backup/datafile_bckp_MYDB1_20190929_0lud02i5_1_1 RECID=17 STAMP=1020267077
deleted backup piece
backup piece handle=/u01/backup/datafile_bckp_MYDB1_20190929_0mud02ij_1_1 RECID=18 STAMP=1020267092
deleted backup piece
backup piece handle=/u01/backup/spfile_bckp_MYDB1_20190929_0nud02im_1_1 RECID=19 STAMP=1020267094
Deleted 3 objects

Optional kann auch der erstellte Restore Point gelöscht werden.

RMAN> drop restore point BEFORE_UPGRADE;