Blog

le 03/10/2009
Thomas Bordet
Infrastructures

Oracle 11g Release 2 Data Guard (2/5) : Compression, Snapshot Standby, Real Time Query, etc

Vous allez, à travers ce second article, continuer l’exploration d’Oracle Data Guard. Il s’agit, cette fois, d’illustrer et de mettre en oeuvre quelque-unes des possibilités offertes par le broker et par les options Active Data Guard et Advanced Compression. En particulier, les thèmes suivants sont abordés :

Comment changer le mode de protection sans indisponibilité en Oracle 11g Release 2 ?
Comment et que peut-on attendre de la compression offerte par le service d’envoi des logs d’Oracle 11g Release 2 Advanced Compression ?
Comment, avec Active Data Guard et le Broker, activer la snapshot standby puis revenir à la configuration physical standby ?
Comment, avec Active Data Guard et le Broker, activer Real Time Query sur la physical standby ?

Cet article est le second d’une série plus large que je vous invite à découvrir ci-dessous :

Le 1er article, présente comment créer une configuration Data Guard en 5 minutes, en plus du temps de copie de la base de données et comment effectuer une transition des roles des bases de données
Le 2nd article (celui-ci), présente comment changer le mode de protection, activer la compression, Snapshot Standby et Real Time Query
Le 3ème article illustre le fonctionnement de la correction automatique de blocs corrumpus sur la base de données primaire et standby
Le 4ème article démontre comment garantir la fraicheur des données sur la standby
Le 5ème article illustre l’utilisation du Block Change Tracking File sur la base standby et l’utilisation de la commande recover database noredo pour gérer la perte d’un fichier archivelog

Il me semble qu’il s’agit d’un tour d’horizon assez complet de l’état de l’art de Data Guard en 11g Release 2. Bien sur, si vous avez d’autres idées, n’hésitez pas à les partager en laissant vos commentaires.

Préambule

Prêt ?
Si vous voulez exécuter les commandes de cet article, il vous faut une configuration Data Guard opérationnelle avec le broker; c’est l’objet de l’article précédent intitulé « Oracle 11g Release 2 Data Guard (1/5) : 5 minutes pour créer une configuration« …
Prêt ?

Changer le mode de protection de votre configuration sans indisponibilité

Le mode de protection permet de définir simplement le niveau de protection de vos données et transactions. Pour changer ce mode de protection, il suffit d’utiliser la commande du broker edit configuration set protection mode as (maxperformance|maxavailability|maxprotection). Avec Oracle 11g Release 2, il est possible de changer de mode de protection sans arrêter la base de données primaire; la seule contrainte est que vous ne pouvez pas passer directement de maxperformance à maxprotection; il faut que vous passiez par maxavailability. D’autre part vous noterez que pour changer de mode il faut que les conditions techniques soient réunies. Par exemple, vous ne pourrez pas passer en mode maximum availability si le transport des logs n’est pas en mode synchrone :

show database verbose black 'LogXptMode';
 LogXptMode = 'ASYNC'
show database verbose white 'LogXptMode';
 LogXptMode = 'ASYNC'
edit configuration set protection mode as maxavailability;
Error: ORA-16627: operation disallowed since no standby databases
would remain to support protection mode
Failed.

Pour passez de maxperformance à maxavailability, exécutez ce qui suit :

edit database black  set property LogXptMode=SYNC;
Property "logxptmode" updated
edit database white set property LogXptMode=SYNC;
Property "logxptmode" updated
show database verbose black 'LogXptMode';
 LogXptMode = 'sync'
show database verbose white 'LogXptMode';
 LogXptMode = 'sync'
edit configuration set protection mode as maxavailability;
Succeeded.
show configuration verbose;

Configuration - worldwide
 Protection Mode: MaxAvailability
 Databases:
 black - Primary database
 white - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

Compression du service de transport des logs

Pour activer la compression du service de transport, il suffit de changer les propriétés RedoCompression depuis le broker, comme ci-dessous :

edit database black set property RedoCompression='ENABLE';
Property "redocompression" updated
edit database white set property RedoCompression='ENABLE';
Property "redocompression" updated

Les propriétés positionnent dans le paramètre log_archive_dest_n comme vous pourrez vous en rendre compte en interrogeant l’instance :

select value from v$parameter where name='log_archive_dest_2';
VALUE
--------------------------------------------------------------------------------
service="white", LGWR SYNC AFFIRM delay=0 optional compression=enable max_failur
e=0 max_connections=1 reopen=300 db_unique_name="white" net_timeout=30, valid_fo
r=(all_logfiles,primary_role)

