Comme je l’avais indiqué dans un précédent post (ici), à  partir de la version 19c, Oracle Real Application Clusters (RAC) n’est plus supporté en Standard Edition.

Et bien voilà, c’est fait !

Annoncé en mars 2020, Oracle a officiellement mis à disposition Oracle Standard Edition High Availability sous Linux, Microsoft Windows et Solaris dans le cadre de la Release Update (RU) 19.7 d’Oracle Database 19c (avril 2020).

Oracle SE HA propose une solution de type failover (actif/passif) pour des instances Standard Edition en utilisant une configuration Oracle Grid Infrastructure qu’il convient donc d’installer au préalable (version 19c RU 19.7 ou ultérieure).

Ensuite, il suffit d’installer Oracle Database (version 19c RU 19.7 ou ultérieure) sur les deux noeuds du cluster, en mode « instance seul » (pas « Real Application Clusters » et d’opter pour la Standard Edition 2 :

Une fois l’installation terminée, il ne reste plus qu’à créer une base de données avec DBCA (Database Configuration Assistant, méthode recommandée), en sélectionnant bien ASM pour le stockage (stockage partagé entre les deux noeuds du cluster) :

Une fois la création terminée, la base de données est automatiquement enregistrée avec Oracle Clusterware (fonctionnalité Oracle Restart) et l’utilitaire srvctl peut être utilisé pour modifier la configuration de la base de données et activer SE HA :

[oracle@clu1 ~]$ srvctl stop database -db db1
[oracle@clu1 ~]$ srvctl modify database -db db1 -node clu1,clu2
[oracle@clu1 ~]$ srvctl start database -db db1
[oracle@clu1 ~]$ srvctl status database -db db1
Instance DB1 is running on node clu1
[oracle@clu1 ~]$ srvctl config database -db db1
Database unique name: DB1
Database name: DB1
Oracle home: /u01/app/oracle/product/19.0.0/dbhome_1
Oracle user: oracle
Spfile: +DATA1/DB1/PARAMETERFILE/spfile.273.1040732475
Password file: 
Domain: 
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: 
Disk Groups: DATA1
Mount point paths: 
Services: 
Type: SINGLE
OSDBA group: dba
OSOPER group: oper
Database instance: DB1
Configured nodes: clu1,clu2
CSS critical: no
CPU count: 0
Memory target: 0
Maximum memory: 0
Default network number for database services: 
Database is administrator managed

Dans la configuration, nous voyons que la base de données est de type SINGLE (pas RAC) et qu’elle est configurée sur deux noeuds.

C’est fini, la base de données est protégée par SE HA. Si l’instance s’arrête inopinément, elle est automatiquement redémarré par Oracle Clusterware (fonctionnalité Oracle Restart déjà existante). Si le serveur sur lequel l’instance est démarrée s’arrête brutalement, l’instance est automatiquement redémarrée sur un autre serveur disponible du cluster. Pour de la maintenance planifiée, ou pour un retour à la normale après une bascule sur un autre serveur, il est possible d’utiliser la commande srvctl relocate :

oracle@clu1 ~]$ srvctl relocate database -db db1 -node clu2
[oracle@clu1 ~]$ srvctl status database -db db1
Instance DB1 is running on node clu2

Il est important de noter que cette commande provoque un arrêt de la base de données sur le serveur d’origine puis un démarrage sur le serveur cible ; cela ne se fait pas à chaud.

Pour la connexion à la base de données à partir des applications, il est conseillé d’utiliser le SCAN (Single Client Access Name) comme nom de serveur dans les adresses réseaux. Ce nom, défini et géré par Oracle Clusterware sur les différents noeuds du cluster, permet de se connecter à l’instance quelle que soit son emplacement, et cela sans devoir modifier la configuration côté client. Ce nom peut être utilisé dans une connexion Easy Connect ou dans un nom de service réseau défini dans le fichier tnsnames.ora.

[oracle@clu1 ~]$ sqlplus system/xxxxxxxxxx@clu-scan/db1

SQL*Plus: Release 19.0.0.0.0 - Production on Wed May 20 06:51:11 2020
Version 19.7.0.0.0
Copyright (c) 1982, 2019, Oracle.  All rights reserved.
Last Successful login time: Wed May 20 2020 06:50:56 +02:00

Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.7.0.0.0

SQL> exit        
Disconnected from Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.7.0.0.0

[oracle@clu1 ~]$ cat $ORACLE_HOME/network/admin/tnsnames.ora 
DB1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = clu-scan)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = DB1)
    )
  )

[oracle@clu1 ~]$ sqlplus system/xxxxxxxxxx@db1

SQL*Plus: Release 19.0.0.0.0 - Production on Wed May 20 06:50:56 2020
Version 19.7.0.0.0
Copyright (c) 1982, 2019, Oracle.  All rights reserved.
Last Successful login time: Wed May 20 2020 05:56:35 +02:00

Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.7.0.0.0

SQL> exit
Disconnected from Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.7.0.0.0

Et la licence me direz-vous ?

Oracle Standard Edition High Availability est disponible sans coût supplémentaire par rapport à la Standard Edition 2, et Oracle Grid Infrastructure en lui même ne nécessite pas de licence.

Par ailleurs, cette configuration active/passive peut être utilisée sans licencier le deuxième serveur  en utilisant la règle des 10 jours (voir Data Recovery using Clustered Environments (Failover)). Pour mémoire, cette règle donne le droit d’exécuter une base de données sur un serveur de secours sans licence, dans un environnement de type failover, pendant un total de 10 jours différents au cours de l’année. Il faut noter que la Standard Edition High Availability est soumise à la limitation du nombre de sockets (2 maximum) par serveur et non pas pour la totalité cluster.

Si vous avez plusieurs base de données à protéger, il peut être intéressant de licencier le deuxième serveur, de répartir les bases de données sur les deux serveurs, chaque serveur étant le secours de l’autre (configuration failover croisée).