Categories
Blog

Cloud – RMAN-06026: some targets not found – aborting restore

 


 

When checking backup status in the Oracle Cloud Database
server, I noticed the following error:

RMAN-06026: some targets not found – aborting restore

RMAN-08526: channel ORA_SBT_TAPE_5: Oracle Database Backup
Service Library VER=3.16.9.21

RMAN-00571:
===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS
===============

RMAN-00571:
===========================================================

RMAN-03002: failure of restore command at 03/19/2017
16:49:39

RMAN-06026: some targets not found – aborting restore

RMAN-06025: no backup of archived log for thread 1 with
sequence 1332 and starting SCN of 416745785 found to restore

RMAN-06025: no backup of archived log for thread 1 with
sequence 1331 and starting SCN of 416745691 found to restore

RMAN-06025: no backup of archived log for thread 1 with
sequence 1330 and starting SCN of 416633416 found to restore

RMAN-06025: no backup of archived log for thread 1 with
sequence 1329 and starting SCN of 416632713 found to restore

RMAN-06025: no backup of archived log for thread 1 with
sequence 1328 and starting SCN of 415836751 found to restore

RMAN-06025: no backup of archived log for thread 1 with
sequence 1327 and starting SCN of 414639947 found to restore

Solution

Why did this happen, what happened.  Oracle
periodically change the Cloud tooling, when they do this you can see the above
error.  By updating the Cloud Tooling this error was fixed in this
case.  To update or check the version of the cloud tooling you can follow
the steps from the Oracle website.

https://docs.oracle.com/en/cloud/paas/database-dbaas-cloud/csdbi/update-cloud-tooling-using-dbpatchm.html#CSDBI-GUID-852CF27F-3312-428A-979E-142D1945E62E

 
 

Categories
Blog

FAL[client, ARC0]: Error 12154 for fetching gap sequence

Recently I came across the following error :
ERROR: failed to establish dependency between database ps1 and diskgroup resource ora.FRA.dg
Error 12154 received logging on to the standby
FAL[client, ARC0]: Error 12154 connecting to s1 for fetching gap sequence
Error 12154 received logging on to the standby
FAL[client, ARC0]: Error 12154 connecting to s2 for fetching gap sequence
Lets have a look to see what has happened and resolve.
1) If we log onto the standby and run the following we can see the gap.

SQL> select *
  2  from v$archive_gap;
   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
         1         74298          74419
         2         67767          67844

1b) Also as a different example you could log onto the ASM standby machine as Oracle and have a look at the archive logs and see if there is any missing.

$asmcmd
cd FRA
cd LS78LIVE
ls

If we look at the list we can identify missing log, it is in sequential order ls78live_1 is thread 1, ls78live_2 is thread 2., We can see below ls78live_1_144812_704059285.arc is missing.

ls78live_1_144811_704059285.arc
ls78live_1_144813_704059285.arc
ls78live_1_144814_704059285.arc
ls78live_1_144815_704059285.arc
..
.
ls78live_2_107944_704059285.arc
ls78live_2_107945_704059285.arc
ls78live_2_107946_704059285.arc 

2) On Primary database retrieve the missing archive log files based on the information we got from v$archive_gap.

rman target sys/** catalog rcuser/**@rmcatalog
RMAN> run
{allocate channel c1 type disk;
backup archivelog from sequence 74298 until sequence 74299 thread 1 format '/database/backup/s78live/gap/arch_1_%U';
backup archivelog from sequence 67767 until sequence 67768 thread 2 format '/database/backup/s78live/gap/arch_2_%U';
}

If the archive logs have been already removed you will get the following error.

Starting backup at 22-JUL-16
specification does not match any archived log in the repository
backup cancelled because there are no files to backup
Finished backup at 22-JUL-16.

In this case you will need to look through your backed up archive logs.
3) On Standby – lets restore the archive files

RMAN> run
{catalog start with '/database/backup/s82live/arch/1dayold';
allocate channel c1 type disk ;
allocate channel c2 type disk ;
restore archivelog from sequence 74298 until sequence 74299 thread 1;
restore archivelog from sequence 67767 until sequence 67768 thread 2;
}

12) We now enable the recovery of the standby.

SQL> sqlplus / as sysdba
SQL> alter database recover managed standby database using current logfile disconnect from session;

Summary
We have identified the gap, found the missing archive log’s, copied them to the standby and re-enabled the dataguard.