ZDLRA, Dataguard, Archivelogs, and RMAN-08137

1 Reply

When configuring a database with Real-Time Redo at ZDLRA it is important to check the deletion policy for archivelog. This is even more important when the database is protected with dataguard. I already wrote about Real-time Redo in this previous post, and when using with dataguard in another post.  

But sometimes (during maintenance as an example) you can face the error RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process if the deletion policy of archivelog is not aligned with your needs.

Protection Policy

As I already wrote before, the deletion policy when suing ZDLRA is defined by the protection policy inside ZDLRA. Since the rman catalog is auto managed by recovery appliance (and what you defined at your protection policy) usually nothing is needed to do at rman side (like delete backup and others commands) because ZDLRA itself delete and crosscheck backups.

But with archivelog it is a different scenario because ZDLRA can’t manage it at the database side. It is your script (or yourself) that need to manage them. But since that with Real-Time Redo the backup of archivelog is automatically done by ZDLRA, you need to adapt how to delete your archivelogs.

Dataguard Environment

Look the configuration below with dataguard and ZDLRA configured:

DGMGRL> show configuration

Configuration - or19dg

  Protection Mode: MaxAvailability
  Members:
  or19dg  - Primary database
    or19dgs - Physical standby database
      zdlras2 - Recovery appliance (receiving current redo)
    zdlras1 - Recovery appliance

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 14 seconds ago)

DGMGRL>

Two databases or19dg (primary), and or19dgs (standby); ad zdlras1 (to protect primary), and zdlras2 (to protect standby) both receiving redo.

And as you can see, the backup is automatically done by Real-time redo:

RMAN> list copy of archivelog all;

List of Archived Log Copies for database with db_unique_name OR19DG
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - -------------------
19906   1    182     A 09/03/2020 23:33:57
        Name: +RECO/OR19DG/ARCHIVELOG/2020_03_09/thread_1_seq_182.435.1034638571

19993   1    183     A 09/03/2020 23:36:10
        Name: +RECO/OR19DG/ARCHIVELOG/2020_03_09/thread_1_seq_183.433.1034638845


RMAN> alter system archive log current;

Statement processed

RMAN> list backup of archivelog sequence 184;


List of Backup Sets
===================


BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
20068   104.00K    SBT_TAPE    00:00:00     09/03/2020 23:44:00
        BP Key: 20069   Status: AVAILABLE  Compressed: YES  Tag: TAG20200309T234400
        Handle: $RSCN_1920977_RTIM_1028557385_THRD_1_SEQ_184_CTKEY_19989_BACKUP   Media:

  List of Archived Logs in backup set 20068
  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time
  ---- ------- ---------- ------------------- ---------- ---------
  1    184     2884794    09/03/2020 23:40:45 2885266    09/03/2020 23:43:39

RMAN>

And if I try to delete I can do it:

RMAN> delete copy of archivelog sequence 184;

released channel: ORA_SBT_TAPE_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=132 instance=or19dg1 device type=DISK
List of Archived Log Copies for database with db_unique_name OR19DG
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - -------------------
20066   1    184     A 09/03/2020 23:40:45
        Name: +RECO/OR19DG/ARCHIVELOG/2020_03_09/thread_1_seq_184.418.1034639019


Do you really want to delete the above objects (enter YES or NO)? yes
deleted archived log
archived log file name=+RECO/OR19DG/ARCHIVELOG/2020_03_09/thread_1_seq_184.418.1034639019 RECID=491 STAMP=1034639019
Deleted 1 objects


RMAN>

This was possible because the standby is up, running and applying the redo, and the configuration of archivelog deletion is the default:

RMAN> show all;

RMAN configuration parameters for database with db_unique_name OR19DG are:
...

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
...

RMAN>

But in this config, if the standby database is down for some reason (or the apply is off) and if we try to delete the archivelog we receive the error RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process.

Look that my standby is down:

DGMGRL> show configuration

Configuration - or19dg

  Protection Mode: MaxAvailability
  Members:
  or19dg  - Primary database
    Warning: ORA-16629: database reports a different protection level from the protection mode

    or19dgs - Physical standby database (disabled)
      ORA-16906: The member was shutdown.

      zdlras2 - Recovery appliance (receiving current redo)
        Error: ORA-16685: database does not receive redo data

    zdlras1 - Recovery appliance

Fast-Start Failover:  Disabled

Configuration Status:
ERROR   (status updated 47 seconds ago)

DGMGRL>

And at rman look that below I have the last sequence as 187 and if I generate a new one and try to delete it I got an error:

RMAN> list copy of archivelog all;

List of Archived Log Copies for database with db_unique_name OR19DG
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - -------------------
20156   1    186     A 09/03/2020 23:45:44
        Name: +RECO/OR19DG/ARCHIVELOG/2020_03_09/thread_1_seq_186.418.1034639695

20157   1    187     A 09/03/2020 23:54:54
        Name: +RECO/OR19DG/ARCHIVELOG/2020_03_09/thread_1_seq_187.421.1034639697


RMAN> alter system archive log current;

Statement processed

RMAN> 
delete copy of archivelog sequence 188;

released channel: ORA_SBT_TAPE_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=132 instance=or19dg1 device type=DISK
RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process
archived log file name=+RECO/OR19DG/ARCHIVELOG/2020_03_09/thread_1_seq_188.420.1034639927 thread=1 sequence=188

RMAN>

