Oracle RAC One Node - srvctl relocate

Hello !

Petit retour en arrière... En début de semaine, je vous ai parlé de Oracle Rac One Node (ici )
Alors comme je l'indiquais dans l'article précédent, Oracle Rac One Node peut engendrer une certaine confusion au vu de son nom. Pour être tout à fait honnête, il y a quelques années lorsque j'ai entendu parlé de cette nouvelle fonctionnalité.... ma première réaction a été ..."Quel Intérêt... un cluster à un noeud... Ca ne sert à rien.."
Voila, mais comme cela peut m'arriver quelque fois, je parle et je réfléchis après... Oracle Rac

One Node ne signifie pas un RAC à un noeud, mais cela signifie un cluster de n noeuds ou l'instance ne sera démarré que sur l'un des noeuds du cluster !
D'ailleurs j'avais débuté mon article en faisant un petit rappel de ma configuration. A savoir un cluster deux noeuds (mes amis jumbo & romeo).

[oracle@jumbo ~]$
[oracle@jumbo ~]$ olsnodes -n
jumbo   1
romeo   2
[oracle@jumbo ~]$

Remarque : Je suis limité par mon laptop mais rien ne m’empêche d'avoir plus que deux nœuds.
En revanche mon instance elle ne tourne que sur un seul noeud (jumbo)

[oracle@jumbo ~]$
[oracle@jumbo ~]$ srvctl status database -d lami
Instance lami_1 is running on node jumbo
Online relocation: INACTIVE
[oracle@jumbo ~]$

Et si l'on veut plus d'informations.

[oracle@jumbo ~]$ srvctl config database -d lami
Database unique name: lami
Database name: lami
Oracle home: /u01/app/oracle/product/12.2.0.1/db_1
Oracle user: oracle
Spfile: +DATA/LAMI/PARAMETERFILE/spfile.314.973075831
Password file: +DATA/LAMI/PASSWORD/pwdlami.282.973075409
....
Services: lamiOneNode
Type: RACOneNode
Online relocation timeout: 30
Instance name prefix: lami
Candidate servers: jumbo,romeo
OSDBA group: dba
OSOPER group: oper
Database instances: lami_1
....
Database is administrator managed

Alors cela m'offre quand même une certaine "haute disponibilité" que ce soit pour une maintenance planifiée ou un incident.

Au dela des maintenances, par exemple dans le cas d'une architecture virtualisé, rien ne m'empêche d'avoir une VM pour l'usage courant, et par exemple une VM un peu plu gonflé en CPU / Mémoire .. pour des périodes plus critiques (Batches trimestrielles, Soldes ,...)
Et dans ce cas Oracle Rac One Node va permettre de basculer rapidement et de facon plutôt transparante d'un serveur à l'autre.

Comment ? Rien de bien compliqué... une simple commande ou l'on va indiquer sur quel noeud basculer le service.

[oracle@jumbo ~]$srvctl relocate database -d lami -n romeo

A savoir que si des transactions sont en cours, elles vont se terminer sur mon premier noeud, et les nouvelles sessions seront elles initialisées sur le second node : romeo
Pour l'exemple, j'avais lancé une "big" transaction sur le noeud initial. Que constate t-on ?

[oracle@romeo ~]$
[oracle@romeo ~]$  srvctl status database -d lami
Instance lami_2 is running on node romeo
Online relocation: ACTIVE
Source instance: lami_1 on jumbo
Destination instance: lami_2 on romeo
[oracle@romeo ~]$
[oracle@romeo ~]$

C'est relative claire... nous avons les informations de source & de destination. Et cette information "Online relocation : ACTIVE"... que ORacle a gentiment appelé "OMotion"... OMotion / VMotion... vous voyez la subtilité marketing d'Oracle ;)
A savoir que ce statut ne va pas durer indéfiniment... Sinon on n'est plus RAC que RAC ONE Node.. et cela a un cout ;)
Il suffit de remonter un peu dans l'article... au moment du srvctl config database -d lami...

Online relocation timeout: 30
 

30 Minutes... voila la durée ou le "Online relocation" pourra être active...
Il est tard, et j'ai pas poussé pour voir ce qui se passe au bout de 30 minutes... mais risque de shutdown abort sur mon instance initiale... A l'occasion je ferai le test et mettrai à jour l'article.
Après si vous avez déjà testé, n’hésitez pas  à commenter !!!!

Enjoy !