Oracle online Upgrade von 12c auf 19c

Einleitung

In diesem Artikel gehen wir verstärkt auf den Prozess des Oracle Upgrades von 12c auf 19c mithilfe des Transient Logical Upgrades ein und erklären Ihnen wie Sie das Upgrade mit minimalsten Ausfallzeiten erfolgreich durchführen können.

Transient Logical Upgrade

Mit Database 11g Release 1 hat Oracle eine Möglichkeit eingeführt, mit der physische Standby-Datenbanken mit DataGuard verwendet werden können, um rollende Datenbank-Upgrades nahezu ohne Ausfallzeiten auszuführen. Hierzu muss man die physische Standby-DB in eine logische Standby-DB konvertieren. Die Vorgehensweise, eine Datenbank mit Hilfe einer logischen Standby Datenbank zu aktualisieren wird auch als “Transient Logical Standby - Rolling Upgrade” bezeichnet.

Diese Upgrade-Methode ist aus mehreren Gründen attraktiv:

Sie ermöglicht es, vorhandene physische Standby-Datenbanken für rollende Datenbank-Upgrades zu verwenden
Es wird kein zusätzlicher Speicherplatz benötigt, um eine separate logische Standby-Datenbank nur für den Zweck eines Rolling Upgrades bereitzustellen
Der vorübergehende logische Rolling-Upgrade-Prozess erfordert nur die Ausführung eines einzelnen Katalog-Upgrades, um beide Primär- und Standby-Datenbanken auf eine neue Oracle-Version zu heben. Das Upgrade des Katalogs der zweiten Datenbank erfolgt implizit und für den Administrator transparent.
Wenn der Upgrade-Vorgang abgeschlossen ist, wird die Konfiguration auf die ursprüngliche Konfiguration einer primären Datenbank mit einer physischen Standby-Datenbank zurückgesetzt.

Lizenzbetrachtungen

Im Oracle License Guide befinden sich Einträge zu den Themen

Rolling Upgrades mit Active DataGuard
Rolling Upgrades—Patch Set, Database, and Operating System

Die Spaltenwerte N und Y geben hier lediglich an, ob das entsprechende Feature in der betreffenden Umgebung verfügbar ist. Lizenzspezifische Informationen befinden sich hier in der Spalte Notes. Demnach erfordern Rolling Updates unter Verwendung von Active DataGuard eine zusätzliche Lizenzierung.

Das hier eingesetzte physru_v3 Skript verwendet Active DataGuard nicht. Dementsprechend erfordert die Verwendung dieses Skripts keine zusätzliche Lizenzierung.

Die Lizenzierung im Oracle Umfeld ist oft sehr komplex und ändert sich von Zeit zu Zeit. Bitte konsultieren Sie daher immer den aktuellsten Oracle License Guide oder wenden Sie sich bei Fragen an unsere Oracle Spezialisten!

Ausgangslage

Wir haben als Ausgangspunkt eine 12.2.0.1 Container Datenbank mit DataGuard Konfiguration (Primary: ODB01P, Physical Standby: ODB01PR) und möchten diese mit geringstem Ausfall auf die Zielversion 19.17.0.0.221018 aktualisieren. Die neue Softwareversion wurde im Vorfeld auf beiden Hosts in neuen Homeverzeichnissen installiert.

Vorbereitungen und Konfiguration

Die diversen Checks und Konfigurationsschritte wurden von Oracle in einem Shell Skript zusammengestellt, welches viele der erforderlichen Aufgaben automatisiert. Dies macht die Ausführung des Prozesses einfacher und zuverlässiger.

Das Script liegt in der Version 3 vor und kann unter dem Namen physru_v3.sh über das Dokument 949322.1 heruntergeladen werden.

physru_v3.sh:
Das Shell Skript mit dem Namen physru_v3.sh führt ein Upgrade für die Oracle RDBMS-Versionen 11gR1 und höher in einer DataGuard Umgebung aus, wobei die physische Standby Datenbank temporär als logische Standby Datenbank betrieben wird. Ein solches Upgrade umfasst normalerweise zahlreiche SQL-Operationen und -Validierungen. Das Physru-Skript reduziert die Anzahl der Schritte erheblich und lässt dem Benutzer die folgenden verbleibenden Schritte:

Aufrufen von DBUA oder catupgrd.sql, um die (logische!) Standby-Datenbank zu aktualisieren.

Starten der aktualisierten Standby-Datenbank im neuen Oracle-Home.
Starten der ehemaligen Primärdatenbank im neuen Oracle-Home.
Starten und Stoppen von RAC-Instanzen.
Deaktivieren und Aktivieren von RAC.