Note:
J’ai construit un test pour se faire une idée des taux de compressions qu’on peut obtenir par cette méthode. L’idée est de pouvoir comparer cette méthode à des méthodes de compression au niveau du réseau, par exemple. Les résultats sortent largement du cadre de cet article mais, j’y reviendrai sans doute d’ici quelques semaines. Je suis assez curieux de vos propres conclusions.

Activer la Snapshot Standby puis resynchroniser la Standby

Une snapshot standby est une standby physique que vous avez ouverte en mode lecture/écriture pour vos tests. Lorsque vous utilisez une snapshot standby, les redologs et archivelogs de la base de données primaire continuent d’être envoyés sur le site de standby ce qui permet d’assurer la protection du site primaire quoiqu’il arrive. Pour revenir en mode physical standby, vous utilisez le « retention point » créé au moment de l’activation de la snapshot standby ainsi que les flashback logs et archivelogs.
Pour activer la snapshot standby, il suffit d’utiliser la commande convert database comme ci-dessous :

dgmgrl sys/change_on_install@black
DGMGRL for Linux: Version 11.2.0.1.0 - Production
show configuration;
Configuration - worldwide
  Protection Mode: MaxPerformance
  Databases:
    black - Primary database
    white - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
convert database white to snapshot standby;
Converting database "white" to a Snapshot Standby database, please wait...
Database "white" converted successfully

La snapshot standby est activé; vous pourrez constater que la base de données est ouverte en vous connectant :

sqlplus sys/change_on_install@white as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mon Sep 28 23:09:02 2009
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
select instance_name from v$instance;
INSTANCE_NAME
----------------
WHITE
show parameter db_unique_name;
NAME           TYPE   VALUE
-------------- ------ --------
db_unique_name string WHITE
select name, open_mode  from v$database;
NAME      OPEN_MODE
--------- --------------------
BLACK      READ WRITE
exit

Pour réactiver la base de données standby, il suffit d’utiliser une fois encore la commande convert database comme ci-dessous :

dgmgrl sys/change_on_install@black
DGMGRL for Linux: Version 11.2.0.1.0 - Production
show configuration;
Configuration - worldwide
  Protection Mode: MaxPerformance
  Databases:
    black - Primary database
    white - Snapshot standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
convert database white to physical standby;
Converting database "white" to a Physical Standby database, please wait...
Operation requires shutdown of instance "WHITE" on database "white"
Shutting down instance "WHITE"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "WHITE" on database "white"
Starting instance "WHITE"...
ORACLE instance started.
Database mounted.
Continuing to convert database "white" ...
Operation requires shutdown of instance "WHITE" on database "white"
Shutting down instance "WHITE"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "WHITE" on database "white"
Starting instance "WHITE"...
ORACLE instance started.
Database mounted.
Database "white" converted successfully

Vous pouvez maintenant vérifier que la base de données et de nouveau une base de données standby:

show configuration;
Configuration - worldwide
  Protection Mode: MaxPerformance
  Databases:
    black - Primary database
    white - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
exit
sqlplus sys/change_on_install@white as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mon Sep 28 23:13:13 2009
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
select instance_name from v$instance;
INSTANCE_NAME
----------------
WHITE
show parameter db_unique_name
NAME           TYPE   VALUE
-------------- ------ -------
db_unique_name string WHITE
select name, open_mode from v$database;
NAME      OPEN_MODE
--------- ---------
BLACK      MOUNTED
select process, status, thread#, sequence#
   from v$managed_standby
 where process='MRP0';
PROCESS   STATUS	  THREAD#  SEQUENCE#
--------- ------------ ---------- ----------
MRP0	  APPLYING_LOG		1	  27
exit

Active Standby (aka Real Time Query)

Active Data Guard permet d’ouvrir une base de données physical standby en mode lecture seule alors qu’elle continue à se synchroniser avec sa base de données primaire. Pour démarrer la base active standby, il suffit de l’arrêter et de l’ouvrir en mode « open ». Vous pouvez effectuer cette opération depuis le broker comme ci-dessous :

show database white;
Database - white
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: OFF
  Instance(s):
    WHITE
