During AIOUG Yatra conference, I attended a session by Markus Michalewicz about “Standard Edition High Availability”. This is a new feature in Oracle Database 19.7, after Oracle has removed Oracle RAC from Oracle Standard Edition (SE2) effective with Oracle Database 19c.
Since I’m interested in HA in general, I decided to try this out.
What is SEHA?
SEHA stands for “Standard Edition High Availability”. It allows running a Standard Edition database in a cluster environment, but unlike RAC and RAC one node (see comparison below), SEHA does not include any RAC database functionality (so no global cache, no global enqueue, etc.). This means that SEHA does not allow 2 instances to be up at the same time, no matter how short this time is. SEHA will have to shutdown an instance on one node before starting another instance on the other node. The concept is similar to Oracle Fail Safe on Windows back in the days.
Installing SEHA
Installing SEHA should be straight forward for anyone who installed RAC in the past.
First step will be installing the Grid Infrastructure (GI) and Oracle Database (DB) software:
- Prepare 2 or more nodes for SEHA (note that there are license restrictions related to SE2, so make sure the nodes are compliant. I won’t go into this here) – My nodes are called seha1 and seha2
- Install GI 19.7 or later on both nodes to form a standalone cluster (just like in RAC) – I used 19.8
- Install Oracle database SE2 19.7 or later (software only) on one node of the cluster – I installed 19.8
Now that we have everything ready we can configure SEHA:
- Use the addnode script to copy and setup the Oracle home on the 2nd node using (from the DB home):
$ORACLE_HOME/addnode/addnode.sh CLUSTER_NEW_NODES=seha2
You can add “-silent” for silent installation without GUI. Please check the documentation for more information (link below). - Now you can create your database on one of the nodes. I used DBCA to create 2 databases (one on seha1 called se1 and one on seha2 called se2).
I created my databases using DBCA and I realized that DBCA automatically added them as resources in the cluster. After creating both databases, this is how my cluster looks like:
[oracle@seha1 ~]$ crsctl status res -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.LISTENER.lsnr
ONLINE ONLINE seha1 STABLE
ONLINE ONLINE seha2 STABLE
ora.chad
ONLINE ONLINE seha1 STABLE
ONLINE ONLINE seha2 STABLE
ora.net1.network
ONLINE ONLINE seha1 STABLE
ONLINE ONLINE seha2 STABLE
ora.ons
ONLINE ONLINE seha1 STABLE
ONLINE ONLINE seha2 STABLE
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup)
1 ONLINE ONLINE seha1 STABLE
2 ONLINE ONLINE seha2 STABLE
3 ONLINE OFFLINE STABLE
ora.DATA.dg(ora.asmgroup)
1 ONLINE ONLINE seha1 STABLE
2 ONLINE ONLINE seha2 STABLE
3 OFFLINE OFFLINE STABLE
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE seha1 STABLE
ora.asm(ora.asmgroup)
1 ONLINE ONLINE seha1 Started,STABLE
2 ONLINE ONLINE seha2 Started,STABLE
3 OFFLINE OFFLINE STABLE
ora.asmnet1.asmnetwork(ora.asmgroup)
1 ONLINE ONLINE seha1 STABLE
2 ONLINE ONLINE seha2 STABLE
3 OFFLINE OFFLINE STABLE
ora.cvu
1 ONLINE ONLINE seha1 STABLE
ora.qosmserver
1 ONLINE ONLINE seha1 STABLE
ora.scan1.vip
1 ONLINE ONLINE seha1 STABLE
ora.se1.db
1 ONLINE ONLINE seha1 Open,HOME=/oracle/db
/19,STABLE
ora.se2.db
1 ONLINE ONLINE seha2 Open,HOME=/oracle/db
/19,STABLE
ora.seha1.vip
1 ONLINE ONLINE seha1 STABLE
ora.seha2.vip
1 ONLINE ONLINE seha2 STABLE
--------------------------------------------------------------------------------
Let’s check one of the databases to see how it is configured:
[oracle@seha1 ~]$ srvctl config database -db se1
Database unique name: se1
Database name: se1
Oracle home: /oracle/db/19
Oracle user: oracle
Spfile: +DATA/SE1/PARAMETERFILE/spfile.271.1046968999
Password file:
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools:
Disk Groups: DATA
Mount point paths:
Services:
Type: SINGLE
OSDBA group: dba
OSOPER group: oper
Database instance: se1
Configured nodes: seha1
CSS critical: no
CPU count: 0
Memory target: 0
Maximum memory: 0
Default network number for database services:
Database is administrator managed
The interesting part for us is line 21 (highlighted). It says that this database is configured on node seha1. This means that the database is configured as “Oracle Restart”. It uses ASM, it is a resource in the cluster, and the cluster makes sure the database is up and running. The cluster is responsible for the database and will restart it automatically if the database crashes.
Now, let’s configure SEHA for database se1. For that we’ll need to reset the local_listener parameter of the database, move the password file to ASM and modify the database resource:
[oracle@seha1 OPatch]$ asmcmd
ASMCMD> pwcopy /oracle/db/19/dbs/orapwse1 +DATA/SE1/orapwSE1
copying /oracle/db/19/dbs/orapwse1 -> +DATA/SE1/orapwSE1
ASMCMD> ls -l +DATA/SE1/orapwSE1
Type Redund Striped Time Sys Name
PASSWORD UNPROT COARSE JUL 29 10:00:00 N orapwSE1 => +DATA/DB_UNKNOWN/PASSWORD/pwddb_unknown.291.1047031887
ASMCMD> exit
[oracle@seha1 OPatch]$ srvctl modify database -db se1 -pwfile +DATA/SE1/orapwSE1
[oracle@seha1 OPatch]$ srvctl config database -db se1
Database unique name: se1
Database name: se1
Oracle home: /oracle/db/19
Oracle user: oracle
Spfile: +DATA/SE1/PARAMETERFILE/spfile.271.1046968999
Password file: +DATA/SE1/orapwSE1
...
[oracle@seha1 OPatch]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Wed Jul 29 10:13:35 2020
Version 19.8.0.0.0
Copyright (c) 1982, 2020, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.8.0.0.0
SQL> show parameter local_listener
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
local_listener string LISTENER_SE1
SQL> alter system reset local_listener scope=both;
System altered.
SQL> show parameter local_listener
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
local_listener string
SQL> exit
SQL> Disconnected from Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.8.0.0.0
[oracle@seha1 OPatch]$ srvctl modify database -db se1 -node seha1,seha2
[oracle@seha1 OPatch]$ srvctl config database -db se1
Database unique name: se1
Database name: se1
Oracle home: /oracle/db/19
Oracle user: oracle
Spfile: +DATA/SE1/PARAMETERFILE/spfile.271.1046968999
Password file: +DATA/SE1/orapwSE1
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools:
Disk Groups: DATA
Mount point paths:
Services:
Type: SINGLE
OSDBA group: dba
OSOPER group: oper
Database instance: se1
Configured nodes: seha1,seha2
CSS critical: no
CPU count: 0
Memory target: 0
Maximum memory: 0
Default network number for database services:
Database is administrator managed
Now you can see that the database is configured on both nodes and this means that SEHA is enabled.
srvctl modify database returns PRKF-1125
The first time I tried this I got PRKF-1125:
[oracle@seha1 ~]$ srvctl modify database -db se1 -node seha1,seha2
PRKF-1125 : multiple values specified for the single value option "node": seha1,seha2
Thanks to Markus Flechtner‘s blog post I understood the problem. Even though Markus doesn’t mention the error specifically, he tweeted about it and the post explains the issue.
The srvctl utility is part of the OCW component of the Oracle Home. The database patch for 19.8 does not include this, so I had the old 19.3 srvctl which does not include SEHA support. In order to workaround this issue, either install the OCW patch into the DB home, or run srvctl from the GI home.
Different Solutions Comparison
| Description | RAC | RAC one node | SEHA |
|---|---|---|---|
| DB edition | EE | EE | SE |
| Automatic restart | Yes | Yes | Yes |
| Automatic failover | Yes | Yes | Yes |
| Load balance | Yes | No | No |
| Zero downtime relocation | Yes | Yes | No |
Conclusion
In this post I showed how to install and configure Oracle Standard Edition High Availability (SEHA). Since it’s quite long already, I’ll write about different scenarios and how SEHA behaves in a separate post which I will publish shortly.
More Info
Here are some relevant link for more information:
Thanks for this write-up.
Would SEHA handle network failure like RAC? for e.g. if the public network interface fails on the Active SEHA node, will DB instance startup on Standby SEHA node?
Thanks
Hi,
I haven’t check this scenario specifically, but it should. Once the network fails the resources should be migrated and SEHA should be one of these resources.
Liron
Thanks for the revert.
We tried this a few times and what we see is that the VIP does failover to other node but DB instance does not failover (i.e. it continues to run on the node where the network has failed and does not startup on the other healthy node).
Very interesting.
I’ll try to find time to check it and will keep you updated.
Thanks for the comment!
thanks for writing this up.
can i know why we need to reset local_listener for oracle SEHA?
Hi,
I don’t remember the details but I think the local_listener is set by default when you create a database with dbca. However, when we set SEHA we would like it to be set by the GI, so you should reset it so the GI can set it to the correct setting.
Hope this helps
i see, thank you.