RMAN-08137 warning

When I did archive log list on my primary, it gives me
archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u04/oradata/arch/PROD/
Oldest online log sequence 29627
Next log sequence to archive 29629
Current log sequence 29629
when I did archive log list on standby , it gives me
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u04/oradata/arch/STNBY/
Oldest online log sequence 29627
Next log sequence to archive 0
Current log sequence 29629
During the hot backup of primary, its showing up these errors.
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/u04/oradata/arch/PROD/PROD_0001_749397572_0000029124.arc thread=1 sequence=29124
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/u04/oradata/arch/PROD/PROD_0001_749397572_0000029125.arc thread=1 sequence=29125
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/u04/oradata/arch/PROD/PROD_0001_749397572_0000029126.arc thread=1 sequence=29126
I am sure standby is not in sync with Primary.
Can someone explain me how to resolve this issue.
Thank you

Here is how you can check whether or not your physical standby is in sync with the primary:
1. Check for GAP on standby
2. Check redo received on standby
3. Check redo applied on standby
Please refer to this url:
http://www.oraclemasters.in/?p=1255

Similar Messages

RMAN-08137: WARNING: archived log not deleted as it is still needed

I am trying to delete archive logs older than 7 days in streams environment.
1) we dont have a standby database
2) checkpoint_retention_time = 7
Please help me with this.
Regards,
Mike