Database Status:
SUCCESS
edit database white set state='APPLY-OFF';
Succeeded.
connect sys/change_on_install@white
Connected.
shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
help startup
Starts an Oracle database instance
Syntax:
  STARTUP [RESTRICT] [FORCE] [PFILE=]
        [MOUNT | OPEN [READ ONLY|READ WRITE]] [NOMOUNT];
startup open
ORACLE instance started.
Database mounted.
Database opened.
show database white;
Database - white
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   (unknown)
  Apply Lag:       (unknown)
  Real Time Query: OFF
  Instance(s):
    WHITE
  Database Error(s):
    ORA-16766: Redo Apply is stopped
Database Status:
ERROR
edit database white set state='APPLY-ON';
Succeeded.
show database white;
Database - white
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: ON
  Instance(s):
    WHITE
Database Status:
SUCCESS
exit;

Vous pouvez vérifier l’état de la base de données en interrogeant la colonne open_mode de la vue v$database :

sqlplus sys/change_on_install@white as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mon Sep 28 23:50:40 2009
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
select name, open_mode from v$database;
NAME	  OPEN_MODE
--------- --------------------
BLACK	  READ ONLY WITH APPLY
exit;

Pour réactiver la base de données standby normal, sans Real-Time Query, arrêtez la et redémarrez la en mode mount :

dgmgrl sys/change_on_install@white
shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
startup mount
ORACLE instance started.
Database mounted.
show database white;
Database - white
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: OFF
  Instance(s):
    WHITE
Database Status:
SUCCESS

Parmi les bizarreries d’active Data Guard, la vue qui indique les fonctionnalités utilisées ne semble pas renvoyer le bon statut d’utilisation :

select detected_usages, CURRENTLY_USED
    from DBA_FEATURE_USAGE_STATISTICS
   where NAME='Active Data Guard - Real-Time Query on Physical Standby';
DETECTED_USAGES CURRE
--------------- -----
	      0 FALSE
select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY

Conclusion

Voilà qui termine le second article de cette série consacrée à Data Guard. Dans le prochain article, vous découvrirez comment tester les nouvelles fonctionnalités de correction automatique des blocs corrompus qui viennent avec Active Data Guard…

Thomas Bordet

Voir tous ses articles

7 réflexions sur “Oracle 11g Release 2 Data Guard (2/5) : Compression, Snapshot Standby, Real Time Query, etc”

Ping : Active Data Guard 11g Release 2 (5/5) : BCTF et RECOVER NOREDO sur la Standby | EASYTEAM LE BLOG
Ping : Oracle Database 11g Release 2 Data Guard (7/5): Observer et Fast Start Failover « EASYTEAM LE BLOG
Ping : Oracle Database 11g Release 2 Data Guard (6/5): Créer une standby logique avec le broker « EASYTEAM LE BLOG
lapicol
04/03/2010 à 01:57

Bonjour,
> Dis, c’est normal que quand tu passes en RTQ, dans l’étape ou du la mets en apply off, le broker indique apply-on après le redémarrage ? Oui c’est normale car la base a été arretée et redémarée (par defaut apply-on c’est une standby).
>Pour démarrer la base active standby, il suffit de l’arrêter et de l’ouvrir en mode « open ».
Pas besoin de l’arreter et de la redémarrer il suffit:
edit database white set state=’APPLY-OFF’;
alter database open read only;
edit database white set state=’APPLY-ON’;
Good luck
Pour démarrer la base active standby, il suffit de l’arrêter et de l’ouvrir en mode « open ».
1. lapicol
  04/03/2010 à 01:59
  
  Bonjour,
  > Dis, c’est normal que quand tu passes en RTQ, dans l’étape ou du la mets en apply off, le broker indique apply-on après le redémarrage ? Oui c’est normale car la base a été arretée et redémarée (par defaut apply-on c’est une standby).
  >Pour démarrer la base active standby, il suffit de l’arrêter et de l’ouvrir en mode « open ».
  Pas besoin de l’arreter et de la redémarrer il suffit:
  edit database white set state=’APPLY-OFF’;
  alter database open read only;
  edit database white set state=’APPLY-ON’;
  Good luck
Ping : Oracle 11g Release 2 Data Guard (4/5) : Garantir la fraicheur de vos requêtes « EASYTEAM Le BLOG
Arnaud Ladrière
08/10/2009 à 11:22

Dis, c’est normal que quand tu passes en RTQ, dans l’étape ou du la mets en apply off, le broker indique apply-on après le redémarrage ? Je trouve cela pas génial.

Les commentaires sont fermés.