Changing the deletion policy

But it is possible to manage this configuring the delete policy of archivelog at rman to allow delete after backed up at tape:

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DEVICE TYPE SBT;

new RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE';
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete

RMAN>

Doing this, you allow the deletion of archivelog even after the standby if down:

RMAN> delete copy of archivelog sequence 188;

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=132 instance=or19dg1 device type=DISK
List of Archived Log Copies for database with db_unique_name OR19DG
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - -------------------
20221   1    188     A 09/03/2020 23:54:57
        Name: +RECO/OR19DG/ARCHIVELOG/2020_03_09/thread_1_seq_188.420.1034639927


Do you really want to delete the above objects (enter YES or NO)? yes
deleted archived log
archived log file name=+RECO/OR19DG/ARCHIVELOG/2020_03_09/thread_1_seq_188.420.1034639927 RECID=500 STAMP=1034639927
Deleted 1 objects


RMAN>

And after you return your standby you can just restore the archivelog and the synchronization will continue. You did not lose the archivelog, it is protected inside of ZDLRA:

RMAN> restore archivelog sequence 188;

Starting restore at 10/03/2020 00:25:04
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=115 instance=or19dg1 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: RA Library (ZDLRAS1) SID=A0755032DEC66C81E0533205A00A9FCE

channel ORA_SBT_TAPE_1: starting archived log restore to default destination
channel ORA_SBT_TAPE_1: restoring archived log
archived log thread=1 sequence=188
channel ORA_SBT_TAPE_1: reading from backup piece $RSCN_1920977_RTIM_1028557385_THRD_1_SEQ_188_CTKEY_20143_BACKUP
channel ORA_SBT_TAPE_1: piece handle=$RSCN_1920977_RTIM_1028557385_THRD_1_SEQ_188_CTKEY_20143_BACKUP tag=TAG20200309T235859
channel ORA_SBT_TAPE_1: restored backup piece 1
channel ORA_SBT_TAPE_1: restore complete, elapsed time: 00:00:01
Finished restore at 10/03/2020 00:25:12

RMAN>

Can’t fix everything

But as you imagined, if the ZDLRA is down (for some reason) and you need to delete the archivelogs you will get an error pointing that you need more backups (RMAN-08138: warning: archived log not deleted – must create more backups).

RMAN> list copy of archivelog all;

using target database control file instead of recovery catalog
List of Archived Log Copies for database with db_unique_name OR19DG
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - -------------------
505     1    190     A 09/03/2020 23:58:51
        Name: +RECO/OR19DG/ARCHIVELOG/2020_03_10/thread_1_seq_190.435.1034641661

513     1    191     A 10/03/2020 00:27:39
        Name: +RECO/OR19DG/ARCHIVELOG/2020_03_10/thread_1_seq_191.429.1034641663

516     1    192     A 10/03/2020 00:27:41
        Name: +RECO/OR19DG/ARCHIVELOG/2020_03_10/thread_1_seq_192.433.1034641857

519     1    193     A 10/03/2020 00:30:57
        Name: +RECO/OR19DG/ARCHIVELOG/2020_03_10/thread_1_seq_193.420.1034641915


RMAN> alter system archive log current;

Statement processed

RMAN> 
list backup of archivelog sequence 194;

specification does not match any backup in the repository

RMAN> delete copy of archivelog sequence 194;

allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=117 instance=or19dg1 device type=DISK
RMAN-08138: warning: archived log not deleted - must create more backups
archived log file name=+RECO/OR19DG/ARCHIVELOG/2020_03_10/thread_1_seq_194.421.1034642149 thread=1 sequence=194

RMAN>

You can use force if needed:

RMAN> delete force copy of archivelog sequence 194;

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=117 instance=or19dg1 device type=DISK
List of Archived Log Copies for database with db_unique_name OR19DG
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - -------------------
522     1    194     A 10/03/2020 00:31:53
        Name: +RECO/OR19DG/ARCHIVELOG/2020_03_10/thread_1_seq_194.421.1034642149


Do you really want to delete the above objects (enter YES or NO)? yes
deleted archived log
archived log file name=+RECO/OR19DG/ARCHIVELOG/2020_03_10/thread_1_seq_194.421.1034642149 RECID=522 STAMP=1034642148
Deleted 1 objects


RMAN>

Architecture

The point here is the architecture design, the idea is always to remove the single point of failure. Even if you have the standby down, with the ZDLRA and database configured with Real-Time Redo you have RPO ZERO.

Of course, that as showed before, you need to take care of archivelog deletion policy to allow delete archivelogs when standby is down. But as you saw too, this can have another collateral effect. Unfortunately, there is no rule of thumb here, you need to sit and check what it is the best in this case: If you want to delete archivelogs just when they were copied to standby or when they were backed up at ZDLRA.

The point was shown to you the options that you have to solve this common issue when using ZDLRA and Dataguard. If you want to dig more, you can see the archivelog definition at the Oracle docs for rman. Or check this post from Frank Pachot.

 

 

Disclaimer: “The postings on this site are my own and don’t necessarily represent my actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications were removed to allow reach the generic audience and to be useful for the community. Post protected by copyright.”

One thought on “ZDLRA, Dataguard, Archivelogs, and RMAN-08137”

  1. Pingback: ZDLRA + MAA, Protection for Gold Architecture | Fernando Simon

Leave a Reply

Your email address will not be published. Required fields are marked *