Wednesday, February 27, 2013

Restore Archive logs from Disk Based Backups gives RMAN-06026: some targets not found - aborting restore RMAN-06102: no channel to restore a backup or copy of log thread 1 seq


One of our DG has gone Out of SYNC. Primary database is in MAXIMUM AVAILABILITY mode and we have specified standby location as an alternate destination.

Now our Primary archive diskgroup got 100% full and one of our team member has ran backup of archive logs to disk (Our Backup Tapes are not Working at that Moment) with the delete input option which has backed up all the Archives and deleted from Primary. 

Now Standby database is looking for archive log which is not in Diskgroup but in RMAN disk backup. 

##########################
#   Task 
##########################

Restore Archive logs from Disk Based Backups.

So our team member has started to make it sync by trying to restore the archives from the backup and got the below errors.

##########################
#   Command Used  
##########################

Command to Restore Archive logs to different location.


run
{
allocate channel c2 device type disk;
set archivelog destination to '/opt/oracle/backup/oralin/arch_bkp/';
restore archivelog from logseq 105408 until logseq 105413;
}

When running the restore got the below errors, 

##########################
#   Errors  
##########################


RMAN> run
{
allocate channel c2 device type disk;
set archivelog destination to '/opt/oracle/backup/oralin/arch_bkp/';
restore archivelog from logseq 105408 until logseq 105413;

}
2> 3> 4> 5> 6> 7>
released channel: ORA_SBT_TAPE_1
released channel: ORA_SBT_TAPE_2
released channel: ORA_SBT_TAPE_3
released channel: ORA_SBT_TAPE_4
released channel: ORA_DISK_1
allocated channel: c1
channel c1: sid=862 devtype=DISK
allocated channel: c2
channel c2: sid=1309 devtype=DISK
executing command: SET ARCHIVELOG DESTINATION
Starting restore at 27-FEB-13
released channel: c1
released channel: c2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 02/27/2013 22:28:14
RMAN-06026: some targets not found - aborting restore
RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 105413 lowscn 13117372976201
RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 105412 lowscn 13117372752915
RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 105411 lowscn 13117372598071
RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 105410 lowscn 13117372461415
RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 105408 lowscn 13117372091300
RMAN>

We spent more time on investigating this error and to resolve the above error. But later on further investigation i found the problem made by the team member and the solution is very simple.




##########################
#   Pre checks 
##########################
  1.  Check whether backup of Archive Logs available. 
  2.  Is the Backup Stored in TAPE or in DISK. 
##########################
 Solution
##########################

 Check whether backup of Archive Logs available. 

RMAN> list backup of archivelog from logseq 105408 until logseq 105413 thread 1;
List of Backup Sets
===================
BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
56800656 577.25M    SBT_TAPE    00:07:21     27-FEB-13
        BP Key: 56800662   Status: AVAILABLE  Compressed: NO  Tag: oralin_FULL_0
        Handle: bk_11040_1_808444905   Media: O00100
  List of Archived Logs in backup set 56800656
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    105408  13117372091300 26-FEB-13 13117372283649 26-FEB-13
  1    105409  13117372283649 26-FEB-13 13117372461415 26-FEB-13
  1    105410  13117372461415 26-FEB-13 13117372598071 26-FEB-13
  1    105411  13117372598071 26-FEB-13 13117372752915 26-FEB-13
  1    105412  13117372752915 26-FEB-13 13117372976201 26-FEB-13
  1    105413  13117372976201 26-FEB-13 13117373012970 27-FEB-13

From the above output if you can see the Backup is stored in SBT_TAPE, but our team member has allocated disk Channel because he took backup of archives to disk.

But the archives which needed to restore are already backed up in TAPE and its his understanding that the archives are stored in DISK Backup.

So After removing the Disk channel allocation command, the restore was successful.

RMAN>  run
{
set archivelog destination to '/opt/oracle/backup/oralin/arch_bkp/';
restore archivelog logseq 105409 thread 1;
}
2> 3> 4> 5>

executing command: SET ARCHIVELOG DESTINATION

Starting restore at 27-FEB-13
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: sid=862 devtype=SBT_TAPE
channel ORA_SBT_TAPE_1: Veritas NetBackup for Oracle - Release 7.1 (2011020313)
allocated channel: ORA_SBT_TAPE_2
channel ORA_SBT_TAPE_2: sid=1309 devtype=SBT_TAPE
channel ORA_SBT_TAPE_2: Veritas NetBackup for Oracle - Release 7.1 (2011020313)
allocated channel: ORA_SBT_TAPE_3
channel ORA_SBT_TAPE_3: sid=617 devtype=SBT_TAPE
channel ORA_SBT_TAPE_3: Veritas NetBackup for Oracle - Release 7.1 (2011020313)
allocated channel: ORA_SBT_TAPE_4
channel ORA_SBT_TAPE_4: sid=576 devtype=SBT_TAPE
channel ORA_SBT_TAPE_4: Veritas NetBackup for Oracle - Release 7.1 (2011020313)
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=359 devtype=DISK
channel ORA_SBT_TAPE_1: starting archive log restore to user-specified destination
archive log destination=/opt/oracle/backup/oralin/arch_bkp/
channel ORA_SBT_TAPE_1: restoring archive log
archive log thread=1 sequence=105409
channel ORA_SBT_TAPE_1: reading from backup piece bk_11063_1_808494442
channel ORA_SBT_TAPE_1: restored backup piece 1
piece handle=bk_11063_1_808494442 tag=TAG20130227T134717
channel ORA_SBT_TAPE_1: restore complete, elapsed time: 00:02:37
Finished restore at 27-FEB-13

So the moral of this story is listen what your team member says but always start with your own investigation path. :)

1 comment:

Anonymous said...

Very interesting.........