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!
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.
Default Tablespace der Datenbank ändern
Befinden sich Anwendungsobjekte im USERS Tablespace und will man diese daher auf Read Only setzen, dann sollte man sicherstellen, dass der Default Tablespace der Datenbank auf einen anderen Tablespace als USERS gesetzt wird (z.B. SYSAUX). Insbesondere bei der Nutzung von AutoUpgrade als Upgrade-Tool der Wahl, ist hier eine Änderung zwingend notwendig, da ansonsten das AutoUprade Tool den Tablespace USERS automatisch vor dem Upgrade wieder auf ReadWrite setzt was dann in Falle einer Wiederhstellung zu einer unbrauchbaren Datenbank führt!
col default_permanent_tablespace for a30 select property_value default_permanent_tablespace from database_properties where property_name = 'DEFAULT_PERMANENT_TABLESPACE';
DEFAULT_PERMANENT_TABLESPACE ------------------------------ USERS
Default Tablespace der Datenbank auf SYSAUX setzen:
SQl> alter database default tablespace sysaux;
col default_permanent_tablespace for a30 select property_value default_permanent_tablespace from database_properties where property_name = 'DEFAULT_PERMANENT_TABLESPACE';
DEFAULT_PERMANENT_TABLESPACE ------------------------------ SYSAUX
Default Tablespace der Oracle Maintained User ändern
Mit dem Ändern des Default Permanent Tablespaces auf SYSAUX sollten sich auch implizit die Default Tablespaces der Oracle Maintained User geändert haben, die zuvor auf USERS gesetzt waren.
col username for a30 col default_tablespace for a30 select username, default_tablespace from dba_users where ORACLE_MAINTAINED='Y' order by 2,1;
Beispiel
USERNAME DEFAULT_TABLESPACE ------------------------------ ------------------------------ ANONYMOUS SYSAUX APPQOSSYS SYSAUX AUDSYS SYSAUX CTXSYS SYSAUX DBSFWUSER SYSAUX DBSNMP SYSAUX DIP SYSAUX GGSYS SYSAUX GSMADMIN_INTERNAL SYSAUX GSMCATUSER SYSAUX GSMUSER SYSAUX ORACLE_OCM SYSAUX REMOTE_SCHEDULER_AGENT SYSAUX WMSYS SYSAUX XDB SYSAUX OJVMSYS SYSTEM OUTLN SYSTEM SYS SYSTEM SYSBACKUP SYSTEM SYSDG SYSTEM SYSKM SYSTEM SYSRAC SYSTEM SYSTEM SYSTEM SYS$UMF SYSTEM XS$NULL USERS
In dem o.a. Beispiel gibt es noch den Account XS$NULL, dessen Default Tablespace sich leider auch nicht manuell nicht ändern lässt. Wenn man in dem Fall nachfolgend mit AutoUpgrade arbeiten möchte, dann darf man den USERS Tablesspace nicht auf Read Only setzen und muss ihn zwingend mitsichern!
Datenbankupgrade
Das Datenbank-Upgrade nach der Sicherung mit der preferierten Upgarde-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;
Default Tablespace wieder auf SYSAUXzurücksetzen
Default Tablespace der Datenbank wieder auf USERS setzen, wenn das Upgrade erfolgreich war
SQl> alter database default tablespace users;
col default_permanent_tablespace for a30 select property_value default_permanent_tablespace from database_properties where property_name = 'DEFAULT_PERMANENT_TABLESPACE';
DEFAULT_PERMANENT_TABLESPACE ------------------------------ USERS
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;