Après avoir configuré votre managed standby et installé la supervision qui vous permet de vérifier que vos bases de données restent synchro, la question qui vient immediatement est « Comment Basculer vos standby en primaire ? ». « Les discours les plus courts étant toujours les moins longs », vous trouverez ci-dessous 2 exemples de bascule qui utilisent la configuration décrite dans mon article précédent, Configurer une « Managed Standby » en 4 étapes.

Switchover

L’opération de switchover consiste à basculer des environnements tout en les laissant synchronisés. Un switchover est constitué des 3 étapes ci-dessous :

• Informer la base primaire qu’elle va devenir Standby
• Basculer la standby en primaire
• Redémarrer la nouvelle Standby et s’assurer de la synchro

Pour le détail de ces opérations, je vous invite à lire la documentation associée.

Informer la base primaire qu’elle va devenir Standby

Pour commencer, il faut que les environnements soient synchronisés, la requête ci-dessous montre un problème dans votre configuration :

select switchover_status 
   from v$database;

SWITCHOVER_STATUS
--------------------
FAILED DESTINATION

Il faut que cette requête indique TO STANDBY ou SESSIONS ACTIVE; si (et seulement si) c’est le cas vous pouvez indiquer à votre base primaire qu’elle va devenir standby :

alter database 
   commit to switchover to physical standby
   with session shutdown;

Une fois l’opération terminée, le statut de votre base passe à RECOVERY NEEDED :

select switchover_status 
   from v$database;

SWITCHOVER_STATUS
--------------------
RECOVERY NEEDED

Vous devez passer votre base de données en mode MOUNT

startup force mount;

Basculer la standby en primaire

Vous voilà prêt à passer la standby en base primaire ; vérifier que le statut de la base de données est TO PRIMARY ou SESSIONS ACTIVE :

select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
TO PRIMARY

Puis passer la base de données en mode primaire et ouvrez-là :

alter database 
   commit to switchover to primary 
   with session shutdown ;

alter database open;

Vous pouvez vérifier que l’application se connecte à la nouvelle base primaire en interrogeant v$session. Le cas échéant changer ses descripteurs de connexion.

Redémarrer la nouvelle Standby et s’assurer de la synchro

Vous pouvez désormais activer votre nouvelle standby en lançant la commande ci-dessous :

alter database 
   recover managed standby database 
   disconnect from session;

Note :
Si vous avez des standby redologs utiliser la clause using current logfile facilitera leur utilisation mais ce n’est pas obligatoire.

Il vous reste, comme dans l’article précédent à reconfigurer le log transport sur votre nouvelle base de données primaire :

alter system set fal_server='black-server:1521/BLACK'; 
alter system set log_archive_dest_2=
   'service=black-server:1521/BLACK async noaffirm valid_for=(online_logfile,primary_role) reopen=60 db_unique_name=BLACK';
alter system set log_archive_dest_state_2=enable;
alter system archive log current;

col destination format a50
select destination, status, archived_thread#, archived_seq#
  from v$archive_dest_status
 where status not in ('DEFERRED', 'INACTIVE');

DESTINATION                              STATUS ARCHIVED_THREAD# ARCHIVED_SEQ#
---------------------------------------- ------ ---------------- -------------
/u01/app/oracle/oradata/WHITE/archivelog  VALID                1            31
black-server:1521/BLACK                   VALID                1            30

Vous pouvez vérifier sur votre nouvelle standby que le recover fonctionne correctement :

select process, client_process, thread#, sequence#, status
  from v$managed_standby;

PROCESS   CLIENT_P    THREAD#  SEQUENCE# STATUS
--------- -------- ---------- ---------- ------------
ARCH      ARCH              0          0 CONNECTED
ARCH      ARCH              0          0 CONNECTED
ARCH      ARCH              0          0 CONNECTED
ARCH      ARCH              1         30 CLOSING
MRP0      N/A               1         32 WAIT_FOR_LOG
RFS       LGWR              1         32 IDLE
RFS       ARCH              0          0 IDLE
RFS       UNKNOWN           0          0 IDLE

Failover

Pour basculer votre base de données standby avec un failover, vous vérifierez d’abord que la base est synchronisée autant que possible. Le cas échéant, utilisez la commande alter system flush redo to ... et/ou enregistrerez les archivelogs à la main comme décrit dans décrit dans la section correspondante de la documentation. Une fois l’opération réalisée, vérifiez que vous pouvez basculer :

select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
NOT ALLOWED

Arrêtez et terminez l’apply :

alter database 
   recover managed standby database cancel;
alter database 
   recover managed standby database finish;
select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
TO PRIMARY

Avant d’ouvrir la standby en production, réfléchissez à ce que vous ferez de votre base de données primaire. Il faut peut-être éviter que votre application puisse se connecter aux 2 bases de données :

alter database 
   commit to switchover to primary
   with session shutdown;

alter database open;

Vous pouvez désormais basculer votre application ou vous servir de votre base comme d’un environnement de test. A moins d’être assuré de récupérer votre base de données primaire et d’avoir des flashbacklogs, n’oubliez pas de faire une sauvegarde ou de remettre en place une nouvelle standby avant de recommencer…