Von 18c-SE2-RAC nach 19c-SEHA
Mit der Version 19c hat Oracle den Real Application Cluster aus der Feature-List der “Standard Edition 2” der Datenbank gestrichen. Bis dahin war SE2-RAC eine günstige Hochverfügbarkeitslösung. Ein knappes Jahr später kam der “Ersatz” auf den Markt: Standard Edition High Availability, kurz: SEHA. Und da für immer mehr ältere Versionen der Datenbank der Support ausläuft oder schon ausgelaufen ist, stellt sich für Administratoren die Frage: Wie komme ich von SE2-RAC zu 19c-SEHA?
Mein Test-System besteht aus einem 2-Knoten-Cluster mit Oracle Grid Infrastructure 19c:
oracle@snoopy:~/ [rdbms18] olsnodes snoopy charlybrown oracle@snoopy:~/ [grinf19] echo $ORACLE_HOME;$ORACLE_HOME/OPatch/opatch lspatches /u00/app/grid/product/19c 33733953;OCW Interim patch for 33733953 33575402;DBWLM RELEASE UPDATE 19.0.0.0.0 (33575402) 33534448;ACFS RELEASE UPDATE 19.14.0.0.0 (33534448) 33515361;Database Release Update : 19.14.0.0.220118 (33515361) 33239955;TOMCAT RELEASE UPDATE 19.0.0.0.0 (33239955) 33192694;OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694) OPatch succeeded.
Wer mit zusätzlichen Services in der Datenbank arbeitet, sollte in jedem Fall den Patch 33733953 installieren. Ansonsten werden mit 19.14 Services für ältere Datenbanken, die nicht zu einer PDB gehören, nicht gestartet (Einzelheiten siehe MOS-Note 2835152.1).
Weiterhin habe ich die 18c- und 19c-Standard-Edition 2 installiert:
oracle@snoopy:~/ [rdbms18] echo $ORACLE_HOME;$ORACLE_HOME/OPatch/opatch lspatches /u00/app/oracle/product/18c-se 32524155;Database Release Update : 18.14.0.0.210420 (32524155) 32552752;OJVM RELEASE UPDATE: 18.14.0.0.210420 (32552752) 28090553;OCW RELEASE UPDATE 18.3.0.0.0 (28090553) OPatch succeeded. oracle@snoopy:~/ [rdbms19se] echo $ORACLE_HOME;$ORACLE_HOME/OPatch/opatch lspatches /u00/app/oracle/product/19c-se 33733953;OCW Interim patch for 33733953 33561310;OJVM RELEASE UPDATE: 19.14.0.0.220118 (33561310) 33515361;Database Release Update : 19.14.0.0.220118 (33515361) OPatch succeeded.
Wichtig: auch im 19c-RDBMS-Oracle-Home sollte der passende OCW-Patch für die Clusterware, in diesem Fall 33733953, installiert sein.
Auf dem Cluster läuft eine Datenbank SE2DB in der klassischen Architektur (Non-CDB-Architektur):
oracle@snoopy:~/ [SE2DB1] srvctl status database -db SE2DB Instance SE2DB1 is running on node snoopy Instance SE2DB2 is running on node charlybrown oracle@snoopy:~/ [SE2DB1] srvctl config database -db SE2DB Database unique name: SE2DB Database name: SE2DB Oracle home: /u00/app/oracle/product/18c-se Oracle user: oracle Spfile: +DATA/SE2DB/PARAMETERFILE/spfile.300.1096408149 Password file: +DATA/SE2DB/PASSWORD/pwdse2db.288.1096406995 Domain: markusdba.local Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Server pools: Disk Groups: DATA,FRA Mount point paths: Services: SE2DB_APP Type: RAC Start concurrency: Stop concurrency: OSDBA group: dba OSOPER group: oper Database instances: SE2DB1,SE2DB2 Configured nodes: snoopy,charlybrown CSS critical: no CPU count: 0 Memory target: 0 Maximum memory: 0 Default network number for database services: Database is administrator managed
Für die Datenbank ist ein zusätzlicher Service definiert:
oracle@snoopy:~/ [SE2DB1] srvctl config service -db SE2DB Service name: SE2DB_APP Server pool: Cardinality: 1 Service role: PRIMARY Management policy: AUTOMATIC DTP transaction: false AQ HA notifications: false Global: false Commit Outcome: false Failover type: Failover method: Failover retries: Failover delay: Failover restore: NONE Connection Load Balancing Goal: LONG Runtime Load Balancing Goal: NONE TAF policy specification: NONE Edition: Pluggable database name: Hub service: Maximum lag time: ANY SQL Translation Profile: Retention: 86400 seconds Replay Initiation Time: 300 seconds Drain timeout: Stop option: Session State Consistency: DYNAMIC GSM Flags: 0 Service is enabled Preferred instances: SE2DB1 Available instances: SE2DB2 CSS critical: no
Wie machen wir aus dieser RAC-Datenbank nun eine SEHA-Datenbank?
Wenn wir davon ausgehen, dass der dbua weiß, dass mit 19c RAC für die SE2 nicht mehr unterstützt ist und dass dbua daher automatisch vorschlägt, aus der RAC-Datenbank eine SEHA-Datenbank zu machen, dann werden wir leider enttäuscht. Denn der 19c-dbua meldet:
Wir müssen die notwendigen Schritte also manuell durchführen:
Schritt 1: pfile generieren
oracle@charlybrown:~/ [SE2DB2] sqlplus / as sysdba SQL*Plus: Release 18.0.0.0.0 - Production on Sat Feb 12 22:36:10 2022 Version 18.14.0.0.0 Copyright (c) 1982, 2018, Oracle. All rights reserved. Connected to: Oracle Database 18c Standard Edition 2 Release 18.0.0.0.0 - Production Version 18.14.0.0.0 SQL> create pfile='/home/oracle/initSE2DB.ora' from spfile; File created. SQL> exit Disconnected from Oracle Database 18c Standard Edition 2 Release 18.0.0.0.0 - Production Version 18.14.0.0.0
Schritt 2: pfile bearbeiten
Im pfile werden wir jetzt die notwendigen Daten ändern, wie z.B. CLUSTER_DATABASE auf “FALSE” setzen. Weiterhin empfehle ich, Verweise auf die 2.RAC-Instanz (SE2DB2) zu entfernen und die Einträge für die 1.Instanz (SE2DB1) durch “*” zu ersetzen, denn bei einer Single-Instance-Datenbank ist eine Unterscheidung der Instanzen nicht erforderlich.
Vorher sichern wir natürlich das RAC-spfile:
oracle@charlybrown:~/ [SE2DB2] cp initSE2DB.ora initSE2DB_RAC.ora
Da bei einer Single-Instance-Datenbank die gesamte Last auch von einer Instanz bewältigt werden muss, muss man ggf. auch die Einstellungen für die Speicher-Konfiguration (SGA_MAX_SIZE, SGA_TARGET, PGA_AGGREGATE_TARGET, DB_CACHE_SIZE, SHARED_POOL_SIZE etc.) und weitere Ressourcen (z.B. PROCESSES) entsprechend anpassen.
Auf meinem kleinen Test-System sieht die init.ora-Datei nach der Bearbeitung so aus:
oracle@charlybrown:~/ [SE2DB2] cat initSE2DB.ora *.audit_file_dest='/u00/app/oracle/admin/SE2DB/adump' *.audit_trail='db' *.cluster_database=false *.compatible='18.0.0' *.control_files='+DATA/SE2DB/CONTROLFILE/current.289.1096407011','+FRA/SE2DB/CONTROLFILE/current.264.1096407011' *.db_block_size=8192 *.db_create_file_dest='+DATA' *.db_create_online_log_dest_1='+DATA' *.db_create_online_log_dest_2='+FRA' *.db_domain='markusdba.local' *.db_name='SE2DB' *.db_recovery_file_dest='+FRA' *.db_recovery_file_dest_size=7851m *.diagnostic_dest='/u00/app/oracle' *.dispatchers='(PROTOCOL=TCP) (SERVICE=SE2DBXDB)' family:dw_helper.instance_mode='read-only' *.instance_number=1 *.local_listener='-oraagent-dummy-' *.nls_language='AMERICAN' *.nls_territory='AMERICA' *.open_cursors=300 *.pga_aggregate_target=1200m *.processes=320 *.remote_login_passwordfile='exclusive' *.sga_target=3000m *.thread=1 *.undo_tablespace='UNDOTBS1'
Schritt 3: Datenbank-Konfiguration dokumentieren
Bevor wir die Datenbank stoppen und aus der Cluster-Registry löschen, sollten wir die Konfiguration dokumentieren:
oracle@charlybrown:~/ [SE2DB2] srvctl config service -db SE2DB oracle@charlybrown:~/ [SE2DB2] srvctl config database -db SE2DB
Schritt 4: Datenbank stoppen
oracle@charlybrown:~/ [SE2DB2] srvctl stop database -db SE2DB
Schritt 5: Datenbank in der Cluster-Registry löschen
oracle@charlybrown:~/ [SE2DB2] srvctl remove database -db SE2DB Remove the database SE2DB? (y/[n]) y
Schritt 6: Neues spfile anlegen
oracle@charlybrown:~/ [SE2DB2] sqlplus / as sysdba SQL*Plus: Release 18.0.0.0.0 - Production on Sat Feb 12 22:49:33 2022 Version 18.14.0.0.0 Copyright (c) 1982, 2018, Oracle. All rights reserved. Connected to an idle instance. SQL> create spfile='+DATA/SE2DB/spfileSE2DB.ora' from pfile='/home/oracle/initSE2DB.ora'; File created. SQL> exit Disconnected
Achtung: Die Single-Instance-Datenbank arbeitet somit mit einem anderen SPFILE als die RAC-Datenbank.
Schritt 7: Single-Instance-Datenbank als Cluster-Resource definieren
oracle@charlybrown:~/ [SE2DB2] srvctl add database -db SE2DB -oraclehome $ORACLE_HOME -dbtype SINGLE -instance SE2DB -spfile +DATA/SE2DB/spfileSE2DB.ora -pwfile +DATA/SE2DB/PASSWORD/pwdse2db.288.1096406995 -diskgroup "DATA,FRA" -node charlybrown
Schritt 8: Datenbank starten
oracle@charlybrown:~/ [SE2DB2] srvctl start database -db SE2DB oracle@charlybrown:~/ [SE2DB2] srvctl status database -db SE2DB Instance SE2DB is running on node charlybrown
Schritt 9: Service wieder definieren und starten
Wenn es zusätzliche Services gibt, dann können diese Services jetzt wieder angelegt und gestartet werden.
oracle@charlybrown:~/ [SE2DB2] srvctl add service -db SE2DB -service SE2DB_APP oracle@charlybrown:~/ [SE2DB2] srvctl start service -db SE2DB -service SE2DB_APP oracle@charlybrown:~/ [SE2DB2] srvctl status service -db SE2DB -service SE2DB_APP Service SE2DB_APP is running on instance(s) SE2DB
Schritt 10: 2.Redo-Thread deaktivieren
Der Redo-Thread der 2.Instanz wird nicht mehr benötigt und kann deaktiviert werden. Zusätzlich kann man auch die Online-Redolog-Dateien dieses Threads löschen.
oracle@charlybrown:~/ [SE2DB2] export ORACLE_SID=SE2DB oracle@charlybrown:~/ [SE2DB] sqlplus / as sysdba SQL*Plus: Release 18.0.0.0.0 - Production on Sat Feb 12 22:56:52 2022 Version 18.14.0.0.0 Copyright (c) 1982, 2018, Oracle. All rights reserved. Connected to: Oracle Database 18c Standard Edition 2 Release 18.0.0.0.0 - Production Version 18.14.0.0.0 SQL> alter database disable thread 2; Database altered.
Schritt 11: 2.Undo-Tablespace löschen
Der Undo-Tablespace für die 2.Instanz wird nicht mehr benötigt und kann gelöscht werden:
SQL> drop tablespace UNDOTBS2 including contents and datafiles; Tablespace dropped. SQL> exit Disconnected from Oracle Database 18c Standard Edition 2 Release 18.0.0.0.0 - Production Version 18.14.0.0.0
Schritt 12: Aufräumen
Zum Abschluss der Vorbereitungen ist es eine gute Gelegenheit aufzuräumen und z.B. die Verzeichnisse der RAC-Instanzen im ADR zu löschen:
oracle@charlybrown:/u00/app/oracle/diag/rdbms/se2db/ [SE2DB] ls -ltr total 8 drwxr-xr-x. 16 oracle asmadmin 4096 Feb 11 21:51 SE2DB2 -rw-r-----. 1 oracle asmadmin 0 Feb 11 21:51 i_1.mif drwxr-xr-x. 16 oracle asmadmin 4096 Feb 12 22:54 SE2DB oracle@charlybrown:/u00/app/oracle/diag/rdbms/se2db/ [SE2DB] rm -rf SE2DB2 oracle@charlybrown:/u00/app/oracle/diag/rdbms/se2db/ [SE2DB] ssh snoopy oracle@snoopy:/u00/app/oracle/diag/rdbms/se2db/ [rdbms19se] rm -rf SE2DB1
Ggf. müssen die RAC-Instanzen auch noch aus anderen Konfigurationsdateien wie z.B. der /etc/oratab gelöscht werden bzw. im Eintrag muss die SID auf “SE2DB” geändert werden.
Neben dem 2.Undo-Tablespace, dem 2.Redolog-Thread und den Dateien im ADR kann man natürlich auch noch das RAC-Spfile im ASM löschen.
Schritt 13: Upgrade auf 19c
Jetzt kann der Upgrade auf die Version 19c erfolgen. Welches Werkzeug man dafür verwendet (dbua (GUI), dbupgrade (CLI) oder autoupgrade) ist in diesem Blog-Post, in dem es ja um den Wechsel von RAC zu SEHA geht, irrelevant.
Ergebnis ist eine 19c-Single-Instance-Datenbank:
oracle@charlybrown:~/ [SE2DB] srvctl status database -db SE2DB Instance SE2DB is running on node charlybrown oracle@charlybrown:~/ [SE2DB] srvctl status service -db SE2DB Service se2db_app is running on instance(s) SE2DB oracle@charlybrown:~/ [SE2DB] srvctl config database -db SE2DB Database unique name: SE2DB Database name: Oracle home: /u00/app/oracle/product/19c-se Oracle user: oracle Spfile: +DATA/SE2DB/spfilese2db.ora Password file: +DATA/SE2DB/PASSWORD/pwdse2db.288.1096406995 Domain: markusdba.local Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Server pools: Disk Groups: DATA,FRA Mount point paths: Services: SE2DB_APP Type: SINGLE OSDBA group: dba OSOPER group: oper Database instance: SE2DB Configured nodes: charlybrown CSS critical: no CPU count: 0 Memory target: 0 Maximum memory: 0 Default network number for database services: Database is administrator managed
Bitte beachten, dass der Parameter COMPATIBLE beim Upgrade nicht geändert wird:
SQL> show parameter compatible NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ compatible string 18.0.0
Dies muss also nach dem Upgrade manuell gemacht werden.
Schritt 14: Konfiguration als SEHA-Datenbank
Die Datenbank wird zu einer SEHA-Datenbank, indem man den zweiten Cluster-Knoten als verfügbaren Knoten hinzufügt.
oracle@charlybrown:~/ [SE2DB] srvctl modify database -db SE2DB -node "charlybrown,snoopy"
Schritt 15: Test des Wechsels auf den anderen Knoten
oracle@charlybrown:~/ [SE2DB] srvctl status database -db SE2DB Instance SE2DB is running on node charlybrown oracle@charlybrown:~/ [SE2DB] srvctl relocate database -db SE2DB -node snoopy oracle@charlybrown:~/ [SE2DB] srvctl status database -db SE2DB Instance SE2DB is running on node snoopy oracle@charlybrown:~/ [SE2DB] srvctl relocate database -db SE2DB -node charlybrown oracle@charlybrown:~/ [SE2DB] srvctl status database -db SE2DB Instance SE2DB is running on node charlybrown
Damit haben wir aus unserer 18c-RAC-Datenbank eine 19c-SEHA-Datenbank gemacht. Wie oben gesehen, ist ein einfacher “Switchover” zum 2.Server möglich. Beim “Failover” erkennt die Clusterware den Ausfall des Servers und startet die Instanz auf dem 2.Server.
Links & weitere Informationen
- Erste Eindrücke von SEHA: https://www.markusdba.net/2020/05/11/standard-edition-high-availability-first-impressions/
- blogs.oracle.com: Standard Edition High Availability Released – See What’s New – https://blogs.oracle.com/maa/standard-edition-high-availability-officially-released
- Oracle Documentation on SEHA: https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/creating-and-configuring-an-oracle-database.html#GUID-4B255433-4F5D-4A75-BB05-EBAB41361B5E
- 10-days-rule: https://www.oracle.com/assets/data-recovery-licensing-070587.pdf
- MOS-Note “Desupport of Oracle Real Application Clusters (RAC) with Oracle Database Standard Edition 19c (Doc ID 2504078.1)”
- MOS-Note “Bug 33733953 – Database Service Fails to Start With “CRS-5037: Database does not have the required fix for bug ‘31143870’” AFTER Grid Infrastructure Patching or Upgrade to 19.14 RU (Doc ID 33733953.8)”
- MOS-Note “ALERT: Database Service Fails to Start With “CRS-5037: Database does not have the required fix for bug ‘31143870’” AFTER Grid Infrastructure Patching or Upgrade to 19.14 RU (Doc ID 2835152.1)”