Das Physru-Skript muss konstruktionsbedingt insgesamt dreimal aufgerufen werden, um das rollende Upgrade abzuschließen.
Wenn das Skript einen Punkt erreicht, an dem ein Eingriff erforderlich ist, benachrichtigt es den Benutzer darüber, welcher der oben genannten Schritte auszuführen ist. Nach Abschluss des jeweiligen Benutzervorgangs muss der Benutzer das Skript erneut aufrufen, um das fortlaufende Upgrade fortzusetzen. Hierbei ist jeweils die exakt gleiche Parametrisierung erforderlich. Das Skript “merkt” sich jeweils, in welchem Schritt es sich befindet.
Sollte ein Fehler auftreten, gibt das Skript einen Fehlerkontext aus, um die Fehlerbehebung bei der Unterbrechung des parallelen Upgrades zu unterstützen.
Nachdem alle Probleme behoben wurden, kann das Skript erneut aufgerufen werden, um an der Stelle der Unterbrechung fortzusetzen.
Physru unterstützt sowohl RAC- als auch Single-Instance-Datenbanken in beliebiger Kombination.

Da Logical Standby Datenbanken auf den Fähigkeiten des LogMiners beruhen, werden bestimmte Datentypen nicht unterstützt. Oracle stellt hier eine spezielle View mit dem Namen DBA_LOGSTDBY_UNSUPPORTED bereit. Die View zeigt Schemas, Tabellen und Tabellenspalten an, die nicht unterstützte Datentypen enthalten.

Fragen wir die Objekte ab, die Probleme bereiten:

SQL> select owner,table_name,column_name,attributes,data_type from
dba_logstdby_unsupported order by 1,2,3; 

no rows selected

Wenn die Primärdatenbank nicht kompatible Objekte enthält, schließt der Log Apply Dienst diese Objekte automatisch aus, während die übrigen Redo-Operationen auf der logischen Standby-Datenbank angewandt werden.

Eine logische Standby-Datenbank kann keine Aktualisierungen für die folgenden Objekte akzeptieren:

Tabellen oder Sequenzen die SYS gehören
Tabellen die Tabellenkomprimierung verwenden
Tabellen die einer Materialized View zugrunde liegen
Globale temporäre Tabellen (GTTs)

Darüber hinaus können Tabellen, die die folgenden nicht unterstützten Datentypen verwenden, nicht mit dem hier beschriebenen Verfahren aktualisiert werden:

Datentypen BFILE, ROWID und UROWID
Benutzerdefinierte Typen
Multimedia-Datentypen wie Oracle Spatial, ORDDICOM und Oracle Text
Sammlungen (z. B. verschachtelte Tabellen, VARRAYs)
SecureFile-LOBs
OBJECT RELATIONAL XML Typen
BINARY XMLs

Wenn unsere Datenbank solche Objekte enthält, muss man die Objekte prüfen. Sind keine Änderungen möglich, muss gegebenenfalls eine andere Upgrade-Methode ausgewählt werden.

Prüfen wir das Redo Apply:

SQL> select DEST_ID,dest_name,status,type,srl,recovery_mode
from v$archive_dest_status where dest_id=2;  2

   DEST_ID DEST_NAME                                STATUS    TYPE             SRL RECOVERY_MODE
---------- ---------------------------------------- --------- ---------------- --- ----------------------------------
         2 LOG_ARCHIVE_DEST_2                       VALID     PHYSICAL         YES MANAGED REAL TIME APPLY

Die Standby-Datenbank muss entweder im Maximum Availability oder im Maximum Protection Modus sein. Unsere Konfiguration war in Maximum Performance, sodass auf Maximum Availability umgeschaltet wird.

DataGuard

Mit DataGuard ist es möglich, sämtliche Datenänderungen an eine räumlich getrennte Datenbank zu senden. Diese kann dann geplant (Switchover) oder bei einem Ausfall der Primärdatenbank (Failover) den Betrieb übernehmen.
Eine DataGuard-Konfiguration läuft immer in einem von drei Datenschutz-Modi (auch Redo-Transportregeln genannt). Alle drei Modi bieten ein hohes Maß an Datenschutz - unterscheiden sich jedoch in Bezug auf die Auswirkungen, die jeder auf die Verfügbarkeit und Leistung der primären Datenbank hat.

Maximum Protection

Dieser Schutzmodus garantiert, dass kein Datenverlust auftritt, wenn die primäre Datenbank ausfällt. Um dieses Schutzniveau bereitzustellen, müssen die Redo-Daten, die zur Wiederherstellung jeder Transaktion benötigt werden, sowohl in das lokale Online-Redo-Log als auch in ein Standby-Redo-Log in mindestens einer Standby-Datenbank geschrieben worden sein, bevor die Transaktion festgeschrieben wird. Um sicherzustellen, dass kein Datenverlust auftritt, wird die primäre Datenbank heruntergefahren, wenn ein Fehler sie daran hindert, ihren Redo-Stream in mindestens eine synchronisierte Standby-Datenbank zu schreiben.

Maximum Availability

