Desactiver ACTIVE DATAGUARD

6 Mars 2018

Hello,
Oracle Active Dataguard a été introduit avec la version 11g. Qu'est ce donc ? Tout simplement la possibilité d'avoir sa base standby ouverte tout en continuant à appliquer les transactions provenant de la base primaire.
Très pratique afin d'utiliser sa base de secours par exemple comme base décisionnelle.

Petit problème : Autant Dataguard est inclus dans la licence Enterprise, autant Active Dataguard est soumis à ce que Oracle appelle un "Extra Cost"... Dit autrement ... Faut raquer pour l'utiliser.
Cela n'est ni la première, ni la dernière option payante d'ORacle. Cependant, à moins d'être pointilleux à l'extrême sur l'accès à vos bases, vous n'êtes pas à l'abri qu'une personne (DBA ou pas) décide (ou se trompe) et ouvre la base de secours.... Et la sans même vous en rendre compte vous venez d'activer "Active Dataguard"... Attention à l'audit...

Assez parlé, vous commencez à connaitre mon environnement...

DGMGRL>
DGMGRL> show configuration

Configuration - mapogos

  Protection Mode: MaxPerformance
  Members:
  rastadb   - Primary database
    rastastby - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 42 seconds ago)

DGMGRL>

Et maintenant, je vais regarder plus en détail ma base de secours.

DGMGRL>
DGMGRL> show database rastastby

Database - rastastby

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 4.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    rastastby

Database Status:
SUCCESS

Ca a l'air plutôt normal.
Et maintenant, depuis mon serveur de secours une personne ne pensant pas à mal lance un sqlplus et ...

SQL>
SQL> alter database open;

Database altered.

SQL>

Petite cause, grosses conséquences...

DGMGRL>
DGMGRL> show database rastastby

Database - rastastby

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 5.00 KByte/s
  Real Time Query:    ON
  Instance(s):
    rastastby

Database Status:
SUCCESS

La base est toujours en "Apply-On" et le Real Time Query est passé à ON.
Vous doutez encore...

SQL>
SQL>
SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY WITH APPLY

SQL>

Sans le savoir (ou pas) vous être en train d'utiliser "Active Dataguard"....
Et si il en reste qui doutent...
Sur ma base primaire (rastadb)

SQL>
SQL> create table active_dg (i number);

Table created.

SQL> insert into active_dg values (6);

1 row created.

SQL> commit;

Commit complete.

SQL>

Et sur mon serveur de secours..

SQL>
SQL>
SQL> select * from active_dg;

         I
----------
         6

SQL>

Plus de doute ! Nous avons vu que cette option peut facilement s'activer et sans pour autant en faire usage volontairement....
Et maintenant...
Certain me diront que j'ai fait un "alter database open" et qu'il suffisait de faire un "Open database read only"..
Oui..je répondrai que dans mon cas la base était également en read-only... et que le problème n'est pas sur le READ ONLY mais sur le "WITH APPLY" :)... Mais bon... je suis dans un bon jour, donc testons.

SQL>
SQL> alter database open read only;

Database altered.

SQL>
SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY WITH APPLY

SQL>

Nous en sommes au même point..
Il faut en fait désactiver l'apply avant d'ouvrir la base.

DGMGRL>
DGMGRL> edit database rastastby set state='APPLY-OFF';
Succeeded.
DGMGRL>

Vérifions..

SQL> alter database open;

Database altered.

SQL>
SQL>
SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY

SQL>

Une fois ce que l'on a faire, il faut alors repasser la base ne mount et ne pas oublier de repasser l'apply à ON...
Je ne vous cache pas qu'avec ces manipulations, on fait intervenir le risque humain qui est quand même à l'origine de pas mal de soucis..
Au final que faire si je veux être certains de ne pas activer mon option "Active Dataguard"... Ouvrir un ticket chez Oracle.. y en a qui ont essayé...
Il existe cependant un de ces fameux paramètre caché qui peut nous aider. Cependant Oracle vous mettra en garde sur l'utilisation de ce type de paramètre.. Sont bien gentils, mais ils proposent rien d'autres...Ah si.. Sortez le pognon & achetez vous la licence..
Let's go !
Remarque : La modification de ce paramètre nécessite un arrêt / relance de votre instance.

SQL> alter system set "_query_on_physical"=FALSE scope=spfile;

System altered.

SQL>
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup mount;
ORACLE instance started.

Total System Global Area 1241513984 bytes
Fixed Size                  8620176 bytes
Variable Size             452986736 bytes
Database Buffers          771751936 bytes
Redo Buffers                8155136 bytes
Database mounted.
SQL>

En parallèle, j'ai réactivé l'APPLY sur ma standby.

DGMGRL> show database rastastby

Database - rastastby

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 1.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    rastastby

Database Status:
SUCCESS

DGMGRL>

Et maintenant que se passe t-il si j'essaye d'ouvrir ma standby database.

SQL>
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-16669: instance cannot be opened because the Oracle Active Data Guard
option is disabled

SQL>

Plus de risque d'ouvrir par erreur ma standby !
Je pourrai toujours l'ouvrir en read / only mais à la seule condition d'avoir désactiver au préalable l'apply... Je vous laisse tester ;)

Remarque : la modification de ce paramètre caché nécessite un arrêt / relance (je sais, je me repête). Il sera donc facile à mettre en place sur une standby... Mais il faudra garder en mémoire d'effectuer également la modification sur la base primaire... car en cas de switchover... c'est votre base primaire qui deviendra standby ;)

Remarque : De mon coté, j'aurai tendance à utiliser symptomatiquement la couche grid & Oracle Restart. Et pour stopper / demarrer les instances utiliser srvctl plutôt que sqlplus. Je vous expliquerai pourquoi dans un prochain article...

Enjoy !