SQL> set serveroutput on
DECLARE
hScn number := 0;
lScn number := 0;
sScn number;
ascn number;
alog varchar2(1000);
begin
select min(start_scn), min(applied_scn) into sScn, ascn
from dba_capture;
DBMS_OUTPUT.ENABLE(2000);
for cr in (select distinct(a.ckpt_scn)
from system.logmnr_restart_ckpt$ a
where a.ckpt_scn <= ascn and a.valid = 1
and exists (select * from system.logmnr_log$ l
where a.ckpt_scn between l.first_change# and l.next_change#)
order by a.ckpt_scn desc)
loop
if (hScn = 0) then
hScn := cr.ckpt_scn;
else
lScn := cr.ckpt_scn;
exit;
end if;
end loop;
if lScn = 0 then
lScn := sScn;
end if;
dbms_output.put_line('Capture will restart from SCN ' || lScn ||' in the following file:');
for cr in (select name, first_time
from DBA_REGISTERED_ARCHIVED_LOG
where lScn between first_scn and next_scn order by thread#)
loop
dbms_output.put_line(cr.name||' ('||cr.first_time||')');
end loop;
end;
After i ran the above script from metalink i got the below output.
When I have run the above code that is given in metalink to check the minimum archive logs required to restart streams i got the below ouput.
Capture will restart from SCN 55313283790in the following file:
+FLASH/ORCL/archivelog/2011_02_22/thread_1_seq_842.346.443519740 (11-MAR-11)*
+FLASH/ORCL/archivelog/2011_02_22/thread_2_seq_832.189.440690538 (11-MAR-11)*
Does this mean that I will not be able to delete the archive logs from 11-mar-11 ?
Regards,
Mike

RMAN-08137 workaround ?

Hello folks;
I have a master db standalone Oracle 10.2.0.4 with stream mono directionnal replication.
When RMAN wants to do a backup, i get this issue RMAN-08137.
This is my configuration for RMAN :
RMAN> show all;
utilisation du fichier de contrôle de la base de données cible au lieu du catalogue de récupération
paramètres de configuration RMAN :
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/appele/log/rman/teler/%F-%T';
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/appele/log/rman/teler/%U';
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE ENCRYPTION FOR DATABASE OFF;
CONFIGURE ENCRYPTION ALGORITHM 'AES128';
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/server/ora10.2.3/dbs/snapcf_teler.f'; This is my run :
RMAN> run
2> {
3> resync catalog;
4> SQL 'ALTER SYSTEM CHECKPOINT';
5> SQL 'create restore point LUNDI';
6> delete force noprompt obsolete;
7> backup as compressed backupset database plus archivelog delete all input;
8> delete force noprompt obsolete;
9> }My issue :
Recovery Manager: Release 10.2.0.4.0 - Production on Lun. Mai 21 20:30:01 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connecté à la base de données cible : TELER (DBID=966418795)
connecté à la base de données du catalogue de récupération
RMAN> run
2> {
3> resync catalog;
4> SQL 'ALTER SYSTEM CHECKPOINT';
5> SQL 'create restore point LUNDI';
6> delete force noprompt obsolete;
7> backup as compressed backupset database plus archivelog delete all input;
8> delete force noprompt obsolete;
9> }
10>
lancement de la resynchronisation complète du catalogue de récupération
resynchronisation complète terminée
instruction SQL : ALTER SYSTEM CHECKPOINT
instruction SQL : create restore point LUNDI
la règle de validité RMAN sera appliquée à la commande
la règle de validité RMAN est définie à la redondance 2
canal affecté : ORA_DISK_1
canal ORA_DISK_1 : sid=192 typedev=DISK
Suppression des sauvegardes et copies obsolètes suivantes :
Type                 Clé    Temps d'exécution    Nom de fichier/Descripteur
Ensemble de sauvegarde           7143414 18/05/12
Elément de sauvegarde       7143424 18/05/12           /appele/log/rman/teler/2enba0pp_1_1
Ensemble de sauvegarde           7143416 18/05/12
Elément de sauvegarde       7143426 18/05/12           /appele/log/rman/teler/c-966418795-20120518-00-20120518
élément de sauvegarde supprimé
descripteur d'élément de sauvegarde=/appele/log/rman/teler/2enba0pp_1_1 recid=78 horodatage=783614777
élément de sauvegarde supprimé
descripteur d'élément de sauvegarde=/appele/log/rman/teler/c-966418795-20120518-00-20120518 recid=80 horodatage=783614837
2 objets supprimés
Démarrage de backup dans 21/05/12
journal en cours archivé
utilisation du canal ORA_DISK_1
journal d'archivage /appele/log/teler/archive/log166_1_781549931.arc non pris en compte : déjà sauvegardé 1 fois
journal d'archivage /appele/log/teler/archive/log167_1_781549931.arc non pris en compte : déjà sauvegardé 1 fois
journal d'archivage /appele/log/teler/archive/log168_1_781549931.arc non pris en compte : déjà sauvegardé 1 fois
journal d'archivage /appele/log/teler/archive/log169_1_781549931.arc non pris en compte : déjà sauvegardé 1 fois
journal d'archivage /appele/log/teler/archive/log170_1_781549931.arc non pris en compte : déjà sauvegardé 1 fois
journal d'archivage /appele/log/teler/archive/log171_1_781549931.arc non pris en compte : déjà sauvegardé 1 fois
journal d'archivage /appele/log/teler/archive/log172_1_781549931.arc non pris en compte : déjà sauvegardé 1 fois
journal d'archivage /appele/log/teler/archive/log173_1_781549931.arc non pris en compte : déjà sauvegardé 1 fois
journal d'archivage /appele/log/teler/archive/log174_1_781549931.arc non pris en compte : déjà sauvegardé 1 fois
journal d'archivage /appele/log/teler/archive/log175_1_781549931.arc non pris en compte : déjà sauvegardé 1 fois
journal d'archivage /appele/log/teler/archive/log176_1_781549931.arc non pris en compte : déjà sauvegardé 1 fois
canal ORA_DISK_1 : démarrage de l'ensemble de sauvegarde compressé de journal d'archivage
canal ORA_DISK_1 : insertion du(des) journal(aux) d'archivage dans l'ensemble de sauvegarde
journal d'archivage en entrée thread=1 séquence=177 recid=149 horodatage=783894606
canal ORA_DISK_1 : démarrage de l'élément 1 dans 21/05/12
canal ORA_DISK_1 : élément 1 terminé dans 21/05/12
pointeur=/appele/log/rman/teler/2pnbii2f_1_1 étiquette=TAG20120521T203007 commentaire=NONE
canal ORA_DISK_1 : ensemble de sauvegarde terminé, temps écoulé : 00:00:02
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log177_1_781549931.arc thread=1 séquence=177
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log166_1_781549931.arc thread=1 séquence=166
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log167_1_781549931.arc thread=1 séquence=167
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log168_1_781549931.arc thread=1 séquence=168
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log169_1_781549931.arc thread=1 séquence=169
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log170_1_781549931.arc thread=1 séquence=170
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log171_1_781549931.arc thread=1 séquence=171
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log172_1_781549931.arc thread=1 séquence=172
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log173_1_781549931.arc thread=1 séquence=173
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log174_1_781549931.arc thread=1 séquence=174
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log175_1_781549931.arc thread=1 séquence=175
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log176_1_781549931.arc thread=1 séquence=176
Fin de backup dans 21/05/12
Démarrage de backup dans 21/05/12
utilisation du canal ORA_DISK_1
canal ORA_DISK_1 : démarrage de l'ensemble de sauvegarde compressé de tous les fichiers de données
canal ORA_DISK_1 : insertion du fichier de données dans l'ensemble de sauvegarde
fichier de données en entrée fno=00005 nom=/appele/teler/db/oradata/elecdatatele.dbf
fichier de données en entrée fno=00002 nom=/appele/teler/idx/oradata/undotele.dbf
fichier de données en entrée fno=00001 nom=/appele/teler/db/oradata/dbstele.dbf
fichier de données en entrée fno=00004 nom=/appele/teler/db/oradata/toolstele.dbf
fichier de données en entrée fno=00003 nom=/appele/teler/db/oradata/sysauxtele.dbf
fichier de données en entrée fno=00006 nom=/appele/teler/db/oradata/elecindxtele.dbf
fichier de données en entrée fno=00007 nom=/appele/teler/db/oradata/userstele.dbf
fichier de données en entrée fno=00008 nom=/appele/teler/db/oradata/resultattele.dbf
fichier de données en entrée fno=00009 nom=/appele/teler/db/oradata/resultat_indxtele.dbf
fichier de données en entrée fno=00010 nom=/appele/teler/db/oradata/streams_data.dbf
canal ORA_DISK_1 : démarrage de l'élément 1 dans 21/05/12
canal ORA_DISK_1 : élément 1 terminé dans 21/05/12
pointeur=/appele/log/rman/teler/2qnbii2h_1_1 étiquette=TAG20120521T203009 commentaire=NONE
canal ORA_DISK_1 : ensemble de sauvegarde terminé, temps écoulé : 00:01:05
Fin de backup dans 21/05/12
Démarrage de backup dans 21/05/12
journal en cours archivé
utilisation du canal ORA_DISK_1
canal ORA_DISK_1 : démarrage de l'ensemble de sauvegarde compressé de journal d'archivage
canal ORA_DISK_1 : insertion du(des) journal(aux) d'archivage dans l'ensemble de sauvegarde
journal d'archivage en entrée thread=1 séquence=178 recid=150 horodatage=783894674
canal ORA_DISK_1 : démarrage de l'élément 1 dans 21/05/12
canal ORA_DISK_1 : élément 1 terminé dans 21/05/12
pointeur=/appele/log/rman/teler/2rnbii4k_1_1 étiquette=TAG20120521T203116 commentaire=NONE
canal ORA_DISK_1 : ensemble de sauvegarde terminé, temps écoulé : 00:00:02
RMAN-08137: AVERTISSEMENT : le journal d'archivage n'a pas été supprimé car il est encore requis
journal d'archivage nom=/appele/log/teler/archive/log178_1_781549931.arc thread=1 séquence=178
Fin de backup dans 21/05/12
Démarrage de Control File and SPFILE Autobackup dans 21/05/12
descripteur d'élément=/appele/log/rman/teler/c-966418795-20120521-01-20120521 commentaire=NONE
Fin de Control File and SPFILE Autobackup dans 21/05/12
la règle de validité RMAN sera appliquée à la commande
la règle de validité RMAN est définie à la redondance 2
utilisation du canal ORA_DISK_1
Suppression des sauvegardes et copies obsolètes suivantes :
Type                 Clé    Temps d'exécution    Nom de fichier/Descripteur
Ensemble de sauvegarde           7143418 18/05/12
Elément de sauvegarde       7143428 18/05/12           /appele/log/rman/teler/2inbakuf_1_1
Ensemble de sauvegarde           7143420 18/05/12
Elément de sauvegarde       7143430 18/05/12           /appele/log/rman/teler/c-966418795-20120518-01-20120518
élément de sauvegarde supprimé
descripteur d'élément de sauvegarde=/appele/log/rman/teler/2inbakuf_1_1 recid=82 horodatage=783635407
élément de sauvegarde supprimé
descripteur d'élément de sauvegarde=/appele/log/rman/teler/c-966418795-20120518-01-20120518 recid=84 horodatage=783635477
2 objets supprimés
Gestionnaire de récupération (Recovery Manager) terminé.How to fix this issue ?
Thank you for your attention ! Help me please
Edited by: Moostiq on 22 mai 2012 11:03

I found the fix. With an acces to metalink everything is alright ...
The solution is :
Remove the 'delete input' and instead of that use 'delete noprompt archivelog until time' or any options.
Links :
standby, RMAN-8137 and Oracle 10.2.0.4
http://www.oraclemasters.in/?p=1255
RMAN-08137 When deleting archivelogs even when Streams CAPTURE does not require them [ID 1079953.1]"
Archive Log not Getting Deleted Using Rman With Rman-08137 [ID 964522.1]
Rman-08137: Warning: Archive Log Not Deleted As It Is Still Needed Rman-08137 [ID 374421.1]
RMAN-08137 when Deleting Archivelog Files [ID 373066.1]
http://database.itags.org/oracle/99206/

Defer log shipping and RMAN-08137 message when doing archivelog backup

Hello,
in a Primary & Dataguard scenario in which we set to DEFER the log shipping to the Dataguard during a high impact process done in the Primary, we receive the message "RMAN-08137: WARNING: archive log not deleted as it is still needed" when doing archive log backup with rman.
Is it the expected behaviour due to the DEFER status with the Dataguard? or even in this scenario we might we able to delete the logs and therefore we have to look more in deep to find our problem?
Thanks in advance for your help.

Hello,
Had a look on v$archived_log and found the archivelogs that are not deleted and the state for them is
DEST_ID=1
STANDBY_DEST=NO
ARCHIVED=YES
APPLIED=NO
as http://docs.oracle.com/cd/B12037_01/server.101/b10755/dynviews_1015.htm says , they are all Local, were archived and there is no apply needed for them as they are not defined to go to the StandBy Database.
Therefore, why can not still archive them? How can we check if they had been processed by a Streams process?
Regards

Rman-08137 can't delete archivelog because the capture process need it

When I use the rman utility to delete the old archivelog on the server ,It shows :Rman-08137 can't delete archivelog because the capture process need it .how to resolve the problem?

It is likely that the "extract" process still requires those archive logs, as it is monitoring transactions that have not yet been "captured" and written out to a GoldenGate trail.
Consider the case of doing the following: ggsci> add extract foo, tranlog, begin now
After pressing "return" on that "add extract" command, any new transactions will be monitored by GoldenGate. Even if you never start extract foo, the GoldenGate + rman integration will keep those logs around. Note that this GG+rman integration is a relatively new feature, as of GG 11.1.1.1 => if "add extract foo" prints out "extract is registered", then you have this functionality.
Another common "problem" is deleting "extract foo", but forgetting to "unregister" it. For example, to properly "delete" a registered "extract", one has to run "dblogin" first:
ggsci> dblogin userid <userid> password <password>
ggsci> delete extract foo
However, if you just do the following, the extract is deleted, but not unregistered. Only a warning is printed.
ggsci> delete extract foo
<warning: to unregister, run the command "unregister...">
So then one just has to follow the instructions in the warning:
ggsci> dblogin ...
ggsci> unregister extract foo logretention
But what if you didn't know the name of the old extracts, or were not even aware if there were any existing registered extracts? You can run the following to find out if any exist:
sqlplus> select count(*) from dba_capture;
The actual extract name is not exactly available, but it can be inferred:
sqlplus> select capture_name, capture_user from dba_capture;
<blockquote>
CAPTURE_NAME CAPTURE_USER
================ ==================
OGG$_EORADF4026B1 GGS
</blockquote>
In the above case, my actual "capture" process was called "eora". All OGG processes will be prefixed by OGG in the "capture_name" field.
Btw, you can disable this "logretention" feature by adding in a tranlog option in the param file,
TRANLOGOPTIONS LOGRETENTION DISABLED
Or just manually "unregister" the extract. (Not doing a "dblogin" before "add extract" should also work in theory... but it doesn't. The extract is still registered after startup. Not sure if that's a bug or a feature.)
Cheers,
-Michael

RMAN-08591: WARNING: invalid archived log deletion policy

Hi,
My database is 11.2.0.1 running on OEL 5.
We have stndby database running on other server, i have configured rman like this
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
But while running db backup, getting the error
RMAN-08591: WARNING: invalid archived log deletion policy.
RMAN retention policy is set to redundancy 1.
The archive files are deleting even though they are not applied on standby.
Thanks,

kkrm333 wrote:
Hi,
My database is 11.2.0.1 running on OEL 5.
We have stndby database running on other server, i have configured rman like this
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
But while running db backup, getting the error
RMAN-08591: WARNING: invalid archived log deletion policy.
RMAN retention policy is set to redundancy 1.
The archive files are deleting even though they are not applied on standby.
Thanks,
bcm@bcm-laptop:~$ oerr rman 8591
8591, 3, "WARNING: invalid archived log deletion policy"
// *Cause: An invalid ARCHIVELOG DELETION POLICY was supplied. The archived
//         log deletion policy was APPLIED but there was no mandatory
//         archived log destinations.
// *Action: One of the following:
//          1) Change archived log deletion policy using CONFIGURE command
//          2) Make one or more of standby destination as MANDATORY.

RMAN-08120: WARNING: archived log not deleted, not yet applied by standby

i get RMAN-08120: WARNING: archived log not deleted, not yet applied by standby on primary
but when i run below query i get the same result from primary and standby
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
44051
SQL>
standby is one log switch behind only!

i get RMAN-08120: WARNING: archived log not deleted, not yet applied by standby on primary You already have answer by post of Mseberg.
but when i run below query i get the same result from primary and standby
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
44051
SQL>
standby is one log switch behind only!this is wrong query used on primary & standby. even if any one of archive gap available lets suppose sequence *44020* , this archive not transported to standby due to some network problem and so on. later if archives from *44021* all the archives transported on standby upto *44051* , then it shows the maximum sequence transferred to standby, It wont shows applied sequence.
Check the below queries.
Primary:-
SQL> select thread#,max(sequence#) from v$archived_log group by thread#;
Standby:-
SQL> select thread#,max(sequence#) from v$archived_log where applied='YES' group by thread#;
HTH.

RMAN-08137

Why RMAN-08137 occurs while backing up archive using RMAN

Please NOTE: I am not sure if this can help if there are regular oracle streams capture process that blocks the archive purging. Hope this works for that too.
We have same issue as goldengate is running on this host and the issue arises when the extract is deleted by gg process but not unregistered in DB. This blocks the archive purging job unable to continue further thinking that this archive is still needed.
To fix it follow either of this.
method 1: login to Goldengate prompt and unregister the extract.
* ggsci> dblogin userid ... ggsci> unregister extract logretention
method 2: login to the database and drop the capture process.
* sql> exec dbms_capture_adm.drop_capture('OGG$_ETESTFFFFFFFF');
Once any of the above is done the RMAN archive purging process should be fine to purge logs with no issues.
thanks

RMAN-08138: WARNING: archived log not deleted - must create more backups

I ran:
1. CROSSCHECK ARCHIVELOG ALL
2. DELETE EXPIRED ARCHIVELOG ALL
I am getting this error. I am trying to free my arciver after an ORA-00257 error.
Can anyone help me out?

Basically this error means you are trying to delete archivelogs still needed for recovery (according to your retention policy). Develop a strategy which backs up the archivelogs in regular intervals, after a successful backup delete the archivelogs from disk, for example:
backup archivelog all delete all input;
Werner

Unable to delete primary database archivelogs using RMAN

Hi,
rman unable to delete the archivelogs of primary database even it is in sync ( with standby database).
giving an error :-
archive log filename=+FLASH/simsval/archivelog/2012_05_24/thread_2_seq_1693.11359.784134169 thread=2 sequence=1693
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=+FLASH/simsval/archivelog/2012_05_24/thread_2_seq_1694.5554.784135415 thread=2 sequence=1694
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=+FLASH/simsval/archivelog/2012_05_24/thread_2_seq_1695.11643.784164901 thread=2 sequence=1695
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=+FLASH/simsval/archivelog/2012_05_24/thread_2_seq_1696.12654.784164913 thread=2 sequence=1696
archive gap showing at primary.
SQL> select to_char (sysdate,'DD-MON-YYYY HH24:MI') as "Now", a.thread#, max(a.sequence#) as "Latest" ,max(b.sequence#) as "Last", max(a.sequence#)-max(b.sequence#) as "To Apply",to_char ( max (b.next_time), 'YYYY-MON-DD HH24:MI') as "LastDate",round ((sysdate - max (b.next_time) ) * 24 * 60, 0) as "Mins Behind" FROM V$ARCHIVED_LOG a , V$ARCHIVED_LOG b where a.applied = 'NO'and b.applied = 'YES' and a.thread# = b.thread# group by a.thread#, a.applied, b.thread#, b.applied order by a.thread#;
Now THREAD# Latest Last To Apply LastDate Mins Behind
01-JUN-2012 00:57 1 2321 2195 126 2012-APR-25 22:34 51983
01-JUN-2012 00:57 2 1729 1576 153 2012-APR-26 15:11 50985
no archive gap showing at standby .
SQL> select to_char (sysdate,'DD-MON-YYYY HH24:MI') as "Now", a.thread#, max(a.sequence#) as "Latest" ,max(b.sequence#) as "Last", max(a.sequence#)-max(b.sequence#) as "To Apply",to_char ( max (b.next_time), 'YYYY-MON-DD HH24:MI') as "LastDate",round ((sysdate - max (b.next_time) ) * 24 * 60, 0) as "Mins Behind" FROM V$ARCHIVED_LOG a , V$ARCHIVED_LOG b where a.applied = 'NO'and b.applied = 'YES' and a.thread# = b.thread# group by a.thread#, a.applied, b.thread#, b.applied order by a.thread#;
Now THREAD# Latest Last To Apply LastDate Mins Behind
01-JUN-2012 04:59 1 2321 2321 0 2012-MAY-31 22:32 386
01-JUN-2012 04:59 2 1729 1729 0 2012-MAY-31 22:32 386
any one please help me to resolve this.
thanks ,
Badam.
Edited by: 937988 on May 31, 2012 9:56 PM

Can you past here log_archive_ parameter on primary database?
Did you create data guard configuration with dgmgrl ?
Mahir M. Quluzade
www.mahir-quluzade.com

Rman backup on physical standby database without cancelling MRP

Hi all,
Could anyone share, is this possible to take RMAN backup on physical standby database without cancelling MRP process.
regarrds,

Hi,
On Standby Side:
SQL> alter database mount;
Database altered.
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
SQL> select max(Sequence#) from v$archived_log;
MAX(SEQUENCE#)
        405
SQL> select max(Sequence#) from v$archived_log where applied='YES';
MAX(SEQUENCE#)
        404
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@oel62-x64 Desktop]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue May 21 15:31:43 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ADMDB (DBID=4063877183, not open)
RMAN> backup database plus archivelog delete all input;
Starting backup at 21-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=32 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=390 RECID=391 STAMP=815416638
input archived log thread=1 sequence=391 RECID=392 STAMP=815421952
input archived log thread=1 sequence=392 RECID=393 STAMP=815422343
input archived log thread=1 sequence=393 RECID=394 STAMP=815422434
input archived log thread=1 sequence=394 RECID=395 STAMP=815422570
input archived log thread=1 sequence=395 RECID=396 STAMP=815476598
input archived log thread=1 sequence=396 RECID=397 STAMP=815476615
input archived log thread=1 sequence=397 RECID=398 STAMP=815476645
input archived log thread=1 sequence=398 RECID=399 STAMP=815477471
input archived log thread=1 sequence=399 RECID=400 STAMP=815477475
input archived log thread=1 sequence=400 RECID=401 STAMP=815477628
input archived log thread=1 sequence=401 RECID=403 STAMP=815584146
input archived log thread=1 sequence=402 RECID=402 STAMP=815584137
input archived log thread=1 sequence=403 RECID=405 STAMP=816017446
*input archived log thread=1 sequence=404 RECID=404 STAMP=816017444*
*input archived log thread=1 sequence=405 RECID=406 STAMP=816017455*
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_annnn_TAG20130521T153202_8spm937d_.bkp tag=TAG20130521T153202 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
channel ORA_DISK_1: deleting archived log(s)
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_14/o1_mf_1_390_8s48hfrp_.arc RECID=391 STAMP=815416638
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_14/o1_mf_1_391_8s4fohwb_.arc RECID=392 STAMP=815421952
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_14/o1_mf_1_392_8s4g1q0v_.arc RECID=393 STAMP=815422343
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_14/o1_mf_1_393_8s4g4l8z_.arc RECID=394 STAMP=815422434
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_14/o1_mf_1_394_8s4g8t9h_.arc RECID=395 STAMP=815422570
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_395_8s631622_.arc RECID=396 STAMP=815476598
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_396_8s631qjj_.arc RECID=397 STAMP=815476615
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_397_8s632od8_.arc RECID=398 STAMP=815476645
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_398_8s63whqc_.arc RECID=399 STAMP=815477471
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_399_8s63wly4_.arc RECID=400 STAMP=815477475
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_400_8s641d8j_.arc RECID=401 STAMP=815477628
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_16/o1_mf_1_401_8s9d21jk_.arc RECID=403 STAMP=815584146
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_16/o1_mf_1_402_8s9d1skv_.arc RECID=402 STAMP=815584137
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_403_8spm6p4h_.arc RECID=405 STAMP=816017446
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_404_8spm6mqj_.arc RECID=404 STAMP=816017444
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_405_8spm6yg0_.arc thread=1 sequence=405
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/stldb/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/stldb/sysaux01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/stldb/example01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/stldb/undotbs01.dbf
input datafile file number=00006 name=/u01/app/oracle/oradata/stldb/appdata01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/stldb/users01.dbf
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_nnndf_TAG20130521T153213_8spm9fnc_.bkp tag=TAG20130521T153213 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:15
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_ncsnf_TAG20130521T153213_8spmfqxf_.bkp tag=TAG20130521T153213 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
specification does not match any archived log in the repository
backup cancelled because there are no files to backup
Finished backup at 21-MAY-13
RMAN> exit
Recovery Manager complete.
[oracle@oel62-x64 Desktop]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Tue May 21 15:34:42 2013
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select max(Sequence#) from v$archived_log;
MAX(SEQUENCE#)
        405
SQL> select max(Sequence#) from v$archived_log where applied='YES';
MAX(SEQUENCE#)
        404
SQL> There have no problem, backup database when MRP is running. But if you want delete, then you are getting RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process.
And will not delete this archived log, because it is needed for standby or upstream capture process.
Updated
When MRP stoped
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@oel62-x64 Desktop]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue May 21 15:46:07 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ADMDB (DBID=4063877183, not open)
RMAN> backup database plus archivelog delete all input;
Starting backup at 21-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=24 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=405 RECID=406 STAMP=816017455
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_annnn_TAG20130521T154617_8spn3s9w_.bkp tag=TAG20130521T154617 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archived log(s)
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_405_8spm6yg0_.arc RECID=406 STAMP=816017455
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/stldb/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/stldb/sysaux01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/stldb/example01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/stldb/undotbs01.dbf
input datafile file number=00006 name=/u01/app/oracle/oradata/stldb/appdata01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/stldb/users01.dbf
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_nnndf_TAG20130521T154618_8spn3v4f_.bkp tag=TAG20130521T154618 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:16
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_ncsnf_TAG20130521T154618_8spn6779_.bkp tag=TAG20130521T154618 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
specification does not match any archived log in the repository
backup cancelled because there are no files to backup
Finished backup at 21-MAY-13
RMAN> Apply process is stopped and new redo received from primary.
SQL> select max(Sequence#) from v$archived_log;
MAX(SEQUENCE#)
        407
SQL> select max(Sequence#) from v$archived_log where applied='YES';
MAX(SEQUENCE#)
        405
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@oel62-x64 Desktop]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue May 21 15:49:28 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ADMDB (DBID=4063877183, not open)
RMAN> backup database plus archivelog delete all input;
Starting backup at 21-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=32 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=406 RECID=407 STAMP=816018527
input archived log thread=1 sequence=407 RECID=408 STAMP=816018530
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_annnn_TAG20130521T154937_8spnb1y3_.bkp tag=TAG20130521T154937 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archived log(s)
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_406_8spn8hkn_.arc thread=1 sequence=406
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_407_8spn8l69_.arc thread=1 sequence=407
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/stldb/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/stldb/sysaux01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/stldb/example01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/stldb/undotbs01.dbf
input datafile file number=00006 name=/u01/app/oracle/oradata/stldb/appdata01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/stldb/users01.dbf
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_nnndf_TAG20130521T154939_8spnb3f5_.bkp tag=TAG20130521T154939 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:15
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_ncsnf_TAG20130521T154939_8spndhly_.bkp tag=TAG20130521T154939 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
specification does not match any archived log in the repository
backup cancelled because there are no files to backup
Finished backup at 21-MAY-13
RMAN> I think, codes is understandable.
Regard
Mahir M. Quluzade
Edited by: Mahir M. Quluzade on May 21, 2013 3:36 PM

RMAN doesnt delete Standby Archivelogs

piece handle=arch-s7618-p1-t715652396 tag=TAG20100407T001953 comment=API Version 2.0,MMS Version 5.0.0.0
channel ch01: backup set complete, elapsed time: 00:02:17
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/u06/DBFR/SUSM1C/arch_SUSM1C_1595_1_680380890.dbf thread=1 sequence=1595
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/u06/DBFR/SUSM1C/arch_SUSM1C_1596_1_680380890.dbf thread=1 sequence=1596
I keep seeing this messages when I try to backup archive logs.
Please note that this is a standby database.
Could someone let me know why it doesn delete these ?

Hi
Please see below explanation of the APPLIED column on this view:
Indicates whether the archivelog has been applied to its corresponding standby database (YES) or not (NO). The value is always NO for local destinations.
This column is meaningful at the physical standby site for the ARCHIVED_LOG entries with REGISTRAR='RFS' (which means this log is shipped from the primary to the standby database). If REGISTRAR='RFS' and APPLIED is NO, then the log has arrived at the standby but has not yet been applied. If REGISTRAR='RFS' and APPLIED is YES, the log has arrived and been applied at the standby database. You can use this field to identify archivelogs that can be backed up and removed from disk.
If this column is not updated then that suggests your standby isn't applying logs?
Thanks
Paul

RMAN and 11g Active Data Guard

I just build my first 11g Active Data Guard . . . well the next thing to do is the RMAN part.
At this point I want to know:
A) How/What do you query to know that a log has been applied on the Standby side
B) How does RMAN know what has been applied
C) If I do the RMAN backup on the Standby side, won't there always be some difference because there is always some delay between the Primary and Standby?

I presume you mean using RMAN to delete archive logs? If the log hasnt been shipped and applied to the standby yet RMAN wont remove it, instead it outputs the following error:
RMAN-08137: WARNING: archive log not deleted as it is still needed
Until the log has been applied on the standby, this intelligence is built in at 11G (at 10G you needed an "_" parameter to get this working).
Thanks
Paul

Standby and primary

On my Primary database
when I did archive log list, it gives me
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u04/oradata/arch/PROD/
Oldest online log sequence 29627
Next log sequence to archive 29629
Current log sequence 29629
On my standby database, when I did archive log list, it gives me
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u04/oradata/arch/STNBY/
Oldest online log sequence 29627
Next log sequence to archive 0
Current log sequence 29629
But during hotback on primary it pops up with these errors
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/u04/oradata/arch/PROD/PROD_0001_749397572_0000028449.arc thread=1 sequence=28449
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/u04/oradata/arch/PROD/PROD_0001_749397572_0000028450.arc thread=1 sequence=28450
RMAN-08137: WARNING: archive log not deleted as it is still needed
I am sure Standby is not in sync with primary.
Can someone explain in detail how to resolve this issue.
Any help is greatly appreciated.
Thank you

My alert log in bdump has the following information:
Primary database is in MAXIMUM PERFORMANCE mode
RFS[739]: Successfully opened standby log 4: '/u01/oradata/STNBY/redo_STNBY_04a.log'
Tue Sep 13 11:27:35 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[739]: Successfully opened standby log 4: '/u01/oradata/STNBY/redo_STNBY_04a.log'
Tue Sep 13 11:28:04 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[739]: Successfully opened standby log 4: '/u01/oradata/STNBY/redo_STNBY_04a.log'
Tue Sep 13 11:40:33 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[739]: Successfully opened standby log 4: '/u01/oradata/STNBY/redo_STNBY_04a.log'
Tue Sep 13 12:00:44 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[739]: Successfully opened standby log 4: '/u01/oradata/STNBY/redo_STNBY_04a.log'
Tue Sep 13 12:02:49 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[739]: Successfully opened standby log 4: '/u01/oradata/STNBY/redo_STNBY_04a.log'
Trace file in bdump give me the following information.
*** 2011-09-09 11:58:59.650 61283 kcrr.c
FAL[client, MRP0]: Error 12514 connecting to PROD for fetching gap sequence
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
*** 2011-09-09 11:59:29.662
OCIServerAttach failed -1
.. Detailed OCI error val is 12514 and errmsg is 'ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
*** 2011-09-09 11:59:29.662 61283 kcrr.c
FAL[client, MRP0]: Error 12514 connecting to PROD for fetching gap sequence
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
*** 2011-09-09 11:59:59.674
OCIServerAttach failed -1
.. Detailed OCI error val is 12514 and errmsg is 'ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
*** 2011-09-09 11:59:59.674 61283 kcrr.c
FAL[client, MRP0]: Error 12514 connecting to PROD for fetching gap sequence
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
*** 2011-09-09 12:00:29.687
OCIServerAttach failed -1
.. Detailed OCI error val is 12514 and errmsg is 'ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
*** 2011-09-09 12:00:29.687 61283 kcrr.c
FAL[client, MRP0]: Error 12514 connecting to PROD for fetching gap sequence
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
*** 2011-09-09 12:00:59.697
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-----------------------------------------------------------

Physical standby database fail-over

Hi,
I am working on Oracle 10.2.0.3 on Solaris SPARC 64-bit.
I have a Dataguard configuration with a single Physical standby database that uses real time application. We had a major application upgrade yesterday and before the start of upgrade, we cancelled the media recovery and disabled the log_archive_dest_n so that it doesn't ship the archive logs to standby site. We left the dataguard configuration in this mode incase of a rollback.
Primary:
alter system set log_archive_dest_state_2='DEFER';
alter system switch logfile;
Standby:
alter database recover managed standby database cancel;Due to application upgrade induced problems we had to failover to the physical standby, which was not in sync with primary from yesterday. I used the following method to fail-over since i do not want to apply any redo from yesterday.
Standby:
alter database activate physical standby database;
alter database open;
shutdown immediate;
startupSo, after this step, the database was a stand alone database, which doesn't have any standby databases yet (but it still has log_archive_config parameter set and log_archive_dest_n parameters set but i have 'DEFER' the log_archive_dest_n pointing to the old primary). I have even changed the "archive log deletion policy to NONE"
RMAN> configure archivelog deletion policy to none;After the fail-over was completed, the log sequence started from Sequence 1. We cleared the FRA to make space for the new archive logs and started off a FULL database backup (backup incremental level 0 database plus archivelog delete input). The backup succeded but we got these alerts in the backup log that RMAN cannot delete the archivelogs.
RMAN-08137: WARNING: archive log not deleted as it is still neededMy question here is
1) Even though i have disabled the log_archive_dest_n parameters, why is RMAN not able to delete the archivelogs after backup when there is no standby database for this failed-over database?
2) Are all the old backups marked unusable after a fail-over is performed?
FYI... flashback database was not used in this case as it did not server our purpose.
Any information or documentation links would be greatly appreciated.
Thanks,
Harris.

Thanks for the reply.
The FINISH FORCE works in some cases but if there is an archive gap (though it didn't report in our case), it might not work some times (DOCID: 846087.1). So, we followed the Switch-over & Fail-Over best practices where it mentioned about this "ACTIVE PHYSICAL STANDBY" for a fail-over if you intend not to apply any archivelogs. The process we followed is the Right one.
Anyhow, we got the issue resolved. Below is the resolution path.
1) Even though if you DEFER the LOG_ARCHIVE_DEST_STATE_N parameter's on the primary, there are some situations where the Primary database in a dataguard configuration where it will not delete the archive logs due to some SCN issues. This issue may or may not arise in all fail-over scenarios. If it does, then do the following checks
Follow DOCID: 803635.1, which talks about a PLSQL procedure to check for problematic SCN's in a dataguard configuration even though the physical standby databases are no available (i.e., if the dataguard parameters are set, log_archive_config, log_archive_dest_n='SERVICE=..." still set and even though corresponding LOG_ARCHIVE_DEST_STATE_N parameters are DEFERRED).
If this procedure returns any rows, then the primary database is not able to delete the archivelogs because it is still thinking there is a standby database and trying to save the archive logs because of the SCN conflict.
So, the best thing to do is, remove the DG related parameters from the spfile (log_archive_config, log_archive_dest_n parameters).
After i made these changes, i ran a test backup using "backup archivelog all delete input", the archive logs got deleted after backup without any issues.
Thanks,
Harris.
Edited by: user11971589 on Nov 18, 2010 2:55 PM

RMAN-08137 warning

Similar Messages

Maybe you are looking for