Dieser Schutzmodus bietet den höchstmöglichen Datenschutz, ohne die Verfügbarkeit der primären Datenbank zu beeinträchtigen. Wie im Maximum Protection Modus werden Transaktionen erst festgeschrieben, wenn alle für die Wiederherstellung dieser Transaktionen erforderlichen Redo-Daten in das Online-Redo-Log und in mindestens eine synchronisierte Standby-Datenbank geschrieben wurden. Im Gegensatz zum Maximum Protection Modus wird die primäre Datenbank nicht heruntergefahren, wenn ein Fehler sie daran hindert, ihren Redo-Stream in eine synchronisierte Standby-Datenbank zu schreiben. Stattdessen arbeitet die primäre Datenbank in RESYNCHRONIZATION, bis der Fehler behoben ist und alle Protokolllücken behoben wurden. Sobald dies der Fall ist, nimmt die primäre Datenbank automatisch den Betrieb im Modus mit maximaler Verfügbarkeit wieder auf.

Maximum Performance

Dieser Schutzmodus bietet den höchstmöglichen Datenschutz, ohne die Leistung der primären Datenbank zu beeinträchtigen. Dies wird erreicht, indem zugelassen wird, dass eine Transaktion festgeschrieben wird, sobald die Redo-Daten, die zum Wiederherstellen dieser Transaktion erforderlich sind, in das lokale Redo-Protokoll geschrieben werden. Der Redo-Datenstrom der primären Datenbank wird auch in mindestens eine Standby-Datenbank geschrieben, aber dieser Redo-Stream wird asynchron in Bezug auf die Festschreibung der Transaktionen geschrieben, die die Redo-Daten erstellen.
Wenn Netzwerkverbindungen mit ausreichender Bandbreite und Latenz verwendet werden, bietet dieser Modus ein Datenschutzniveau, das sich dem des Modus mit maximaler Verfügbarkeit annähert, mit minimalen Auswirkungen auf die Leistung der primären Datenbank.

Um Maximum Availability einzuschalten, muss auf beiden Datenbanken der DataGuard Parameter Logxptmode auf SYNC eingestellt werden.

LogXptMode

Der Redo-Log-Transport von Oracle DataGuard bietet synchronen und asynchronen Log-Transportmodus. Der Unterschied besteht darin, wann das COMMIT stattfindet.

LogXptMode = (‘SYNC‘): Wie der Name schon sagt, synchronisiert der SYNC-Modus die primäre mit der Standby-Datenbank und alle DML auf dem primären Server werden NICHT festgeschrieben, bis die Protokolle erfolgreich zu den Standby-Servern transportiert wurden. Der synchrone Protokolltransportmodus ist für die Datenschutzmodi Maximum Protection und Maximum Availability erforderlich.
LogXptMode = (‘ASYNC‘): Umgekehrt ermöglicht der asynchrone Modus (ASYNC), dass Updates (DML) auf dem primären Server festgeschrieben werden, bevor die Protokolldatei auf den Standby-Servern ankommt. Der asynchrone Protokolltransportmodus ist für den Datenschutzmodus Maximum Performance erforderlich.

dgmgrl /
DGMGRL> EDIT DATABASE "ODB01P" SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated
DGMGRL> EDIT DATABASE "ODB01PR" SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated

Schließlich Konfiguration auf Maximum Availability umschalten

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
Succeeded.

Danach prüfen wir den Status der Standby-DB:

DGMGRL> show database verbose "ODB01PR"

Database - ODB01PR

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 0 seconds ago)
  Apply Lag:          0 seconds (computed 0 seconds ago)
  Average Apply Rate: 21.00 KByte/s
  Active Apply Rate:  1.29 MByte/s
  Maximum Apply Rate: 1.59 MByte/s
  Real Time Query:    OFF
  Instance(s):
    ODB01PR

Flashback muss auf beiden Seiten (Primary und Standby) eingeschaltet sein:

SQL> SELECT FLASHBACK_ON FROM V$DATABASE;

FLASHBACK_ON
------------------
NO

SQL> alter database flashback on;

Database altered.

SQL> SELECT FLASHBACK_ON FROM V$DATABASE;

FLASHBACK_ON
------------------
YES

Standby File Management soll auf beiden Seiten (Primary und Standby) auf auto gestellt sein:

SQL> show parameter standby_file_management

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
standby_file_management              string      AUTO

Der DataGuard Broker muss während der Verwendung des physru-Skripts beendet werden.

alter system set dg_broker_start=false;

Natürlich soll die Primary Datenbank geöffnet und im Read-Write Modus stehen:

SQL> select status from v$instance;

STATUS
------------
OPEN

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB01                          READ WRITE NO

Die Standby-DB bleibt im Mount-Status:

SQL> select status from v$instance;

STATUS
------------
MOUNTED

Ausführung

Schritt 1 - Erste Physru Skript Ausführung
Nachdem wir die nötigen Checks durchgeführt haben, können wir das physru_v3.sh Skript zum ersten mal starten.

Was macht das Skript?
Im ersten Aufruf führt das Skript folgende Aktionen durch:

Stage 0 - Prechecks
Stage 1 - Erstellen eines Backups und eines Restore Punkts
Stage 2 - Konvertierung des physischen Standby-DB in eine logische

Das Skript braucht folgende Parameter zum starten:

