Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter

Abonnez-vous maintenant et nous vous tiendrons au courant.
Nous respectons votre vie privée. Vous pouvez vous désabonner à tout moment.

Synchronisation standby avec Dbvisit

Partager sur linkedin
Partager sur twitter
Partager sur facebook
INTRODUCTION

Lorsqu’une base Primaire est désynchronisée de sa base Standby, il existe plusieurs méthodes pour revenir en état nominal.

Les exemples principaux sont RMAN DUPLICATE FROM ACTIVE ou FROM BACKUP ou si supérieur à la version 12c RESTORE FROM SERVICE.

Il s’agit ici de rattrapages pour des versions Oracle Entreprise avec la solution Dataguard en place.

Mais pour les versions Standards utilisant l’outil dbvisit, cette resynchronisation est encore plus simple car une seule commande suffit à restaurer votre base standby.

ANALYSE

Via dbvisit, on remarque que la base standby est désynchronisée depuis au moins 23 jours.

oracle@[PRIMAIRE]> /usr/dbvisit/standby/dbvctl -d <BASE> -i
=============================================================
Dbvisit Standby Database Technology (9.0.12_0_g1268187) (pid 11997)
dbvctl started on dbv-prod-vip: Thu Nov 19 17:45:14 2020
=============================================================

Dbvisit Standby log gap report for <BASE> at 202011191745: ------------------------------------------------------------- Description | SCN | Timestamp ------------------------------------------------------------- Source 6913521764 2020-11-19:17:45:19 +01:00 Destination 6840854840 2020-10-27:16:00:06 +01:00
Standby database time lag (DAYS-HH:MI:SS): +23 DAYS 01:45:13

Report for Thread 1 ------------------- SOURCE Current Sequence 71515 Last Archived Sequence 71514 Last Transferred Sequence 70895 Last Transferred Timestamp 2020-10-27 16:00:29 DESTINATION Next Required Recovery Sequence 70895
Transfer Log Gap 619 Apply Log Gap 620

Report for Thread 2
-------------------
SOURCE
Current Sequence 65312
Last Archived Sequence 65311
Last Transferred Sequence 64724
Last Transferred Timestamp 2020-10-27 16:00:29

DESTINATION
Next Required Recovery Sequence 64724

Transfer Log Gap 586
Apply Log Gap 587

=============================================================
dbvctl ended on dbv-stby-vip: Thu Nov 19 17:45:26 2020
=============================================================

Malheureusement, les archivelogs ne sont plus présentes sur la Primaire et ne peuvent donc pas être restaurées puis envoyées à la standby.

[PRIMAIRE]
RMAN> RESTORE ARCHIVELOG FROM SEQUENCE 70896 UNTIL SEQUENCE 71000 THREAD 1 ; Starting restore at 19/11/2020 17:47:12 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=2329 instance=<INSTANCE_NAME_1> device type=DISKRMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 11/19/2020 17:47:13 RMAN-06026: some targets not found - aborting restore RMAN-06025: no backup of archived log for thread 1 with sequence 70900 and starting SCN of 6841296436 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 70899 and starting SCN of 6841219152 found to restore
[...]
RMAN-06025: no backup of archived log for thread 1 with sequence 71000 and starting SCN of 6851985900 found to restore

La solution reste donc la resynchonisation qu’il est alors possible d’effectuer avec une seule commande dbvisit.

SYNCHRONISATION
oracle@[PRIMAIRE]> /usr/dbvisit/standby/dbvctl -d  -D stop
Stopping Dbvisit Daemon...
Successfully stopped.

oracle@[STANDBY]> /usr/dbvisit/standby/dbvctl -d -D stop
Stopping Dbvisit Daemon...
Successfully stopped.

oracle@[PRIMAIRE]> /usr/dbvisit/standby/dbvctl -d --sync
-------------------------------------------------------------------------------
Use RMAN incremental backups to synchronise a physical standby database with the primary database.
RMAN incremental backup of the primary database will be created, starting at the current SCN of the standby, which in turn will then be used to roll the standby database forward in time. RMAN incremental backups can be useful in case the physical standby database: Is lagging far behind the primary database. Has widespread nologging changes. Has nologging changes on a subset of datafiles. -------------------------------------------------------------------------------
Continue? <Yes/No> [Yes]:
-------------------------------------------------------------------------------
SUMMARY
-------------------------------------------------------------------------------
SOURCE dbv-stby-vip Current SCN: 6913530027
Time: 2020-11-19:17:51:47

