SEHA means Standard Edition High Availability. SEHA is fully integrated with Oracle Grid Infrastructure starting with Oracle Grid Infrastructure 19c, and more specifically since RU 19.7. SEHA provides then cluster-based failover for single-instance Standard Edition Oracle Databases using Oracle Clustware. It is important to mention that Oracle removed Oracle RAC from SE2 Edition since 19c.
Most important things to know about SEHA
- SEHA allows running a database in SE in cluster environment
- No RAC functionality (global cache, global enqueue, …)
- SEHA has less functionalities as RAC
- 2 instances can then not be up at the same time
- SEHA will have to shutdown one instance before starting the other node instance
Also know that a database in SE Edition with a version lower than 19c and configured in RAC will have to be converted to SEHA configuration as part of the upgrade to Oracle database 19c.
A comparison between SEHA and RAC can be found in this oracle documentation : https://docs.oracle.com/en/database/oracle/oracle-database/19/cwadd/introduction-to-oracle-clusterware.html#GUID-C54E2511-24E2-452B-B4C7-0D5A93A751A9
A stated in Markus Michalewicz’s (Oracle Vice President of Product Management) blog about SEHA (https://blogs.oracle.com/maa/post/standard-edition-high-availability-released-see-whats-new), SEHA databases can be licensed using the “10-day failover rule”.
Please carefully read the prerequisite of SEHA you can find on this link : https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/guidelines-for-seha.html#GUID-55EEFB09-B708-4BA5-BA1A-23609FEC6A29
What about SEHA and ODA?
SEHA provides cluster-based failover for 19c SE database. When there is an instance or node failure, following scenario will apply:
- There is first an attempt to restart the instance on the local node
- Then the database automatically fails over on the other node if needed
- This means the database is restarted on the second node
Of course SEHA is not possible on ODA light as ODA 2S, 2M, 2L. To be able to take advantage of this functionality we will need an ODA-2-HA model which will come with 2 server nodes, a shared storage and server interconnects.
My Lab environment
My lab is running an ODA X5-2-HA.
Node 0 hostname is dbioda02.
Node 1 hostname is dbioda03.
Create a SEHA database on the ODA-2-HA
A single-instance Oracle 19c SE2 database will be automatically configured in failover mode. High Availability option can of course later be enable or disabled. Both nodes need to host a dbhome in SE edition.
I have a SE dbhome:
[root@dbioda02 ~]# odacli describe-dbhome -i 5b0b3769-0c05-435e-b7c8-5d295c05934c
DB Home details
----------------------------------------------------------------
ID: 5b0b3769-0c05-435e-b7c8-5d295c05934c
Name: OraDB19000_home2
Version: 19.15.0.0.220419
Home Location: /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_2
Status: CONFIGURED
Created: January 27, 2023 9:34:03 AM CET
Database Edition: SE
I created a SE Single Instance database named DBISEHA (note the option -y SI):
[root@dbioda02 ~]# odacli create-database -u DBISEHA -n DBISEHA -dh 5b0b3769-0c05-435e-b7c8-5d295c05934c -y SI -g 0
Enter SYS and SYSTEM user password:
Retype SYS and SYSTEM user password:
Job details
----------------------------------------------------------------
ID: f47e6f6a-6fcb-422a-8187-b9a2031eae50
Description: Database service creation with db name: DBISEHA
Status: Created
Created: January 27, 2023 9:41:13 AM CET
Message:
Task Name Start Time End Time Status
---------------------------------------- ----------------------------------- ----------------------------------- ----------
As we can see, High Availability, so called SEHA, has been automatically configured. Note the field High Availability:
[root@dbioda02 ~]# odacli describe-database -i bed8b9fb-214a-423e-b0e8-d8c084b45dd1
Database details
----------------------------------------------------------------
ID: bed8b9fb-214a-423e-b0e8-d8c084b45dd1
Description: DBISEHA
DB Name: DBISEHA
DB Version: 19.15.0.0.220419
DB Type: SI
DB Role: PRIMARY
DB Target Node Name: dbioda02
DB Edition: SE
DBID: 1535732728
Instance Only Database: false
CDB: false
PDB Name:
PDB Admin User Name:
High Availability: true
Class: OLTP
Shape: odb1
Storage: ASM
DB Redundancy:
CharacterSet: AL32UTF8
National CharacterSet: AL16UTF16
Language: AMERICAN
Territory: AMERICA
Home ID: 5b0b3769-0c05-435e-b7c8-5d295c05934c
Console Enabled: false
TDE Wallet Management:
TDE Enabled: false
Level 0 Backup Day: Sunday
AutoBackup Enabled: false
Created: January 27, 2023 9:41:13 AM CET
DB Domain Name: dbi-lab.ch
Associated Networks: Public-network
CPU Pool Name:
We can disable and enable SEHA functionality with following options:
[root@dbioda02 ~]# odacli modify-database -h | grep seha
--disable-seha,-no-sh Disable SEHA for SE 19c and later SIDB (inverse
option: --enable-seha/-sh)
--enable-seha,-sh Enable SEHA for SE 19c and later SIDB (inverse
option: --disable-seha/-no-sh)
Let’s deactivate the SEHA functionality:
[root@dbioda02 ~]# odacli modify-database -in DBISEHA -no-sh
{
"jobId" : "930d200a-cd29-4f7b-a6b3-5831b1b14ff2",
"status" : "Created",
"message" : "Modify database",
"reports" : [ ],
"createTimestamp" : "January 27, 2023 10:09:00 AM CET",
"resourceList" : [ {
"resourceId" : "bed8b9fb-214a-423e-b0e8-d8c084b45dd1",
"resourceType" : "DB",
"resourceNewType" : null,
"jobId" : "930d200a-cd29-4f7b-a6b3-5831b1b14ff2",
"updatedTime" : "January 27, 2023 10:09:00 AM CET"
} ],
"description" : "Modify database : DBISEHA",
"updatedTime" : "January 27, 2023 10:09:00 AM CET",
"jobType" : "",
"warning" : "'--enable-seha/-sh' option is deprecated, use '--enable-ha/-ha' instead. '--disable-seha/-no-sh' option is deprecated, use '--disable-ha/-no-ha' instead."
}
[root@dbioda02 ~]# odacli describe-job -i 930d200a-cd29-4f7b-a6b3-5831b1b14ff2
Job details
----------------------------------------------------------------
ID: 930d200a-cd29-4f7b-a6b3-5831b1b14ff2
Description: Modify database : DBISEHA
Status: Success
Created: January 27, 2023 10:09:00 AM CET
Message: Modify database
Task Name Start Time End Time Status
---------------------------------------- ----------------------------------- ----------------------------------- ----------
Disable High availability for database {DBISEHA} January 27, 2023 10:09:02 AM CET January 27, 2023 10:09:04 AM CET Success
[root@dbioda02 ~]# odacli describe-database -i bed8b9fb-214a-423e-b0e8-d8c084b45dd1 | grep 'High Availability'
High Availability: false
And reactivate it again:
[root@dbioda02 ~]# odacli modify-database -in DBISEHA -sh
{
"jobId" : "4ae27cab-84fa-4204-be8d-37519df75aac",
"status" : "Created",
"message" : "Modify database",
"reports" : [ ],
"createTimestamp" : "January 27, 2023 10:14:05 AM CET",
"resourceList" : [ {
"resourceId" : "bed8b9fb-214a-423e-b0e8-d8c084b45dd1",
"resourceType" : "DB",
"resourceNewType" : null,
"jobId" : "4ae27cab-84fa-4204-be8d-37519df75aac",
"updatedTime" : "January 27, 2023 10:14:05 AM CET"
} ],
"description" : "Modify database : DBISEHA",
"updatedTime" : "January 27, 2023 10:14:05 AM CET",
"jobType" : "",
"warning" : "'--enable-seha/-sh' option is deprecated, use '--enable-ha/-ha' instead. '--disable-seha/-no-sh' option is deprecated, use '--disable-ha/-no-ha' instead."
}
[root@dbioda02 ~]# odacli describe-job -i 4ae27cab-84fa-4204-be8d-37519df75aac
Job details
----------------------------------------------------------------
ID: 4ae27cab-84fa-4204-be8d-37519df75aac
Description: Modify database : DBISEHA
Status: Success
Created: January 27, 2023 10:14:05 AM CET
Message: Modify database
Task Name Start Time End Time Status
---------------------------------------- ----------------------------------- ----------------------------------- ----------
Configure All Candidate Nodes January 27, 2023 10:14:06 AM CET January 27, 2023 10:14:09 AM CET Success
[root@dbioda02 ~]# odacli describe-database -i bed8b9fb-214a-423e-b0e8-d8c084b45dd1 | grep 'High Availability'
High Availability: true
[root@dbioda02 ~]#
Relocate a SEHA database
A Single Instance SE2 database can easily be relocated to other node with odacli modify-database command using the target host name (option –targethost,-th) or with the node number (option –targetnode,-g).
As we can see, my DBISEHA database is currently running on my node 0:
[root@dbioda02 ~]# ps -ef | grep [p]mon oracle 464 1 0 09:54 ? 00:00:00 ora_pmon_DBISEHA grid 45768 1 0 2022 ? 00:05:06 apx_pmon_+APX1 grid 63447 1 0 2022 ? 00:04:47 asm_pmon_+ASM1 oracle 86674 1 0 2022 ? 00:05:22 ora_pmon_DBITST1 [root@dbioda03 ~]# ps -ef | grep [p]mon grid 11548 1 0 2022 ? 00:01:54 asm_pmon_+ASM2 grid 13397 1 0 2022 ? 00:01:57 apx_pmon_+APX2 oracle 23156 1 0 2022 ? 00:02:13 ora_pmon_DBITST2
Which is confirmed by ODA Metadata:
[root@dbioda02 ~]# odacli describe-database -i bed8b9fb-214a-423e-b0e8-d8c084b45dd1 | grep 'DB Target Node Name'
DB Target Node Name: dbioda02
Let’s relocate the database to the other node:
[root@dbioda02 ~]# odacli modify-database -in DBISEHA -g 1
{
"jobId" : "ab67a8e9-d5bf-40db-b83c-ecff118f5268",
"status" : "Created",
"message" : "Modify database",
"reports" : [ ],
"createTimestamp" : "January 27, 2023 10:31:03 AM CET",
"resourceList" : [ {
"resourceId" : "bed8b9fb-214a-423e-b0e8-d8c084b45dd1",
"resourceType" : "DB",
"resourceNewType" : null,
"jobId" : "ab67a8e9-d5bf-40db-b83c-ecff118f5268",
"updatedTime" : "January 27, 2023 10:31:03 AM CET"
} ],
"description" : "Modify database : DBISEHA",
"updatedTime" : "January 27, 2023 10:31:03 AM CET",
"jobType" : ""
}
[root@dbioda02 ~]# odacli describe-job -i ab67a8e9-d5bf-40db-b83c-ecff118f5268
Job details
----------------------------------------------------------------
ID: ab67a8e9-d5bf-40db-b83c-ecff118f5268
Description: Modify database : DBISEHA
Status: Success
Created: January 27, 2023 10:31:03 AM CET
Message: Modify database
Task Name Start Time End Time Status
---------------------------------------- ----------------------------------- ----------------------------------- ----------
Relocate database {DBISEHA} January 27, 2023 10:31:04 AM CET January 27, 2023 10:32:22 AM CET Success
We can see with odacli that the database has been relocated and that the current running node is now node 1, dbioda03:
[root@dbioda02 ~]# odacli describe-database -i bed8b9fb-214a-423e-b0e8-d8c084b45dd1 | grep 'DB Target Node Name'
DB Target Node Name: dbioda03
And we can confirm seeing that the pmon process of the database is now running on node 1:
[root@dbioda02 ~]# ps -ef | grep [p]mon grid 45768 1 0 2022 ? 00:05:06 apx_pmon_+APX1 grid 63447 1 0 2022 ? 00:04:47 asm_pmon_+ASM1 oracle 86674 1 0 2022 ? 00:05:22 ora_pmon_DBITST1 [root@dbioda03 ~]# ps -ef | grep [p]mon grid 11548 1 0 2022 ? 00:01:54 asm_pmon_+ASM2 grid 13397 1 0 2022 ? 00:01:57 apx_pmon_+APX2 oracle 23156 1 0 2022 ? 00:02:13 ora_pmon_DBITST2 oracle 38465 1 0 10:32 ? 00:00:00 ora_pmon_DBISEHA
We can also see from both alert logs that, with Oracle SEHA, the running instance is first stopped before the new one is started.
On the running node 0, the instance was stopped and completed at 10:31:28:
[oracle@dbioda02 trace]$ tail -2 alert_DBISEHA.log 2023-01-27T10:31:28.200215+01:00 Instance shutdown complete (OS id: 74061)
The start of the instance on the new node 1, only started afterwards at 10:31:53:
[oracle@dbioda03 trace]$ head -2 alert_DBISEHA.log 2023-01-27T10:31:53.131466+01:00 Starting ORACLE instance (normal) (OS id: 37772)
What if now node 1 is crashing?
If we power off node 1, the database DBISEHA will be automatically failovered on node 0.
Let’s poweroff node 1:
[root@dbioda03 ~]# date Fri Jan 27 10:55:22 CET 2023 [root@dbioda03 ~]# systemctl poweroff Connection to 10.X.X.233 closed by remote host. Connection to 10.X.X.233 closed.
And check that PMON processes for DBISEHA database will be started on node 0:
[root@dbioda02 ~]# ps -ef | grep [p]mon oracle 18471 1 0 10:56 ? 00:00:00 ora_pmon_DBISEHA grid 45768 1 0 2022 ? 00:05:07 apx_pmon_+APX1 grid 63447 1 0 2022 ? 00:04:47 asm_pmon_+ASM1 oracle 86674 1 0 2022 ? 00:05:22 ora_pmon_DBITST1
The database has been automatically started on node 0 about 30 seconds later.
Confirmed with the alert log file on node 0:
[oracle@dbioda02 trace]$ more alert_DBISEHA.log ... ... ... 2023-01-27T10:55:55.393501+01:00 Starting ORACLE instance (normal) (OS id: 18288) ... ... ...
Upgrade a RAC database to 19c SEHA database
A stated previously, databases in SE version lower than 19c and having RAC enabled will have to be converted to SEHA configuration as part of the upgrade to Oracle database 19c.
Convert the oracle RAC database to a Single Instance database with following command (option -y SI):
[root@dbioda02 ~]# odacli modify-database -in DBIRACSE -y SI
Upgrade the SI database to Oracle 19c version with SEHA functionality enabled.
[root@dbioda02 ~]# odacli upgrade-database -i 42612408-6ddf-4152-bce0-74ed41394866 –to 5b0b3769-0c05-435e-b7c8-5d295c05934c -sh
Enable/disable options are available for all 3 odacli create, modify and upgrade database commands.
![Thumbnail [60x60]](https://www.dbi-services.com/blog/wp-content/uploads/2022/08/MAW_web-min-scaled.jpg)
![Thumbnail [90x90]](https://www.dbi-services.com/blog/wp-content/uploads/2022/08/JDU_web-min-scaled.jpg)
![Thumbnail [90x90]](https://www.dbi-services.com/blog/wp-content/uploads/2022/08/ALN_web-min-scaled.jpg)