username = hier sollte der User sys verwendet werden
primary_tns = tns-Dienstname der primären Datenbank
standby_tns = tns-Dienstname der Standby-DB
primary_name = db_unique_name primären Datenbank
standby_name = db_unique_name der Standby-DB
upgrade_version = Version der Ziel-Instanz

./physru_v3.sh sys ODB01P ODB01PR ODB01P ODB01PR 19.0.0.0
Please enter the sysdba password:

### Initialize script to either start over or resume execution
Mar 30 09:47:57 2023 [0-1] Identifying rdbms software version
Mar 30 09:47:57 2023 [0-1] database ODB01P is at version 12.2.0.1.0
Mar 30 09:47:58 2023 [0-1] database ODB01PR is at version 12.2.0.1.0
Mar 30 09:47:59 2023 [0-1] verifying fast recovery area is enabled at ODB01P and ODB01PR
Mar 30 09:47:59 2023 [0-1] verifying backup location at ODB01P and ODB01PR
Mar 30 09:48:00 2023 [0-1] verifying available flashback restore points
Mar 30 09:48:00 2023 [0-1] verifying DG Broker is disabled
Mar 30 09:48:01 2023 [0-1] looking up prior execution history
Mar 30 09:48:01 2023 [0-1] purging script execution state from database ODB01P
Mar 30 09:48:01 2023 [0-1] purging script execution state from database ODB01PR
Mar 30 09:48:02 2023 [0-1] starting new execution of script

### Stage 1: Backup user environment in case rolling upgrade is aborted
Mar 30 09:48:02 2023 [1-1] database ODB01P location for backup controlfile is /fra/ODB01P
Mar 30 09:48:02 2023 [1-1] database ODB01PR location for backup controlfile is /fra/ODB01PR
Mar 30 09:48:02 2023 [1-1] creating restore point PRU_0000_0003 on database ODB01PR
Mar 30 09:48:03 2023 [1-1] backing up current control file on ODB01PR
Mar 30 09:48:03 2023 [1-1] created backup control file /fra/ODB01PR/PRU_0003_ODB01PR_f.f
Mar 30 09:48:03 2023 [1-1] creating restore point PRU_0000_0003 on database ODB01P
Mar 30 09:48:04 2023 [1-1] backing up current control file on ODB01P
Mar 30 09:48:04 2023 [1-1] created backup control file /fra/ODB01P/PRU_0003_ODB01P_f.f

NOTE: Restore point PRU_0000_0001 and backup control file PRU_0003_ODB01PR_f.f
      can be used to restore ODB01PR back to its original state as a
      physical standby, in case the rolling upgrade operation needs to be aborted
      prior to the first switchover done in Stage 4.

### Stage 2: Create transient logical standby from existing physical standby
Mar 30 09:48:05 2023 [2-1] verifying RAC is disabled at ODB01PR
Mar 30 09:48:05 2023 [2-1] verifying database roles
Mar 30 09:48:05 2023 [2-1] verifying physical standby is mounted
Mar 30 09:48:06 2023 [2-1] verifying database protection mode
Mar 30 09:48:06 2023 [2-1] verifying transient logical standby datatype support
Mar 30 09:48:08 2023 [2-2] starting media recovery on ODB01PR
Mar 30 09:48:15 2023 [2-2] confirming media recovery is running
Mar 30 09:48:15 2023 [2-2] waiting for apply lag to fall under 30 seconds
Mar 30 09:48:21 2023 [2-2] apply lag measured at 5 seconds
Mar 30 09:48:22 2023 [2-2] stopping media recovery on ODB01PR
Mar 30 09:48:24 2023 [2-2] executing dbms_logstdby.build on database ODB01P
Mar 30 09:48:36 2023 [2-2] converting physical standby into transient logical standby
Mar 30 09:48:42 2023 [2-3] opening database ODB01PR
Mar 30 09:48:47 2023 [2-4] configuring transient logical standby parameters for rolling upgrade
Mar 30 09:48:48 2023 [2-4] starting logical standby on database ODB01PR
Mar 30 09:48:50 2023 [2-4] enabling log archive destination to database ODB01PR
Mar 30 09:48:50 2023 [2-4] waiting until logminer dictionary has fully loaded
Mar 30 09:49:13 2023 [2-4] dictionary load 62% complete
Mar 30 09:49:23 2023 [2-4] dictionary load 99% complete

Wenn unsere Pluggable Datenbank auf der Standby Seite nicht automatisch startet - weil in der physischen Standby DB der Mount Status für die PDB gespeichert wurde - werden wir am ende bei 99% stecken bleiben und nach 30 Minuten einen Timeout erhalten.

Mar 27 10:19:24 2023 [2-4] ERROR: timed out after 30 minutes of inactivity

Das ist aber kein Problem, dafür starten wir die Pluggable-DB auf der Standby Seite:

alter pluggable database PDB01 open;

