Si vous me suivez au delà de ce blog, vous aurez remarqué mon intérêt pour les séries d’article. Cela permet de creuser un sujet sur plusieurs semaines et de partager des expériences parfois délicates… Et vous ne savez pas tout ;-).

Parmi ces séries et leurs séquelles plus ou moins référencées, vous trouverez notamment une série d’articles sur les installations en ligne de commande. Plus qu’une série, il y a mon blog de 37 articles dédiés à Oracle Streams et, plus récemment, une série de 7 articles à propos des bases de données Standby et Data Guard.

Faire et défaire… bref …

Pourtant malgré les articles, vous tombez toujours sur de nouvelles questions. Par exemple, dans le dernier article consacré à Data Guard, vous constatez que redémarrer la base de données primaire basculée automatiquement par l’Observer Data Guard la ré-instancie automatiquement. Alors qu’en est-il lorsque l’observer n’est pas actif ? Une recherche dans la documentation propose la méthode « 13.2 Converting a Failed Primary Into a Standby Database Using Flashback Database » soit une méthode en 5 étapes… Pourtant depuis Oracle 11.2, il existe beaucoup mieux !

Note:
On supposera que l’ensemble des pré-requis pour la ré-instantiation sont réunis et notamment que les bases de données primaires et standby ont leurs flashback logs actifs. Pour plus de détails reportez-vous à la section 5.5.8 Reinstating the Former Primary Database in the Broker Configuration du document « Oracle Data Guard Broker – 11g Release 2 (11.2) »

Scénario initial

Supposez que vous ayez 2 bases de données nommées BLACK et WHITE; BLACK est la base de données primaire et WHITE sa standby. Toutes les 2 ont leurs flashback logs actifs et le broker data guard est correctement configuré. La configuration initiale ressemble à celle-ci :

dgmgrl sys/change_on_install@black

show configuration verbose

Configuration - worldwide

  Protection Mode: MaxPerformance
  Databases:
    black - Primary database
    white - Physical standby database

  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '30'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

Vous allez, pour les besoins du scénario, arrêter la base de données primaire et basculer sur la standby. Voici le script correspondant :

ps -ef |grep [s]mon |grep BLACK | 
  awk '{print "kill -9",$2}'|sh

dgmgrl sys/change_on_install@white

show configuration

Configuration - worldwide

  Protection Mode: MaxPerformance
  Databases:
    black - Primary database
    white - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
ORA-01034: ORACLE not available
ORA-16625: cannot reach database "black"
DGM-17017: unable to determine configuration status

failover to white;
Performing failover NOW, please wait...
Failover succeeded, new primary is "white"

show configuration

Configuration - worldwide

  Protection Mode: MaxPerformance
  Databases:
    white - Primary database
    black - Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

Vous voilà prêt pour la partie intéressante de cet article. La ré-instantiation de la base de données primaire ou les 5 étapes présentées en début d’articles.

Ré-instanciation

Si vous redémarrez la base de données primaire par inadvertance, l’existence du broker l’empêche de s’ouvrir comme vous le constatez ci-dessous. Pourtant, la base de données reste une base de données primaire :

. oraenv
BLACK

sqlplus / as sysdba

Connected to an idle instance.

startup
ORACLE instance started.

Total System Global Area 1603411968 bytes
Fixed Size      2228784 bytes
Variable Size    402656720 bytes
Database Buffers  1191182336 bytes
Redo Buffers      7344128 bytes
Database mounted.
ORA-16649: possible failover to another database prevents this database from
being opened

select OPEN_MODE, DATABASE_ROLE 
  from v$database;

OPEN_MODE            DATABASE_ROLE
-------------------- ----------------
MOUNTED              PRIMARY

Et maintenant, ré-instanciez la base de données ; il suffit, pour cela, de se connecter à la nouvelle base de données primaire, c’est à dire WHITE et de lancer la commande REINSTATE DATABASE comme ci-dessous :

dgmgrl sys/change_on_install@white

reinstate database black;
Reinstating database "black", please wait...
Operation requires shutdown of instance "BLACK" on database "black"
Shutting down instance "BLACK"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "BLACK" on database "black"
Starting instance "BLACK"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "black" ...
Reinstatement of database "black" succeeded

Comme vous le constatez ci-dessous, la configuration est à nouveau opérationnelle et prête à une prochaine bascule, planifiée ou non :

show configuration

Configuration - worldwide

  Protection Mode: MaxPerformance
  Databases:
    white - Primary database
    black - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS