Blog

Flashback et Snapshot Standby en Action

Qui utilise une base de données Oracle et n’a jamais besoin ?

  • d’investiguer les causes d’un problème constaté en production quelques minutes/heures auparavant
  • de tester une correction ou une évolutions et comparer le résultat à celui de la production
  • de ré-exécuter un batch après correction de données et réintégrer le résultat en production
  • de simuler des modifications pour des raisons techniques ou métier

Pour tous ces scénarios, une base de données standby est très utile et peut être ouverte en lecture-écriture… sans « Active Data Guard » mais simplement avec Flashback Logs et Snapshot Standby.

Cet article illustre comment combiner ces 2 fonctionnalités, faire reculer la base de données de standby et l’ouvrir en lecture écriture. Une fois vos tests réalisés, vous pourrez resynchroniser base de données primaire et standby…

Environnement exemple

Pour démontrer les possibilités d’utilisation de Data Guard dans ce contexte, vous commencerez par monter une configuration exemple. Pour ma part, j’ai simplement repris en quelques minutes la configuration décrite dans un article précédent intitulé Comment créer une configuration Data Guard en 5 minutes. La configuration est très vite en place :

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

Activer flashback database sur la Standby

Le script ci-dessous active les flashback logs sur la standby. Pour cela, vous devrez préalablement désactiver les processus d’apply et le réactiver ensuite. Vous pouvez tout exécuter depuis la ligne de commande dgmgrl à condition d’être connecté à la standby et avec l’aide du mot clé « sql » :

dgmgrl sys/manager@white
edit database white set state='apply-off';
show database white;

Database - white

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-OFF
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: OFF
  Instance(s):
    WHITE

Database Status:
SUCCESS

sql "alter system set db_recovery_file_dest_size=5G";
sql "alter system set db_recovery_file_dest='/u01/app/oracle/fra'";
sql "alter database flashback on";

edit database white set state='apply-on';
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

Schéma exemple

Pour illustrer notre propos, créons un utilisateur DEMO et une table T sur la base de données primaire :

. oraenv
BLACK

sqlplus / as sysdba
create user demo identified by demo default tablespace users;
grant connect, resource to demo; 
connect demo/demo
create table t(id number);
insert into t values (1);

Capturons l’heure à laquelle nos données sont valides :

alter session set nls_date_format='DD/MM/YYYY HH24:MI:SS';
select sysdate from dual;

SYSDATE
-------------------
06/01/2012 23:22:50

Flashback de la Standby

Imaginons un instant que le schéma DEMO est supprimé de la base de données primaire :

. oraenv
BLACK
sqlplus / as sysdba
drop user demo cascade;
exit

Vérifiez, en passant la base de données de standby en lecture seule, que le schéma a également été supprimé de la standby :

dgmgrl sys/manager@white

edit database white set state='read-only';

exit;

. oraenv
WHITE

sqlplus / as sysdba

select * from demo.t;
                   *
ERROR at line 1:
ORA-00942: table or view does not exist

exit;

Vous pourrez faire « reculer » la base de données standby dans le temps avec la commande flashback standby database, toujours depuis dgmgrl. Pour cela, repasser la base de données en mode MOUNT :

dgmgrl sys/manager@white

DGMGRL> edit database white set state='apply-off';
Succeeded.
DGMGRL> show database white; 

Database - white

 Role:            PHYSICAL STANDBY
 Intended State:  APPLY-OFF
 Transport Lag:   0 seconds
 Apply Lag:       4 minutes 18 seconds
 Real Time Query: OFF
 Instance(s):
   WHITE

Database Status:
SUCCESS

Et lancer la commande flashback :

sql "flashback standby database to timestamp cast(to_date('06/01/2012 23:22:50','DD/MM/YYYY HH24:MI:SS') as timestamp)";

Voici le schéma normalement à nouveau disponible sur la standby. Ouvrez la base de données en mode lecture et écriture pour faire vos tests :

convert database white to snapshot standby;

exit

Vérifiez que vous avez accès au schéma avant la commande DROP et que vous êtes bien en mode lecture/écriture pour vos tests :

. oraenv
WHITE

sqlplus / as sysdba

select * from demo.t;

 ID
----------
  1

insert into demo.t values(2);

select * from demo.t;

 ID
----------
  2
  1

La synchronisation continue…

Même si votre standby est utilisée à d’autres fins, la synchronisation des archivelogs continue ce qui lui permet de continuer à servir de secours à sa base de données primaire. Vous pouvez le vérifiez en changeant le fichier redo sur la base de données primaire : 

select process, STATUS, SEQUENCE# from v$managed_standby;

PROCESS   STATUS SEQUENCE#
--------- ------------ ----------
ARCH   CLOSING  1
ARCH   CONNECTED  0
ARCH   CONNECTED  0
ARCH   CLOSING       212
RFS   IDLE   0
RFS   IDLE        213
RFS   IDLE   0

exit

. oraenv
BLACK
sqlplus / as sysdba

alter system archive log current;
exit

. oraenv
WHITE
sqlplus / as sysdba

select process, STATUS, SEQUENCE# from v$managed_standby;

PROCESS   STATUS SEQUENCE#
--------- ------------ ----------
ARCH   CLOSING  1
ARCH   CONNECTED  0
ARCH   CONNECTED  0
ARCH   CLOSING       212
RFS   IDLE   0
RFS   IDLE        214
RFS   IDLE   0

exit

Revenir au mode nominal

Une fois vos tests réalisés, vous pouvez revenir en mode nominal et convertir à nouveau votre standby ; les flashback logs sont également mis à contribution dans cette phase mais sans que vous ayez à utiliser explicitement la commande flashback :

dgmgrl sys/manager@white
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 ins
tance "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

show database white;

Database - white

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   51 seconds
  Apply Lag:       51 seconds
  Real Time Query: OFF
  Instance(s):
    WHITE

Database Status:
SUCCESS

La standby est réalignée

Par curiosité, passez à nouveau la standby en mode lecture seule et vérifiez que le schéma à de nouveau disparu :

edit database white set state='read-only';
exit

. oraenv
WHITE

sqlplus / as sysdba
select * from demo.t;
                   *
ERROR at line 1:
ORA-00942: table or view does not exist

Le meilleur pour la fin…

L’ensemble de ces capacités sont disponibles en version Enterprise Edition et ne nécessitent pas l’option Active Data Guard. Pour vérifier, référez-vous à la section correspondante du Licensing Guide ; vous constaterez que Active Data Guard inclut uniquement

  • la capacité d’interroger une base de données alors que les processus MRP sont actifs ou Real-Time Query, 
  • la capacité de réparation automatique des blocs illustrée dans cet article,
  • l’utilisation du BCTF ou Fast Incremental Backup sur la standby

Et voilà!

Thomas Bordet
Thomas Bordet
Voir tous ses articles
Articles récents

Mentions légales & Politique de confidentialité