Wir müssen das Timeout nicht abwarten, sondern können das Skript vorzeitig beenden und erneut starten. Es wird merken, dass der letzte Lauf entweder fehlgeschlagen ist oder der Benutzer es abgebrochen hat und fragt nach, wie wir weiter vorgehen möchten. Hierbei stehen die folgenden Möglichkeiten zur Verfügung:

Fortsetzen des Upgrade von dort, wo die letzte Ausführung aufgehört hat
Von vorne starten
Skript beenden

Wir wählen 1 und das Skript macht weiter wo es zuletzt aufgehört hat:

### Initialize script to either start over or resume execution
Mar 30 10:26:20 2023 [0-1] Identifying rdbms software version
Mar 30 10:26:20 2023 [0-1] database ODB01P is at version 12.2.0.1.0
Mar 30 10:26:20 2023 [0-1] database ODB01PR is at version 12.2.0.1.0
Mar 30 10:26:22 2023 [0-1] verifying fast recovery area is enabled at ODB01P and ODB01PR
Mar 30 10:26:22 2023 [0-1] verifying backup location at ODB01P and ODB01PR
Mar 30 10:26:23 2023 [0-1] verifying available flashback restore points
Mar 30 10:26:23 2023 [0-1] verifying DG Broker is disabled
Mar 30 10:26:24 2023 [0-1] looking up prior execution history
Mar 30 10:26:24 2023 [0-1] last completed stage [2-3] using script version 0003

WARN: The last execution of this script either exited in error or at the
      user's request.  At this point, there are three available options:

        1) resume the rolling upgrade where the last execution left off
        2) restart the script from scratch
        3) exit the script

      Option (2) assumes the user has restored the primary and physical
      standby back to the original configuration as required by this script.

Enter your selection (1/2/3): 1

Mar 30 10:26:29 2023 [0-1] resuming execution of script
Mar 30 10:26:29 2023 [2-4] verifying RAC is disabled at ODB01PR
Mar 30 10:26:30 2023 [2-4] configuring transient logical standby parameters for rolling upgrade
Mar 30 10:26:31 2023 [2-4] starting logical standby on database ODB01PR
Mar 30 10:26:32 2023 [2-4] enabling log archive destination to database ODB01PR
Mar 30 10:26:32 2023 [2-4] waiting until logminer dictionary has fully loaded
Mar 30 10:26:33 2023 [2-4] dictionary already loaded
Mar 30 10:26:34 2023 [2-4] waiting for apply lag to fall under 30 seconds
Mar 30 10:26:46 2023 [2-4] apply lag measured at 11 seconds

NOTE: Database ODB01PR is now ready to be upgraded.  This script has left the
      database open in case you want to perform any further tasks before
      upgrading the database.  Once the upgrade is complete, the database must
      opened in READ WRITE mode before this script can be called to resume the
      rolling upgrade.

NOTE: If ODB01PR was previously a RAC database that was disabled, it may be
      reverted back to a RAC database upon completion of the rdbms upgrade.
      This can be accomplished by performing the following steps:

          1) On instance ODB01PR, set the cluster_database parameter to TRUE.
          eg: SQL> alter system set cluster_database=true scope=spfile;

          2) Shutdown instance ODB01PR.
          eg: SQL> shutdown abort;

          3) Startup and open all instances for database ODB01PR.
          eg: srvctl start database -d ODB01PR

Wir können nun schauen was das Skript mit unserer physischen Standby-DB angestellt hat:

SQL> select name, db_unique_name, database_role, protection_mode, open_mode from v$database;

NAME      DB_UNIQUE_NAME                DATABASE_ROLE    PROTECTION_MODE      OPEN_MODE
--------- ----------------------------- ---------------- -------------------- ---------------
ODB01P    ODB01PR                       LOGICAL STANDBY  MAXIMUM AVAILABILITY READ WRITE

Die physische wurde in eine logische Standby-DB umgewandelt und wie das Skript schon ausgegeben hat, ist die Standby-DB bereit für das Upgrade. Währenddessen läuft unsere Primary Instanz aktiv weiter.

Schritt 2 - Upgrade der logischen Standby-DB

Das Upgrade kann manuell oder mittels dbua erfolgen. Wir werden dbua benutzen.

cd /u01/app/oracle/product/19.0.0.0/dbhome_1/bin/
./dbua

Wählen wir unsere Datenbank aus und verwenden wir User und Passwort des SYS Users:

Im zweiten Schritt wählen wir die PDB aus

Der Upgrade Assistent führt nun die PreUpgrade Checks durch. Wir prüfen und beheben die Fehlermeldungen die mit manual gekennzeichnet sind. Danach können wir mit Fix & Check Again die Checks erneut durchführen und mit Next weiter gehen.

Bei den Upgrade Optionen können die Standard Werte bleiben und wir fahren mit Next fort.

In Schritt 5 können wir die Recovery Optionen einstellen, wobei wir zwischen Flashback, vom Upgrade durchzuführendes RMAN-Backup oder einem bereits zuvor erstellten Backup auswählen können. Im Fall von Flashback kann ein bereits existierender oder ein neuer Restore-Point spezifiziert werden.

