Downgrade einer RAC-Datenbank mittels garantiertem Restore-Punkt
Erfahrungsgemäß versucht man, nach einem Datenbank-Upgrade meistens, in jedem Fall auf der höheren Version zu bleiben und evtl. auftretende Anwendungsprobleme in der neuen Umgebung zu löschen. Aber wenn “alle Stricke reißen” oder wenn unmittelbar während oder nach des Upgrades etwas schiefgeht und man schnell zur alten Version zurück muss, dann ist ein Downgrade die Methode der Wahl. Eine Methode dazu ist der Downgrade zu einem garantierten Restore-Punkt. Wie funktioniert das bei einer RAC-Datenbank?
Schauen wir uns das Ganze einmal am Beispiel eines Upgrades von Oracle 11.2.0.4 nach Oracle 19c bzw. dem darauf folgenden Downgrade an:
Wichtig: Damit ein Downgrade möglich sein soll, darf der COMPATIBLE-Parameter der Datenbank nach dem Upgrade nicht geändert (erhöht) werden.
Vorbereitung
Ausgangspunkt ist eine Oracle 11.2.0.4-Datenbank:
oracle@geri:~/ [UPGR1] srvctl status database -d UPGR Instance UPGR2 is running on node freki Instance UPGR1 is running on node geri oracle@geri:~/ [UPGR1] /u00/app/oracle/product/11.2.0.4/OPatch/opatch lspatches 30298532;Database Patch Set Update : 11.2.0.4.200114 (30298532) OPatch succeeded.
Vor dem Upgrade wird ein garantierter Restore-Punkt gesetzt. Wenn man mit eigenen Skripten („manual upgrade“) arbeitet, dann muss man diesen Schritt selbst in seine Upgrade-Prozedur einbauen. „autoupgrade“ erzeugt automatisch einen garantierten Restore-Punkt.
Beim Database Upgrade Assistant („dbua“) ist das Recovery über einen Restore-Punkt eine der Varianten, die man auswählen kann:
Wenn man einen garantierten Restore-Punkt manuell anlegen möchte, dann ist der Syntax wie folgt:
CREATE RESTORE POINT <restore point name> GUARANTEE FLASHBACK DATABASE;
Stand nach dem Upgrade
oracle@geri:~/ [UPGR1] sqlplus "/ as sysdba"
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Apr 9 15:20:06 2020
Version 19.6.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.6.0.0.0
SQL> show parameter compatible
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
compatible string 11.2.0.4.0
noncdb_compatible boolean FALSE
SQL> select scn,time,name,GUARANTEE_FLASHBACK_DATABASE from v$restore_point;
SCN TIME NAME GUA
---------- ----------------------------------- -------------------- ---
671558 09-APR-20 02.15.24.000000000 PM GRP_1586434524412 YES
SQL> exit
Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.6.0.0.0
Flashback der Datenbank
Der Flashback der Datenbank erfolgt in der 19c-Umgebung:
oracle@geri:~/ [UPGR1] srvctl stop database -d UPGR oracle@geri:~/ [UPGR1] sqlplus "/ as sysdba" SQL*Plus: Release 19.0.0.0.0 - Production on Thu Apr 9 20:34:35 2020 Version 19.6.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Connected to an idle instance. SQL> startup mount; ORACLE instance started. Total System Global Area 3154113400 bytes Fixed Size 8901496 bytes Variable Size 704643072 bytes Database Buffers 2432696320 bytes Redo Buffers 7872512 bytes Database mounted. SQL> flashback database to restore point GRP_1586434524412; Flashback complete. SQL> shutdown immediate; ORA-01109: database not open Database dismounted. ORACLE instance shut down. SQL> exit Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.6.0.0.0
Wechsel zurück in die Oracle 11.2-Umgebung
Beim Cluster muss dabei zusätzlich das in der Cluster-Registry (OCR) gespeicherte ORACLE_HOME auf die alte Version zurückgesetzt werden. Dafür muss srvctl in der 19c-Variante verwendet werden.
oracle@geri:~/ [UPGR1] srvctl downgrade database -db UPGR -oraclehome /u00/app/oracle/product/11.2.0.4 -targetversion 11.2.0.4
Zurücksetzen des ORACLE_HOMEs:
oracle@geri:~/ [UPGR1] echo $ORACLE_HOME /u00/app/oracle/product/11.2.0.4
Öffnen der Datenbank mit RESETLOGS
oracle@geri:~/ [UPGR1] sqlplus "/ as sysdba" SQL*Plus: Release 11.2.0.4.0 Production on Thu Apr 9 20:43:26 2020 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to an idle instance. SQL> startup mount; ORA-01078: failure in processing system parameters LRM-00101: unknown parameter name '__unified_pga_pool_size' ORA-01078: failure in processing system parameters LRM-00101: unknown parameter name '__unified_pga_pool_size'
Oracle 19c hat also ein paar neue Parameter in das spfile geschrieben, die Oracle 11g nicht kennt. Bevor wir die Datenbank als 11.2-Datenbank starten können, müssen wir diese Parameter also erstmal entfernen:
SQL> create pfile='/tmp/initUPGR.ora' from spfile='+DATA/upgr/spfileupgr.ora'; File created. SQL> !vi /tmp/initUPGR.ora
Danach können wir die Datenbank mit RESETLOGS öffnen und legen anschließend noch ein Oracle 11.2-kompatibles spfile an:
SQL> startup mount pfile='/tmp/initUPGR.ora'; ORACLE instance started. Total System Global Area 3140026368 bytes Fixed Size 2257352 bytes Variable Size 822087224 bytes Database Buffers 2298478592 bytes Redo Buffers 17203200 bytes Database mounted. SQL> alter database open resetlogs; Database altered. SQL> create spfile='+DATA/upgr/spfileupgr.ora' from pfile='/tmp/initUPGR.ora'; File created. SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options
Zum Abschluß starten wir die Datenbank mit srvctl als RAC-Datenbank:
oracle@geri:~/ [UPGR1] srvctl start database -d UPGR oracle@geri:~/ [UPGR1] srvctl status database -d UPGR Instance UPGR2 is running on node freki Instance UPGR1 is running on node geri
Anschließend droppen wir noch den Restore-Point:
oracle@geri:~/ [UPGR1] sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Thu Apr 9 20:58:38 2020 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options SQL> drop restore point GRP_1586434524412; Restore point dropped. SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options
Zusammenfassung
Der Downgrade mittels einem garantierten Restore-Point ist eine schnelle und einfache Methode um einen Datenbank-Downgrade durchzuführen. Dabei sind aber einige Punkte zu beachten:
- Der COMPATIBLE-Parameter muss auf dem Ursprungswert bleiben, d.h. in der höheren Version stehen die neuen Features nicht bzw. nur teilweise zur Verfügung.
- Bei einem Downgrade wird die Datenbank auf den Stand VOR dem Upgrade zurückgesetzt, d.h. eventuelle Datenänderungen gehen verloren. Die Auswertung der Redolog- und Archivelog-Dateien mittels LogMiner kann hier Abhilfe schaffen; damit kann man die Datenänderungen ggf. rekonstruieren
- Bei einem garantierten Restore-Point werden die Flashback-Logs nicht überschrieben, d.h. es muss genug Platz in der Fast-Recovery-Area vorhanden sein. Aus diesem Grund sollte man den Restore-Point auch löschen, sobald man ihn nicht mehr benötigt.
- Vom Downgrade einer Datenbank ohne Clusterware unterscheidet sich das Vorgehen bei einer RAC-Datenbank nur durch die beiden Schritte mit srvctl, insbesondere dem “srvctl downgrade”.
Referenzen / weitere Informationen
- Oracle Database 19c Upgrade Guide – Kapitel 7: Downgrading Oracle Database to an Earlier Release
- MOS-Note: Guaranteed Restore Point with Flashback Database disabled generates too many flashback logs (Doc ID 566647.1)
- MOS-Note: Master Note For Oracle Database Downgrade (Doc ID 1151427.1)
- MOS-Note: How to Downgrade a 12.2 Non CDB Database to Previous Release (Doc ID 2193965.1)
- Youtube-Video von Mike Dietrich zu diesem Thema
Amazon Partner Link:
