Oracle empfiehlt mittlerweile das Out-of-Place-Patching, aber wie genau funktioniert das ganze? In diesem Blogbeitrag werden die Schritte und der Prozess des Out-of-Place-Patchings erläutert.
Datenbankugebung
Bevor wir starten hier eine kurze Übersicht zur Datenbankumgebung. Wir haben als Beispiel ein Oracle Base Release, also Oracle 19.3.0 mit 3 CDB’s (CDB_A, CDB_B und CDB_C).
Außerdem haben wir ein Real Application Cluster (RAC) mit 2 Knoten (Server 1 „rzk01“ und Server 2 „rzk02“), die in einem Rechenzentrum in Köln laufen. Die Datenbanken laufen also gleichzeitig auf Server 1 und 2, sodass wir eine Hochverfügbarkeit sicherstellen, falls einer der Server ausfallen sollte. Zudem ermöglicht dies eine Lastverteilung, da nicht alle Aktivitäten ausschließlich auf einem Server in der Datenbank stattfinden.
Neben dem Haupt-Rechenzentrum in Köln gibt es ein zusätzliches Rechenzentrum in Leverkusen. In Leverkusen läuft die Datenbank im Standby-Modus, während in Köln die aktive Primary-Datenbank betrieben wird. Dank Oracle Data Guard haben wir eine effektive Desaster-Recovery-Lösung implementiert. Wenn das Rechenzentrum in Köln ausfällt, kann das Rechenzentrum in Leverkusen als Primary-Datenbank übernehmen und den Betrieb ohne Unterbrechung fortsetzen. So gewährleisten wir eine schnelle Wiederherstellung und maximale Verfügbarkeit unserer Daten.
Ziel
Unser Ziel ist nun diese Datenbankumgebung von 19 auf 19.22 zu patchen.
1. Golden Image
Zu aller erst muss der neue Patch auf der my oracle support Seite heruntergeladen werden. In unserem Fall der 19.22 Patch. Wichtig ist hier das GI Update zu wählen, da wir eine Grid Infrastructure haben, die ebenfalls gepatched werden muss
Anschließend patchen wir ein Grid und ein Oracle Home, am besten auf einer Testumgebung und erstellen davon ein Golden Image, damit wir das für die Produktionsumgebung weiterverwenden können.
1. GI Home Patchen
User grid:
cd /u01/app/grid/product/19/gridhome
cd $ORACLE_HOME
rm -rf OPatch/*
unzip /u05/orashare/software/opatch/p6880880_12201032_Linux-x86-64.zip
cd Patch/RU240116/35943157
$ORACLE_HOME/Opatch/opatchauto apply -analyze
Wenn analyse successful ist, -analyze weglassen und apply
$ORACLE_HOME/Opatch/opatchauto apply
Gold Image erstellen:
./gridSetup.sh -createGoldImage -destinationLocation /u05/orashare/software/Gold –silent
/u05/orashare/software/Gold/grid_home_2024-01-23_01-21-09PM.zip
2. DB Home Patchen
cd /u01/app/oracle/product/19/dbhome_1
cd $ORACLE_HOME
rm -rf OPatch/*
unzip /u05/orashare/software/opatch/p6880880_12201032_Linux-x86-64.zip
cd Patch/RU240116/35943157
$ORACLE_HOME/Opatch/opatchauto apply -analyze
Wenn analyse successful ist, -analyze weglassen und apply
$ORACLE_HOME/Opatch/opatchauto apply
Gold Image erstellen:
./runInstaller -createGoldImage -destinationLocation /u05/orashare/software/Gold –silent
/u05/orashare/software/Gold/db_home_2024-01-23_11-53-25AM.zip
2. HOmes Patchen
Leverkusen läuft im standby darum fangen wir damit am besten an. Wenn da was schief gehen sollte haben wir immernoch die primary seite in Köln.
Auf beiden Servern im RAC in Leverkusen rzl01 und rzl02:
root:
mkdir -p /u01/app/grid/product/19.22/gridhome
chown -R grid:oinstall /u01/app/grid/product/19.22
Nur auf rzl01:
grid:
cd /u01/app/grid/product/19.22/gridhome
export ORACLE_HOME=`pwd`
unzip /u05/orashare/software/Gold/grid_home_2024-01-23_01-21-09PM.zip
2.1 Vorbereitung GridSetup
$ORACLE_HOME/gridSetup.sh -executePrereqs -silent
export ORACLE_BASE=/u01/app/gridbase
export ORA_INVENTORY=/u01/app/oraInventory
export CLUSTER_NAME=$(olsnodes -c)
export CLUSTER_NODES=$(olsnodes | tr '\n' ','| sed 's/,\s*$//’)
2.2 GridSetup
./gridSetup.sh -ignorePrereq -waitforcompletion -silent -responseFile $ORACLE_HOME/install/response/gridsetup.rsp INVENTORY_LOCATION=$ORA_INVENTORY ORACLE_BASE=$ORACLE_BASE SELECTED_LANGUAGES=en oracle.install.option=CRS_SWONLY oracle.install.asm.OSDBA=oinstall oracle.install.asm.OSOPER=oinstall oracle.install.asm.OSASM=asmadmin oracle.install.crs.config.ClusterConfiguration=STANDALONE oracle.install.crs.config.configureAsExtendedCluster=false oracle.install.crs.config.clusterName=$CLUSTER_NAME oracle.install.crs.config.gpnp.configureGNS=false oracle.install.crs.config.autoConfigureClusterNodeVIP=false oracle.install.crs.config.clusterNodes=$CLUSTER_NODES
##warten…
2.3 TNSNAMES UND LISTENER anpassen
Auf allen Servern rzl01 und rzl02:
cd $ORACLE_HOME/network/admin
ln -s /u01/app/oracle/admin/network/tnsnames.ora
cp /u01/app/grid/product/19/gridhome/network/admin/sqlnet.ora . cp /u01/app/grid/product/19/gridhome/network/admin/listener.ora .
2.4 Datenbanksoftware
Beide Server rzl01 und rzl02:
oracle:
mkdir -p /u01/app/oracle/product/19.22/dbhome_1
cd /u01/app/oracle/product/19.22/dbhome_1
export ORACLE_HOME=`pwd`
Nur ein Server rzl01:
unzip /u05/orashare/software/Gold/db_home_2024-01-23_11-53-25AM.zip
export ORACLE_BASE=/u01/app/oracle
export ORA_INVENTORY=/u01/app/oraInventory
export CLUSTER_NAME=$(/u01/app/grid/product/19/gridhome/bin/olsnodes -c)
export CLUSTER_NODES=$(/u01/app/grid/product/19/gridhome/bin/olsnodes | tr '\n' ','| sed 's/,\s*$//')
./runInstaller -silent -responseFile $ORACLE_HOME/install/response/db_install.rsp oracle.install.option=INSTALL_DB_SWONLY UNIX_GROUP_NAME=oinstall INVENTORY_LOCATION=$ORA_INVENTORY ORACLE_HOME=$ORACLE_HOME ORACLE_BASE=$ORACLE_BASE oracle.install.db.InstallEdition=EE oracle.install.db.OSDBA_GROUP=dba oracle.install.db.OSOPER_GROUP=oper oracle.install.db.OSBACKUPDBA_GROUP=backupdba oracle.install.db.OSDGDBA_GROUP=dgdba oracle.install.db.OSKMDBA_GROUP=kmdba oracle.install.db.OSRACDBA_GROUP=dba oracle.install.db.rootconfig.executeRootScript=false oracle.install.db.CLUSTER_NODES=$CLUSTER_NODES
2.5 Network/admin Ordner
Beide Server user root
/u01/app/oracle/product/19.22/dbhome_1/root.sh
Beide Server user oracle
cd /u01/app/oracle/product/19.22/dbhome_1/network/admin
ln -s /u01/app/grid/product/19.22/gridhome/network/admin/listener.ora
ln -s /u01/app/oracle/admin/network/sqlnet.ora ln -s /u01/app/oracle/admin/network/tnsnames.ora
3. Switch Home
Nachdem die neuen 19.22 Homes erstellt wurden, kann anschließend ein Switch Home ausgeführt werden, um die Datenbanken im neuen Home zu betreiben.
3.1 Ändern des ORACLE_HOMES für die Datenbank und /etc/oratab
User oracle
srvctl modify database -db CDB_A -oraclehome u01/app/oracle/product/19.22/dbhome_1
srvctl modify database -db CDB_B -oraclehome u01/app/oracle/product/19.22/dbhome_1
srvctl modify database -db CDB_C -oraclehome u01/app/oracle/product/19.22/dbhome_1
vi /etc/oratab # auf allen Knoten
CDB_A:/u01/app/oracle/product/19.22/dbhome_1:N
CDB_B:/u01/app/oracle/product/19.22/dbhome_1:N
CDB_C:/u01/app/oracle/product/19.22/dbhome_1:N
3.2 Switch Home 1. Server rzl01
User grid
. oraenv
--> -MGMTDB # sollte jetzt neues GI HOME sein
$ORACLE_HOME sollte 19.22 sein
$ORACLE_HOME/gridSetup.sh -silent -switchGridHome oracle.install.option=CRS_SWONLY ORACLE_HOME=$ORACLE_HOME oracle.install.crs.config.clusterNodes=hostname -s oracle.install.crs.rootconfig.executeRootScript=false
3.3 Nacharbeiten
root:
/u01/app/grid/product/19.22/gridhome/root.sh
root:
/u01/app/grid/product/19.22/gridhome/bin/crsctl stop crs
/u01/app/grid/product/19.22/gridhome/bin/crsctl start crs -wait
#Überprüfen
ps -ef |grep grid
3.4. Switch Home wiederholen für 2. Server (rzl02)
Hier noch einmal alles für den 2. Server, also rzl02 wiederholen ab 3.1 Ändern des ORACLE_HOMES für die Datenbank und /etc/oratab
Nachdem auf dem zweiten Server ebenfalls das Switch Home erfolgt ist, ist die Standby-Seite in Leverkusen fertig gepatched. Nun fehlt noch Köln. Wir erinnern uns, in Köln läuft die Datenbank auf der Primary-Seite weshalb wir überlegen müssen wie es nun weitergeht.
Es gibt 2 Möglichkeiten:
•Möglichkeit 1: Primary-Seite patchen:
Vorteil: Keine Downtime und Desaster Recovery
Nachteil:Ein RAC-Knoten ist für kurze Zeit während switch home nicht verfügbar
→ bei nur 2 Knoten keine Hochverfügbarkeit mehr
•Möglichkeit 2: Switchover
Vorteil: Stellen Hochverfügbarkeit sicher und Desaster Recovery
Nachteil: Kurze Downtime beim Switchover
Wichtig: Beide Varianten sind völlig in Ordnung. Hier muss jeder für sich selbst abwägen, welche Methode für sein System am besten geeignet ist.
Egal welche Methode gewählt wird, müssen alle Schritte nochmal für die Server in Köln wiederholt werden (ab Schritt 2. Homes Patchen)
4. Datapatch
Nachdem alle Homes auf den jeweiligen Rechenzentren gepatched wurden folgt am Schluss wie immer der Datapatch. Der Datapatch muss nur auf einem Server auf der aktiven Seite durchgeführt werden, allerdings pro CDB.
Nur auf der aktiven Seite:
Umgebung setzen auf CDB_A:
$ORACLE_HOME/OPatch/datapatch
Prüfen:
sqlplus / as sysdba
SQL>select patch_id, patch_type, status, description from dba_registry_sqlpatch;
Umgebung setzen auf CDB_B:
$ORACLE_HOME/OPatch/datapatch
Prüfen
sqlplus / as sysdba
SQL>select patch_id, patch_type, status, description from dba_registry_sqlpatch;
Umgebung setzen auf CDB_C
$ORACLE_HOME/OPatch/datapatch
Prüfen:
sqlplus / as sysdba
SQL>select patch_id, patch_type, status, description from dba_registry_sqlpatch;
Am Ende muss in der dba_registry_sqlpatch Tabelle der 19.22 Patch aufgelistet sein
Damit war der Patch erfolgreich!
Probleme
Natürlich läuft nicht immer alles reibungslos, hier also noch zwei Probleme auf die während des Patchens aufgetreten sind
1. PDB im restricted Mode
Nach dem Datapatch blieben einige PDBs im restricted mode. Der Grund ist nicht bekannt, allerdings lässt sich das lösen in dem der _pdb_datapatch_violation_restricted Parameter auf False gesetzt wird:
•Alter System set “_pdb_datapatch_violation_restricted“ = FALSE;
Anschließen muss datapatch noch einmal ausgeführt werden
2. Listener falsch konfiguriert
Es ist wichtig daran zu denken die Listenereinträge anzupassen, da in den Listener.ora Einträgen das Oracle_Home angegeben wird. Also von 19 auf 19.22:
Das Suchen und Ersetzen kann wie folgt mit einem Linux Befehl verwirklicht werden:
sed –I 's/product\/19/product\/19.22/g' /u01/app/grid/product/19.22/gridhome/network/admin/listener.ora