Auf Einzelinstanzsystemen kann man entweder einen vorhandenen Listener auswählen oder einen neuen Listener erstellen. Wenn ein neuer Listener erstellt werden soll, muss man den Listener-Namen und eine Portnummer für den Listener angeben. In diesem Fall müsste die Tnsnames Datei aber auf beiden Seiten entsprechend geändert werden. Wählen wir den Listener aus und drücken auf Next.

Wir konfigurieren bei Bedarf OEM später separat, deshalb lassen wir das OEM Setup hier aus.

Im nächsten schritt des Upgrade Assistenten erhalten wir die Zusammenfassung:

Danach startet das Upgrade mit dem Finish Button und es wird eine Seite angezeigt, auf der die Upgrade-Aktivitäten bzw. deren Status angezeigt werden.

Abschließend erhalten wir die Ergebnisse des Upgrades:

Das gesamte Upgrade hat ca. eine Stunde gedauert. In den Resultaten kann man sich die Dauer der jeweiligen Schritte ansehen.

Das gesamte Upgrade hat ca. eine Stunde gedauert. Damit ist unsere Standby-DB auf 19c aktualisiert.

Schritt 3 - Physru Skript zweiter Lauf

Nachdem unsere Standby-DB auf die Zielversion aktualisiert wurde, können wir das physru Skript zum 2 mal starten. Das Skript führt einen Switchover durch. Hierbei werden wir für die Dauer des Umschaltvorgangs eine kleine Unterbrechung haben, aber die meisten Applikationen merken das nicht einmal.

Was macht das Skript?

Im zweiten Aufruf macht das Skript folgendes:

Stage 0 - Prechecks
Stage 3 - Validiert und prüft die logische Standby-DB mit der neuen Version
Stage 4 - Switchover auf die logische Standby-DB. Damit wird diese zur neuen Primary
Stage 5 - Die alte Primary-DB wird auf den PreUpgrade Restore Punkt zurückgestellt und in eine physische Standby-DB konvertiert. Damit befinden sich die Daten der ehemaligen Primärdatenbank jetzt wieder im gleichen Status, wie zum Zeitpunkt des ersten physru-Aufrufs. Die während des Upgrades erfolgten Datenänderungen befinden sich in der ehemaligen Standby-DB.

[oracle@ora1 ~]$ ./physru_v3.sh sys ODB01P ODB01PR ODB01P ODB01PR 19.0.0.0.0
Please enter the sysdba password:

### Initialize script to either start over or resume execution
Mar 30 11:26:33 2023 [0-1] Identifying rdbms software version
Mar 30 11:26:33 2023 [0-1] database ODB01P is at version 12.2.0.1.0
Mar 30 11:26:33 2023 [0-1] database ODB01PR is at version 19.0.0.0.0
Mar 30 11:26:35 2023 [0-1] verifying fast recovery area is enabled at ODB01P and ODB01PR
Mar 30 11:26:35 2023 [0-1] verifying backup location at ODB01P and ODB01PR
Mar 30 11:26:36 2023 [0-1] verifying available flashback restore points
Mar 30 11:26:36 2023 [0-1] verifying DG Broker is disabled
Mar 30 11:26:37 2023 [0-1] looking up prior execution history
Mar 30 11:26:37 2023 [0-1] last completed stage [2-4] using script version 0003
Mar 30 11:26:37 2023 [0-1] resuming execution of script

### Stage 3: Validate upgraded transient logical standby
Mar 30 11:26:38 2023 [3-1] database ODB01PR is no longer in OPEN MIGRATE mode
Mar 30 11:26:38 2023 [3-1] database ODB01PR is at version 19.0.0.0.0

### Stage 4: Switch the transient logical standby to be the new primary
Mar 30 11:26:40 2023 [4-1] waiting for ODB01PR to catch up (this could take a while)
Mar 30 11:26:40 2023 [4-1] starting logical standby on database ODB01PR
Mar 30 11:26:42 2023 [4-1] waiting for apply lag to fall under 30 seconds
Mar 30 11:27:28 2023 [4-1] apply lag measured at 44 seconds
Mar 30 11:27:39 2023 [4-1] apply lag measured at 6 seconds
Mar 30 11:27:41 2023 [4-2] using fast switchover optimizations

NOTE: A switchover is about to be performed which will incur a brief outage
      of the primary database.  If you answer 'y' to the question below,
      database ODB01PR will become the new primary database, and database ODB01P
      will be converted into a standby in preparation for upgrade.  If you answer
      'n' to the question below, the script will exit, leaving the databases in
      their current roles.
Are you ready to proceed with the switchover? (y/n): y

Mar 30 11:27:48 2023 [4-2] continuing
Mar 30 11:27:48 2023 [4-2] switching ODB01P to become a logical standby
Mar 30 11:27:53 2023 [4-2] ODB01P is now a logical standby
Mar 30 11:27:53 2023 [4-2] waiting for standby ODB01PR to process end-of-redo from primary
Mar 30 11:27:55 2023 [4-2] switching ODB01PR to become the new primary
Mar 30 11:27:56 2023 [4-2] ODB01PR is now the new primary