DESTINATION
dbv-prod-vip Next SCN required for recovery: 6840854840
Time: 2020-10-27:16:00:06

Time difference between SOURCE and DESTINATION: +23 DAYS 01:51:41
No Nonlogged transactions detected in the following datafiles on DESTINATION:
-------------------------------------------------------------------------------
=>Synchronize standby database using incremental backups from SCN 6840854840? [Y]:Y Your input: Y
Is this correct? <Yes/No> [Yes]:

-------------------------------------------------------------------------------
TRANSPORTABLE MEDIA can be used to transfer the database backup to the standby server. Transportable media is an external device such as a USB drive that is first plugged into the primary server and then manually transferred to the standby site and plugged into the standby server to continue the process. It can be used for large databases or slow networks. Specifying No means the network will be used to transfer the database backup.

=>Do you want to use TRANSPORTABLE MEDIA? [N]: N Your input: N
Is this correct? <Yes/No> [Yes]:

-------------------------------------------------------------------------------
A temporary location must be specified on dbv-prod-vip where the database willbe backed up to first. This location must be big enough to hold RMAN incremental backup of the primary database).
=>Specify the location on dbv-stby-vip: [/orabackup/dbvisit_primary]: Your input: /orabackup/dbvisit_primary
Is this correct? <Yes/No> [Yes]:

-------------------------------------------------------------------------------
A temporary location must be specified on dbv-stby-vip where the backup will be copied to before being applied. This location must be big enough to hold RMAN incremental backup of the primary database).
=>Specify the location on dbv-prod-vip: [/var/ORADMP/dbvisit_ARCHDEST]: /backup/dbvisit_standby Your input: /backup/dbvisit_standby
Is this correct? <Yes/No> [Yes]:

Synchronising Standby Database
-------------------------------------------------------------------------------
>>> Deleting previous incremental backup... done
>>> Creating incremental backup of primary database... done
>>> Creating standby control file... done
>>> Transferring backup to standby server... done
>>> Restoring standby control file... done
>>> Cataloguing incremental backup in RMAN catalogue... done
>>> Applying incremental backup to the standby database... done
>>> Performing checkpoint and archiving logs... done
>>> Synchronising standby... done
>>> Obtaining sync summary... done
>>> If a primary node was down during sync operation, you need to run dbvctl with -R option on this node.
POST-ACTIONS

Il ne reste plus qu’à rallumer les process dbvist et se s’assurer que la configuration soit synchronisée.

oracle@[PRIMAIRE]> /usr/dbvisit/standby/dbvctl -d  -D start
Starting Dbvisit Daemon...
Successfully started.


oracle@[STANDBY]> /usr/dbvisit/standby/dbvctl -d -D start
Starting Dbvisit Daemon...
Successfully started.


oracle@[PRIMAIRE]> /usr/dbvisit/standby/dbvctl -d <BASE> -i ============================================================= Dbvisit Standby Database Technology (9.0.12_0_g1268187) (pid 25698) dbvctl started on dbv-prod-vip: Thu Nov 19 19:32:10 2020 =============================================================
Dbvisit Standby log gap report for <BASE> at 202011191745: ------------------------------------------------------------- Description | SCN | Timestamp ------------------------------------------------------------- Source 6913521764 2020-11-19:19:31:59 +01:00 Destination 6840854840 2020-11-19:19:30:45 +01:00
Standby database time lag (DAYS-HH:MI:SS): +0 DAYS 00:01:14

Report for Thread 1
-------------------
SOURCE
Current Sequence 71515
Last Archived Sequence 71514
Last Transferred Sequence 71514
Last Transferred Timestamp 2020-11-19 19:31:59

DESTINATION
Next Required Recovery Sequence 71515
Transfer Log Gap 0
Apply Log Gap 1

Report for Thread 2
-------------------
SOURCE
Current Sequence 65312
Last Archived Sequence 65312
Last Transferred Sequence 65312
Last Transferred Timestamp 2020-11-19 19:25:23

DESTINATION
Next Required Recovery Sequence 65312

Transfer Log Gap 0
Apply Log Gap 0

=============================================================
dbvctl ended on dbv-stby-vip: Thu Nov 19 19:32:41 2020
=============================================================
CONCLUSION

On peut donc remarquer que malgré le fait que l’on soit sur une version Standard sans la possibilité d’avoir le Dataguard (réservé aux versions Enterprise), il est possible d’avoir une solution simple et rapide de gestion de standby avec une resynchronisation semi-automatique.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.