### Stage 5: Flashback former primary to pre-upgrade restore point and convert to physical
Mar 30 11:27:58 2023 [5-1] shutting down database ODB01P
Mar 30 11:28:24 2023 [5-1] mounting database ODB01P
Mar 30 11:28:32 2023 [5-2] flashing back database ODB01P to restore point PRU_0000_0003
Mar 30 11:28:37 2023 [5-3] converting ODB01P into physical standby
Mar 30 11:28:38 2023 [5-4] shutting down database ODB01P

NOTE: Database ODB01P has been shutdown, and is now ready to be started
      using the newer version Oracle binary.  This script requires the
      database to be mounted (on all active instances, if RAC) before calling
      this script to resume the rolling upgrade.

Das Skript weist darauf hin, dass die alte Primary-DB abeschaltet wurde und wir können sie nun im neuen Homeverzeichnis starten. Dazu müssen wir zuvor die Passwort-Datei und das Spfile der alten Version in das neue Homeverzeichnis kopieren.

[oracle@ora1 ~]$ cp /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/orapwODB01P /u01/app/oracle/product/19.0.0.0/dbhome_1/dbs/orapwODB01P
[oracle@ora1 ~]$ cp /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/spfileODB01P.ora /u01/app/oracle/product/19.0.0.0/dbhome_1/dbs/spfileODB01P.ora
[oracle@ora1 ~]$ export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_1
[oracle@ora1 ~]$ export ORACLE_SID=ODB01P
[oracle@ora1 dbs]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Mar 30 11:27:03 2023
Version 19.17.0.0.0

Copyright (c) 1982, 2022, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup mount
ORACLE instance started.

Total System Global Area 4.0265E+10 bytes
Fixed Size                 23302880 bytes
Variable Size            4697620480 bytes
Database Buffers         3.5433E+10 bytes
Redo Buffers              110911488 bytes
Database mounted.

Fragen wir den Status ab:

SQL> select name,dbid,database_role from v$database;

NAME            DBID DATABASE_ROLE
--------- ---------- ----------------
ODB01P    2695615138 PHYSICAL STANDBY

Schritt 4 - Physru Skript dritter Lauf

Beim dritten Aufruf des Skripts werden die Änderungen der neuen Primary-DB in die neue Standby-DB geschrieben. Abschließend fragt das Skript nach, ob die Rollen der DB wieder ausgetauscht werden sollen, sodass die ursprüngliche Primary-DB und Standby-DB wieder als Primary-DB bzw. Standby-DB betrieben werden. Es ist nicht zwingend erforderlich, einen weiteren Switchover durchzuführen, wenn man die Ausfallzeiten auf einem absoluten Minimum halten möchte.

Wenn man mit N antwortet, bleibt ODB01P die physische Standby-DB und ODB01PR die Primary-DB.

Zu Demonstrationszwecken antworten wir jedoch mit yes (y), sodass wir den Originalzustand, das heißt die Primary-DB auf dem Primary Host und die Standby-DB auf der Standby-Seite haben. Unabhängig von unserer Antwort laufen jetzt aber beide Instanzen in der neuen 19c Umgebung.

Was macht das Skript?

Im dritten Aufruf macht das Skript folgendes:

Stage 0 - Prechecks
Stage 6 - Ausführung des Media Recovery ab dem anfangs gesetzten Restore-Point. Hierbei erhält die neue Standby-DB die Katalog-Updates und die während des Updates durchgeführten Benutzertransaktionen aus der neuen Primary-DB
Stage 7 - Switchback (optional)

[oracle@ora1 ~]$ ./physru_v3.sh sys ODB01P ODB01PR ODB01P ODB01PR 19.0.0.0.0
Please enter the sysdba password:

### Initialize script to either start over or resume execution
Mar 30 11:29:59 2023 [0-1] Identifying rdbms software version
Mar 30 11:29:59 2023 [0-1] database ODB01P is at version 19.0.0.0.0
Mar 30 11:29:59 2023 [0-1] database ODB01PR is at version 19.0.0.0.0
Mar 30 11:30:01 2023 [0-1] verifying fast recovery area is enabled at ODB01P and ODB01PR
Mar 30 11:30:01 2023 [0-1] verifying backup location at ODB01P and ODB01PR
Mar 30 11:30:02 2023 [0-1] verifying available flashback restore points
Mar 30 11:30:02 2023 [0-1] verifying DG Broker is disabled
Mar 30 11:30:03 2023 [0-1] looking up prior execution history
Mar 30 11:30:03 2023 [0-1] last completed stage [5-4] using script version 0003
Mar 30 11:30:03 2023 [0-1] resuming execution of script

### Stage 6: Run media recovery through upgrade redo
Mar 30 11:30:06 2023 [6-1] upgrade redo region identified as scn range [12304942, 15486381]
Mar 30 11:30:06 2023 [6-1] enabling log archive destination to database ODB01P
Mar 30 11:30:07 2023 [6-1] starting media recovery on ODB01P
Mar 30 11:30:20 2023 [6-1] confirming media recovery is running
Mar 30 11:30:20 2023 [6-1] waiting for media recovery to initialize v$recovery_progress
Mar 30 11:31:27 2023 [6-1] monitoring media recovery's progress
Mar 30 11:31:29 2023 [6-3] recovery of upgrade redo at 07% - estimated complete at Mar 30 11:34:20
Mar 30 11:31:46 2023 [6-3] recovery of upgrade redo at 18% - estimated complete at Mar 30 11:33:59
Mar 30 11:32:02 2023 [6-3] recovery of upgrade redo at 26% - estimated complete at Mar 30 11:34:18
Mar 30 11:32:19 2023 [6-3] recovery of upgrade redo at 31% - estimated complete at Mar 30 11:34:36
Mar 30 11:32:35 2023 [6-3] recovery of upgrade redo at 51% - estimated complete at Mar 30 11:33:51
Mar 30 11:32:52 2023 [6-3] recovery of upgrade redo at 69% - estimated complete at Mar 30 11:33:33
Mar 30 11:33:08 2023 [6-3] recovery of upgrade redo at 78% - estimated complete at Mar 30 11:33:40
Mar 30 11:33:24 2023 [6-4] media recovery has finished recovering through upgrade

### Stage 7: Switch back to the original roles prior to the rolling upgrade

NOTE: At this point, you have the option to perform a switchover
     which will restore ODB01P back to a primary database and
     ODB01PR back to a physical standby database.  If you answer 'n'
     to the question below, ODB01P will remain a physical standby
     database and ODB01PR will remain a primary database.

Do you want to perform a switchover? (y/n): y

Mar 30 11:34:32 2023 [7-1] continuing
Mar 30 11:34:34 2023 [7-2] waiting for apply lag to fall under 30 seconds
Mar 30 11:34:35 2023 [7-2] apply lag measured at 1 seconds
Mar 30 11:34:37 2023 [7-3] switching ODB01PR to become a physical standby
Mar 30 11:34:49 2023 [7-3] ODB01PR is now a physical standby
Mar 30 11:35:50 2023 [7-3] shutting down database ODB01PR
Mar 30 11:36:08 2023 [7-3] mounting database ODB01PR
Mar 30 11:36:19 2023 [7-3] starting media recovery on ODB01PR
Mar 30 11:36:25 2023 [7-3] confirming media recovery is running
Mar 30 11:36:25 2023 [7-3] waiting for standby ODB01P to process end-of-redo from primary
Mar 30 11:36:06 2023 [7-3] switching ODB01P to become the new primary
Mar 30 11:36:06 2023 [7-3] ODB01P is now the new primary
Mar 30 11:36:06 2023 [7-3] opening database ODB01P

### Stage 8: Statistics
script start time:                                           30-Mar-23 09:47:57
script finish time:                                          30-Mar-23 11:36:06
total script execution time:                                       +00 01:48:09
wait time for user upgrade:                                        +00 01:02:51
active script execution time:                                      +00 00:41:17
transient logical creation start time:                       30-Mar-23 09:47:52
transient logical creation finish time:                      30-Mar-23 09:48:27
primary to logical switchover start time:                    30-Mar-23 11:27:41
logical to primary switchover finish time:                   30-Mar-23 11:27:56
primary services offline for:                                      +00 00:00:15
total time former primary in physical role:                        +00 00:07:25
time to reach upgrade redo:
time to recover upgrade redo:                                      +00 00:01:57
primary to physical switchover start time:                   30-Mar-23 11:34:36
physical to primary switchover finish time:                  30-Mar-23 11:35:06
primary services offline for:                                      +00 00:00:30

SUCCESS: The physical rolling upgrade is complete

Fazit

Wir haben ein Upgrade durchgeführt und das laut Skriptausgaben mit lediglich 15 Sekunden Ausfallzeit für den Switchover und 30 Sekunden Ausfallzeit für den Switchback, was mit herkömmlichen Upgrade Methoden nicht erreichbar ist. Das hier dargestellte Verfahren des Transient Logical Upgrade hat jedoch auch seine Nachteile, welche wir am Anfang des Artikels erwähnt haben.

Welchen Upgrade-Weg wir nehmen, hängt von unserer Konfiguration ab. In jedem Fall sollte dieses Verfahren im Vorfeld ausgiebig mit einer Konfiguration getestet werden, die der Produktivumgebung möglichst ähnlich ist. Wir empfehlen hier den Aufbau einer Testumgebung mit einer exakten Kopie der Produktion.

Gerne stehen Ihnen rund um das Thema Oracle und dazugehörige Upgrades unsere Experten zur Seite und helfen Ihnen gerne mit Best Practices und Optimierungslösungen weiter. Kontaktieren Sie uns dafür gerne unverbindlich über unser Kontaktformular. Wir freuen uns von Ihnen zu hören.