Standby do not applied archives

Hi,
Please help me any one,
am facing the below problem,
Errors in file /oracle/admin/marvlstd/bdump/marvlstd_mrp0_28273.trc:
ORA-12801: error signaled in parallel query server P000
ORA-00600: internal error code, arguments: [3020], [90], [573443], [378060803], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 90, block# 573443)
ORA-10564: tablespace USERS
ORA-01110: data file 90: '+DA
when am started MRP above error to be occurred how to solve the issue in statdby
i have restarted asm and DB its fine but archives not applied,
once i put the below command facing the above problem.
alter database recover managed standby database disconnect from session;
Thanks
Gopi G

Hi,
please check following link: ORA-10567: Redo is inconsistent with data block (file# 124, block# 214081) &laquo; Hendry&#039;s &quot;Oracl…
Thank you

Similar Messages

New standby not applying archive log

I have just created standby database....but its not applying archive log...
when I checked the alerlog file of standby....
ora-19527 physical standby redo log must be renamed

yes, I have created at onlien redo logs at standby database..
what is test and test?
i saw one command like this...
log_file_name_convert= ((''/u01/oradata/prod'', ''/u01/oradata/standby''),(''/u02/oradata/prod'', ''/u02/oradata/standby''))
My Primary DB name is OraclePM
My Standby DB name is OracleDR
I have placed all redo logs in direcrtory (D:\oracle\product\logs\ ) the directory structure for both databases is same... I have created 3 additionals redo logs at standby database...
How can I edit my standby init file...

My Active dataguard is not applying archives.

Dears,
Following is my setup
=====================
Primary:
prod on RAC with 2 nodes
Database : Oracle 11.2.0.3
OS OEL 5.7
storage : ASM
+DATADG
+FLASHDG
Standby:
sync on single node
Database : Oracle 11.2.0.3
storage : ASM
+DATADG
+FLASHDG
I've configured Active dataguard successfully and was able to apply archivelogs successfully instantly.
Archive log locations are +FLASHDG/prod/ARCHIVELOG/ AND /u02/arch --- on primary
Archive log locations are +FLASHDG/stby/ARCHIVELOG/ AND /u02/arch --- on standby
On Standby
===========
SQL> select 'Using Active Data Guard' ADG from v$managed_standby m,v$database d where m.process like 'MRP%' ;
ADG
Using Active Data Guard
SQL> select open_mode,database_role,PROTECTION_MODE,PROTECTION_LEVEL from v$database;
OPEN_MODE DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL
READ ONLY WITH APPLY PHYSICAL STANDBY MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
SQL>
Upto now everything is ok, means same data is sync on primary and standby. As my archive location was getting full, i've used this SQL query to clean them
SELECT 'alter diskgroup '||dg.name||' drop file
''+'||dg.name||''||SYS_CONNECT_BY_PATH(al.name,'/')||''';'
FROM v$asm_alias al, v$asm_file fi, v$asm_diskgroup dg
WHERE al.file_number = fi.file_number(+)
AND al.group_number = dg.group_number
AND fi.type = 'ARCHIVELOG'
START WITH alias_index = 0
CONNECT BY PRIOR al.reference_index = al.parent_index;
SELECT 'alter diskgroup '||dg.name||' drop file
''+'||dg.name||''||SYS_CONNECT_BY_PATH(al.name,'/')||''';'
FROM v$asm_alias al, v$asm_file fi, v$asm_diskgroup dg
WHERE al.file_number = fi.file_number(+)
AND al.group_number = dg.group_number
AND fi.type = 'BACKUPSET'
START WITH alias_index = 0
CONNECT BY PRIOR al.reference_index = al.parent_index;
In order to delete ARCHIVE logs which are stored in ASM FLASHDG, which will have a type of "ARCHIVELOG" and "BACKUPSET" i've used this above two queries.
After performing this steps , my Active dataguard is not applying archives.
On the primary server, check the latest archived redo log
SELECT sequence#, first_time, next_time
FROM v$archived_log
ORDER BY sequence#;
2809 16-APR-13 16-APR-13
2809 16-APR-13 16-APR-13
2809 16-APR-13 16-APR-13
2810 16-APR-13 16-APR-13
2810 16-APR-13 16-APR-13
2810 16-APR-13 16-APR-13
2811 16-APR-13 16-APR-13
2811 16-APR-13 16-APR-13
2811 16-APR-13 16-APR-13
2812 16-APR-13 16-APR-13
2812 16-APR-13 16-APR-13
2812 16-APR-13 16-APR-13
2813 16-APR-13 16-APR-13
2813 16-APR-13 16-APR-13
2814 16-APR-13 16-APR-13
2814 16-APR-13 16-APR-13
2815 16-APR-13 16-APR-13
2815 16-APR-13 16-APR-13
2816 16-APR-13 16-APR-13
2816 16-APR-13 16-APR-13
2817 16-APR-13 16-APR-13
2817 16-APR-13 16-APR-13
2818 16-APR-13 16-APR-13
2818 16-APR-13 16-APR-13
2819 16-APR-13 16-APR-13
2819 16-APR-13 16-APR-13
2820 16-APR-13 16-APR-13
2820 16-APR-13 16-APR-13
2821 16-APR-13 16-APR-13
2821 16-APR-13 16-APR-13
2822 16-APR-13 16-APR-13
2822 16-APR-13 16-APR-13
2823 16-APR-13 16-APR-13
2823 16-APR-13 16-APR-13
2824 16-APR-13 16-APR-13
2824 16-APR-13 16-APR-13
2825 16-APR-13 16-APR-13
2825 16-APR-13 16-APR-13
2826 16-APR-13 16-APR-13
2826 16-APR-13 16-APR-13
2827 16-APR-13 16-APR-13
2827 16-APR-13 16-APR-13
2828 16-APR-13 16-APR-13
2828 16-APR-13 16-APR-13
2829 16-APR-13 16-APR-13
2829 16-APR-13 16-APR-13
2830 16-APR-13 16-APR-13
2830 16-APR-13 16-APR-13
2831 16-APR-13 16-APR-13
2831 16-APR-13 16-APR-13
2832 16-APR-13 16-APR-13
2832 16-APR-13 16-APR-13
2833 16-APR-13 16-APR-13
2833 16-APR-13 16-APR-13
2834 16-APR-13 16-APR-13
2834 16-APR-13 16-APR-13
2835 16-APR-13 16-APR-13
2835 16-APR-13 16-APR-13
2836 16-APR-13 16-APR-13
2836 16-APR-13 16-APR-13
2837 16-APR-13 16-APR-13
2837 16-APR-13 16-APR-13
2838 16-APR-13 16-APR-13
2838 16-APR-13 16-APR-13
2839 16-APR-13 16-APR-13
2839 16-APR-13 16-APR-13
2840 16-APR-13 16-APR-13
2840 16-APR-13 16-APR-13
2841 16-APR-13 16-APR-13
2841 16-APR-13 16-APR-13
2842 16-APR-13 16-APR-13
2842 16-APR-13 16-APR-13
2843 16-APR-13 16-APR-13
2843 16-APR-13 16-APR-13
2844 16-APR-13 16-APR-13
2844 16-APR-13 16-APR-13
2845 16-APR-13 16-APR-13
2845 16-APR-13 16-APR-13
2846 16-APR-13 16-APR-13
2846 16-APR-13 16-APR-13
Check the new archived redo log has arrived at the standby server and been applied.
SELECT sequence#, first_time, next_time, applied
FROM v$archived_log
ORDER BY sequence#;
2801 15-APR-13 15-APR-13 YES
2801 15-APR-13 15-APR-13 YES
2802 15-APR-13 15-APR-13 YES
2802 15-APR-13 15-APR-13 YES
2803 15-APR-13 15-APR-13 YES
2803 15-APR-13 15-APR-13 YES
2804 15-APR-13 15-APR-13 YES
2804 15-APR-13 15-APR-13 YES
2805 15-APR-13 15-APR-13 YES
2805 15-APR-13 15-APR-13 YES
2806 15-APR-13 15-APR-13 YES
2806 15-APR-13 15-APR-13 YES
2807 15-APR-13 15-APR-13 YES
2807 15-APR-13 15-APR-13 YES
2808 15-APR-13 16-APR-13 YES
2808 15-APR-13 16-APR-13 YES
2809 16-APR-13 16-APR-13 YES
2809 16-APR-13 16-APR-13 YES
2810 16-APR-13 16-APR-13 YES
2810 16-APR-13 16-APR-13 YES
2811 16-APR-13 16-APR-13 YES
2811 16-APR-13 16-APR-13 YES
2812 16-APR-13 16-APR-13 IN-MEMORY
2812 16-APR-13 16-APR-13 YES
So could anyone help me to resolve this issue. Anticipating your response at the earliest.
Regards,
VIKHAR
Edited by: VIKHARAHMED on Apr 16, 2013 9:38 AM

Here is the alert log file
Media Recovery Log +FLASHDG/stby/archivelog/2013_04_16/thread_2_seq_1476.1987.812900733
Tue Apr 16 18:56:42 2013
Primary database is in MAXIMUM PERFORMANCE mode
RFS[1]: Assigned to RFS process 16803
RFS[1]: Selected log 12 for thread 2 sequence 1485 dbid 220323208 branch 808484882
Tue Apr 16 18:56:42 2013
RFS[2]: Assigned to RFS process 16807
RFS[2]: Opened log for thread 2 sequence 1484 dbid 220323208 branch 808484882
Archived Log entry 6324 added for thread 2 sequence 1484 rlc 808484882 ID 0xd21a288 dest 10:
Tue Apr 16 19:09:02 2013
RFS[1]: Selected log 11 for thread 2 sequence 1486 dbid 220323208 branch 808484882
Tue Apr 16 19:09:02 2013
Archived Log entry 6325 added for thread 2 sequence 1485 ID 0xd21a288 dest 1:
Archived Log entry 6326 added for thread 2 sequence 1485 ID 0xd21a288 dest 2:
Tue Apr 16 19:12:23 2013
RFS[1]: Selected log 12 for thread 2 sequence 1487 dbid 220323208 branch 808484882
Tue Apr 16 19:12:23 2013
Archived Log entry 6327 added for thread 2 sequence 1486 ID 0xd21a288 dest 1:
Archived Log entry 6328 added for thread 2 sequence 1486 ID 0xd21a288 dest 2:
Tue Apr 16 19:14:41 2013
"alert_stby.log" 845L, 33990C 782,1 94%
Tue Apr 16 19:17:27 2013
Archived Log entry 6331 added for thread 2 sequence 1488 ID 0xd21a288 dest 1:
Archived Log entry 6332 added for thread 2 sequence 1488 ID 0xd21a288 dest 2:
Tue Apr 16 19:25:51 2013
RFS[1]: Selected log 11 for thread 2 sequence 1490 dbid 220323208 branch 808484882
Tue Apr 16 19:25:51 2013
Archived Log entry 6333 added for thread 2 sequence 1489 ID 0xd21a288 dest 1:
Archived Log entry 6334 added for thread 2 sequence 1489 ID 0xd21a288 dest 2:
Tue Apr 16 19:51:02 2013
RFS[1]: Selected log 12 for thread 2 sequence 1491 dbid 220323208 branch 808484882
Tue Apr 16 19:51:02 2013
Archived Log entry 6335 added for thread 2 sequence 1490 ID 0xd21a288 dest 1:
Archived Log entry 6336 added for thread 2 sequence 1490 ID 0xd21a288 dest 2:
Tue Apr 16 20:37:12 2013
RFS[1]: Selected log 11 for thread 2 sequence 1492 dbid 220323208 branch 808484882
Tue Apr 16 20:37:12 2013
Archived Log entry 6337 added for thread 2 sequence 1491 ID 0xd21a288 dest 1:
Archived Log entry 6338 added for thread 2 sequence 1491 ID 0xd21a288 dest 2:
Tue Apr 16 21:08:23 2013
RFS[1]: Selected log 12 for thread 2 sequence 1493 dbid 220323208 branch 808484882
Tue Apr 16 21:08:23 2013
Archived Log entry 6339 added for thread 2 sequence 1492 ID 0xd21a288 dest 1:
Archived Log entry 6340 added for thread 2 sequence 1492 ID 0xd21a288 dest 2:
Tue Apr 16 22:16:06 2013
RFS[1]: Selected log 11 for thread 2 sequence 1494 dbid 220323208 branch 808484882
Tue Apr 16 22:16:06 2013
Archived Log entry 6341 added for thread 2 sequence 1493 ID 0xd21a288 dest 1:
Archived Log entry 6342 added for thread 2 sequence 1493 ID 0xd21a288 dest 2:
Tue Apr 16 22:31:46 2013
RFS[1]: Selected log 12 for thread 2 sequence 1495 dbid 220323208 branch 808484882
Tue Apr 16 22:31:46 2013
Archived Log entry 6343 added for thread 2 sequence 1494 ID 0xd21a288 dest 1:
Archived Log entry 6344 added for thread 2 sequence 1494 ID 0xd21a288 dest 2:
Wed Apr 17 09:31:59 2013
RFS[1]: Selected log 11 for thread 2 sequence 1496 dbid 220323208 branch 808484882
Wed Apr 17 09:32:00 2013
Archived Log entry 6345 added for thread 2 sequence 1495 ID 0xd21a288 dest 1:
Archived Log entry 6346 added for thread 2 sequence 1495 ID 0xd21a288 dest 2:

ORA-326/ORA-334 Physical Standby DB - Not applying logs

Hi, all, I have a Dataguard, the primary db is a RAC with three nodes, the standby db is a physical standby. the dataguard are all oracle 10.2.0.3 on solaris 9 sparc system
Now, my standby db did not apply the archivelogs,there are some errors in standby alert log :
Thu Jan 8 15:44:31 2009
Errors in file /oracle/admin/xxxx/bdump/whut_mrp0_12863.trc:
ORA-00326:log begins at change 2984028173, need earlier change 2984013192
ORA-00334:archived log '+DGARCH/whut/3_22648_611942629.dbf'
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Thu Jan 8 15:44:34 2009
Errors in file /export/home/oracle/admin/whut/bdump/whut_mrp0_12863.trc:
ORA-00326:log begins at change 2984028173, need earlier change 2984013192
ORA-00334:archived log '+DGARCH/whut/3_22648_611942629.dbf'
Thu Jan 8 15:44:34 2009
MRP0: Background Media Recovery process shutdown (whut)
and the archivelogs on the standby db like this :
NAME APP DEL
+DGARCH/whut/3_22651_611942629.dbf                           NO NO
+DGARCH/whut/3_22650_611942629.dbf                           NO NO
+DGARCH/whut/3_22649_611942629.dbf                           NO NO
+DGARCH/whut/3_22648_611942629.dbf                           NO NO
+DGARCH/whut/3_22648_611942629.dbf                           NO NO
+DGARCH/whut/3_22648_611942629.dbf                           NO YES
+DGARCH/whut/3_22291_611942629.dbf                           YES YES
+DGARCH/whut/2_62553_611942629.dbf                           NO NO
+DGARCH/whut/2_62552_611942629.dbf                           NO NO
+DGARCH/whut/2_62551_611942629.dbf                           NO NO
+DGARCH/whut/2_62550_611942629.dbf                           NO NO
query the first_change# on the standby db like this :
SEQUENCE# FIRST_CHANGE# APP ARC
22646 2983721221 NO YES
22647 2983911304 NO YES
22648 2984028173 NO YES
23813 2984013365 NO YES
23814 2984118027 NO YES
62546 2984027708 NO YES
SEQUENCE# FIRST_CHANGE# APP ARC
62547 2984163823 NO YES
23815 2984132128 NO YES
23816 2984312713 NO YES
62548 2984255538 NO YES
62549 2984312692 NO YES
22649 2984028196 NO YES
23817 2984351070 NO YES
then ,how to fix the dataguard and apply the archivelog on standby db ?
why I can found 2984028173 with 22648,but can not found 2984013192 ??
and why there have three 22648 with different applied status and deleted status on standby db ???
Thanks all.

Thank you for your reply.
the trc file like this:
/oracle/admin/xxx/bdump/xxx_mrp0_12863.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /oracle/product/10.2.0/database
System name:     SunOS
Node name:     stdb
Release:     5.9
Version:     Generic_122300-25
Machine:     sun4u
Instance name: xxx
Redo thread mounted by this instance: 1
Oracle process number: 27
Unix process pid: 12863, image: oracle@stdb (MRP0)
*** SERVICE NAME:() 2009-01-08 15:44:24.179
*** SESSION ID:(197.3) 2009-01-08 15:44:24.179
ARCH: Connecting to console port...
*** 2009-01-08 15:44:24.180 61287 kcrr.c
MRP0: Background Managed Standby Recovery process started
*** 2009-01-08 15:44:29.191 1103 krsm.c
Managed Recovery: Initialization posted.
*** 2009-01-08 15:44:29.192 61287 kcrr.c
Managed Standby Recovery starting Real Time Apply
Recovery target incarnation = 5, activation ID = 721050634
Influx buffer limit = 152383 (50% x 304766)
Successfully allocated 3 recovery slaves
Using 367 overflow buffers per recovery slave
Start recovery at thread 3 ckpt scn 2984013192 logseq 22648 block 2
*** 2009-01-08 15:44:31.181
Media Recovery add redo thread 3
*** 2009-01-08 15:44:31.181
Media Recovery add redo thread 1
*** 2009-01-08 15:44:31.182
Media Recovery add redo thread 2
*** 2009-01-08 15:44:31.184 1103 krsm.c
Managed Recovery: Active posted.
*** 2009-01-08 15:44:31.838
Media Recovery Log +DGARCH/whut/3_22648_611942629.dbf
*** 2009-01-08 15:44:31.851 61287 kcrr.c
MRP0: Background Media Recovery terminated with error 326
ORA-00326: log begin at 2984028173, need earlier 2984013192
ORA-00334: archivelog: '+DGARCH/whut/3_22648_611942629.dbf'
*** 2009-01-08 15:44:31.851 61287 kcrr.c
Managed Standby Recovery not using Real Time Apply
*** 2009-01-08 15:44:31.851
Media Recovery drop redo thread 3
*** 2009-01-08 15:44:31.851
Media Recovery drop redo thread 1
*** 2009-01-08 15:44:31.851
Media Recovery drop redo thread 2
*** 2009-01-08 15:44:34.269 1103 krsm.c
Managed Recovery: Not Active posted.
ORA-00326: log begin at 2984028173,need earlier 2984013192
ORA-00334: archivelog: '+DGARCH/whut/3_22648_611942629.dbf'
ARCH: Connecting to console port...
*** 2009-01-08 15:44:34.359 61287 kcrr.c
MRP0: Background Media Recovery process shutdown
*** 2009-01-08 15:44:34.359 1103 krsm.c

Standby database not applying archivelogs, manually apply after registering

Hi
I have a small problem with physical standby db.
Standby db was created and it was working fine, was applying logs with no problem. One day I had to switch it to read only mode, it stayed in this mode for quiet a while. Then there was a problem with space for archive logs. I fixed this, copied missing logs, registered them and these were applied.
And then database stopped on the sequence which was automatically registered by primary database.
v$managed_standby:
PROCESS STATUS CLIENT_P SEQUENCE# DELAY_MINS BLOCK#
ARCH CLOSING ARCH 19667 0 126977
ARCH CLOSING ARCH 19668 0 133121
MRP0 WAIT_FOR_LOG N/A 19600 0 0
As you can see there is WAIT_FOR_LOG sequence 19600 which should be applied, which is in the directory, to which oracle user has rights to read etc, etc.
Only way to force database to apply this log is to manually register it, but I have to add "or replace", because file is already registered.
/path/dbsid1_19600_668777138.log 2 19600 YES NO NO A 28-OCT-09 28-OCT-09
alter database register or replace physical logfile '/path/dbsid1_19600_668777138.log';
After this I have:
/path/dbsid_19600_668777138.log 2 19600 YES NO NO A 28-OCT-09 28-OCT-09
/path/dbsid_19600_668777138.log 0 19600 YES YES NO A 29-OCT-09 28-OCT-09
Registering this file causes applying at once.
In pfile on primary:
log_archive_dest_2 string SERVICE=DRSTDB2 ARCH DELAY=2880
Pay attention - destination 2.
Question is obvious - why logs are not applied automatically?
Why logs ARE applying manually but the DEST_ID is set to 0?
There was no major structure change in primary, besides - logs are applied after all. Bouncing the database doesn't give me any good, switching to readonly and back to recovery mode neither.
Please can you help? I can build this standby again but this is not a solution.
Any additional info on request.
Regards
Jarek Jozwik
Edited by: user11281267 on 30-Oct-2009 06:15

You haven't given any usefuly information on your problem.
show parameter log_archive_dest
show parameter fal
show parameter dg
What errors are in your alert logs ?
What command are you using to recover ?
Check the contents of v$archived_log
# run on primary to detect failures :-
select destination, status, fail_date, valid_now
from v$archive_dest
where status != 'VALID' or VALID_NOW != 'YES';
# run on standby to get exact position of rollforward :-
select thread#, to_char(snapshot_time,'dd-mon-yyyy:hh24:mi'),
to_char(applied_time,'dd-mon-yyyy:hh24:mi'),
to_char(newest_time,'dd-mon-yyyy:hh24:mi') from V$STANDBY_APPLY_SNAPSHOT;
Are you using dataguard broker ?

Logical Server NOT applying archives

Grid Control is showing all working fine, checked the configuration it show everything is fine. Logical server is receiving all the logs, but not applying. Can anyone tell WHY???
Thanks

Is logical server the standby server???. If yes, then is recovery managed cancelled.If so, then alter database recover managed standby database discconect from session; will start applying the archives automatically.
Anand

Standby log not applying

Hi folks,
Tried creating Data guard for the first time. Was able to successfully create a standby and on every log switch on primary database, a switch is seen on standby too..
But the issue is, log's are not getting applied on standby db..
SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            F:\app\product\11.2.0\dbhome_1\RDBMS
Oldest online log sequence     33
Next log sequence to archive   0
Current log sequence           38
SQL> SELECT sequence#, first_time, next_time, applied
2 FROM v$archived_log
3 ORDER BY sequence#;
SEQUENCE# FIRST_TIM NEXT_TIME APPLIED
*16 31-MAY-12 31-MAY-12 NO*
*17 31-MAY-12 31-MAY-12 NO*
*19 31-MAY-12 31-MAY-12 NO*
*20 31-MAY-12 31-MAY-12 NO*
*28 31-MAY-12 31-MAY-12 NO*
*29 31-MAY-12 31-MAY-12 NO*
*32 31-MAY-12 31-MAY-12 NO*
*34 31-MAY-12 31-MAY-12 NO*
*36 31-MAY-12 31-MAY-12 NO*
*37 31-MAY-12 31-MAY-12 NO*
*38 31-MAY-12 31-MAY-12 NO*
11 rows selected.
Also the alert log on strandby show's as...
Alert log on standby:
Thu May 31 23:30:43 2012
RFS[18]: Assigned to RFS process 3380
RFS[18]: Identified database type as 'physical standby': Client is ARCH pid 5780
RFS[18]: Selected log 4 for thread 1 sequence 36 dbid 196575176 branch 784736843
Thu May 31 23:30:45 2012
Archived Log entry 9 added for thread 1 sequence 36 ID 0xbb7cbc8 dest 1:
Thu May 31 23:30:45 2012
RFS[19]: Assigned to RFS process 4968
RFS[19]: Identified database type as 'physical standby': Client is LGWR ASYNC pid 5072
Primary database is in MAXIMUM PERFORMANCE mode
RFS[19]: Selected log 4 for thread 1 sequence 37 dbid 196575176 branch 784736843
Thu May 31 23:30:46 2012
RFS[20]: Assigned to RFS process 4996
RFS[20]: Identified database type as 'physical standby': Client is ARCH pid 5192
Thu May 31 23:30:47 2012
Archived Log entry 10 added for thread 1 sequence 37 ID 0xbb7cbc8 dest 1:
RFS[19]: Selected log 4 for thread 1 sequence 38 dbid 196575176 branch 784736843
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000010_0784736843.0001 (162 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_4996.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000010_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000010_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_4996.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000010_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000010_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:30:48 2012
RFS[21]: Assigned to RFS process 4508
RFS[21]: Identified database type as 'physical standby': Client is ARCH pid 5780
Thu May 31 23:30:48 2012
RFS[22]: Assigned to RFS process 1524
RFS[22]: Identified database type as 'physical standby': Client is ARCH pid 5308
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000009_0784736843.0001 (198 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_4508.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000009_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000009_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_4508.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000009_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000009_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000008_0784736843.0001 (17296 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_1524.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000008_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000008_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_1524.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000008_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000008_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:30:51 2012
RFS[23]: Assigned to RFS process 460
RFS[23]: Identified database type as 'physical standby': Client is ARCH pid 5192
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000011_0784736843.0001 (65 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_460.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000011_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000011_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_460.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000011_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000011_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:30:52 2012
RFS[24]: Assigned to RFS process 3456
RFS[24]: Identified database type as 'physical standby': Client is ARCH pid 5780
Thu May 31 23:30:52 2012
RFS[25]: Assigned to RFS process 1936
RFS[25]: Identified database type as 'physical standby': Client is ARCH pid 5308
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000012_0784736843.0001 (287 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_3456.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000012_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000012_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_3456.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000012_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000012_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000013_0784736843.0001 (10 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_1936.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000013_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000013_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_1936.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000013_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000013_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:30:56 2012
RFS[26]: Assigned to RFS process 5084
RFS[26]: Identified database type as 'physical standby': Client is ARCH pid 5192
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000014_0784736843.0001 (193 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_5084.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000014_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000014_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_5084.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000014_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000014_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:30:57 2012
RFS[27]: Assigned to RFS process 2404
RFS[27]: Identified database type as 'physical standby': Client is ARCH pid 5780
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000015_0784736843.0001 (8 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_2404.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000015_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000015_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_2404.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000015_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000015_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:36:48 2012
RFS[28]: Assigned to RFS process 2988
RFS[28]: Identified database type as 'physical standby': Client is ARCH pid 5192
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000010_0784736843.0001 (162 blocks)
Thu May 31 23:36:49 2012
RFS[29]: Assigned to RFS process 4152
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_2988.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000010_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000010_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
RFS[29]: Identified database type as 'physical standby': Client is ARCH pid 5308
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_2988.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000010_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000010_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:36:49 2012
RFS[30]: Assigned to RFS process 4128
RFS[30]: Identified database type as 'physical standby': Client is ARCH pid 5780
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000009_0784736843.0001 (198 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_4128.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000009_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000009_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_4128.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000009_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000009_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000008_0784736843.0001 (17296 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_4152.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000008_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000008_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_4152.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000008_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000008_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:36:51 2012
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_arc2_5596.trc:
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000038_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
ARC2: Error 19504 Creating archive log file to 'F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000038_0784736843.0001'
ARCH: Archival stopped, error occurred. Will continue retrying
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_arc2_5596.trc:
ORA-16038: log 4 sequence# 38 cannot be archived
ORA-19504: failed to create file ""
ORA-00312: online log 4 thread 1: 'F:\APP\ORADATA\STAN\SRL01.LOG'
Thu May 31 23:36:53 2012
RFS[31]: Assigned to RFS process 4340
RFS[31]: Identified database type as 'physical standby': Client is ARCH pid 5192
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000011_0784736843.0001 (65 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_4340.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000011_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000011_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_4340.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000011_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000011_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:36:54 2012
RFS[32]: Assigned to RFS process 3080
RFS[32]: Identified database type as 'physical standby': Client is ARCH pid 5780
Thu May 31 23:36:54 2012
RFS[33]: Assigned to RFS process 3296
RFS[33]: Identified database type as 'physical standby': Client is ARCH pid 5308
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000012_0784736843.0001 (287 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_3080.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000012_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000012_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_3080.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000012_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000012_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000013_0784736843.0001 (10 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_3296.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000013_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000013_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_3296.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000013_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000013_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:36:55 2012
RFS[34]: Assigned to RFS process 3464
RFS[34]: Identified database type as 'physical standby': Client is ARCH pid 5192
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000014_0784736843.0001 (193 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_3464.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000014_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000014_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_3464.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000014_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000014_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:36:57 2012
RFS[35]: Assigned to RFS process 6036
RFS[35]: Identified database type as 'physical standby': Client is ARCH pid 5780
Creating archive destination file : F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000015_0784736843.0001 (8 blocks)
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_6036.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000015_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000015_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Errors in file f:\app\diag\rdbms\stan\stan\trace\stan_rfs_6036.trc:
ORA-00270: error creating archive log F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000015_0784736843.0001
ORA-19504: failed to create file "F:\APP\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000015_0784736843.0001"
ORA-27056: could not delete file
OSD-04024: Unable to delete file.
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.
Thu May 31 23:37:09 2012
Archived Log entry 11 added for thread 1 sequence 38 ID 0xbb7cbc8 dest 1:
Archiver process freed from errors. No longer stopped
confirmed that there is enough space and proper permission on the folder's..
someone please suggest what could have gone wrong??
Regards!

Hello again;
So I both servers log_archive_dest_1 is not set?
The Oracle example is
Primary
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago'
Standby
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/boston/VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'
If a fast recovery area was configured (with the DB_RECOVERY_FILE_ DEST initialization parameter) and you have not explicitly configured a local archiving destination with the LOCATION attribute, Data Guard automatically
uses the LOG_ARCHIVE_DEST_1 initialization parameter (if it has not already been set) as the default destination for local archiving. Also, see Chapter 15 for complete LOG_ARCHIVE_DEST_n information.
My take is since you are not using FRA this parameter is not defined by default. I would probably set it on both, but frankly I'm not sure this will solve your issue. If it does I would sure like to know about it so i can add it to my notes.
Not related to your issue
Would consider setting standby_file_management to 'Auto' on both.
Would consider setting log_archive_dest_state_2 to 'DEFER' on the Standby.
Best Regards
mseberg
Would

10gR2 Logical Standby database not applying logs

No errors are appearing in the logs and I've started the apply process :ALTER DATABASE START LOGICAL STANDBY APPLY but when I query dba_logstdby_log, none of the logs for the last 4 days shows as applied and the first SCN is still listed as current. Any thoughts on where I should start looking?
the latest event in DBA_LOGSTDBY_EVENTS is the startup of the log mining and apply.
I do not have standby redo logs so I cannot do real time apply, though I am looking to implementing this. Obviously, this is pretty new to me.

Sorry I didn't mention this before, the logs are being transferred, I verified their location on the os and it matches the location in the dba_logstdby_log view.

Standby DB not applying logs

Hi,
i opened my primary DB using "alter database open resetlogs" after recovering from a power failure crash.
this caused the log sequence number to reset to 1.
when i check the standby DB for maximum log sequence applied, it is showing the last log applied before the crash whereas the primary DB has since the recovery, produced over 200 logs.
how can i get the standby DB to start applying the new log sequence?
regards,
Michael

If you had opened the Primary with a RESETLOGS to a point earlier than the highest log applied on the standby and you cannot flashback the standby, you have to rebuild the standby.
For example, the Standby has applied Sequence#1411 but the Primary was opened with RECOVER upto Sequence#1409 and RESETLOGS. The Primary has diverged from the Standby so the standby has to be rebuilt.
If however, the last redo applied to the Standby was lower than the RECOVER and RESETLOGS point on the primary, the Standby should be automatically able to continue. In your case, you say that the Standby hasn't continued. Therefore, I suspect the former (Primary RECOVER and RESETLOGS to a lower SCN/SEQUENCE#).
See "9.4 Recovering Through the OPEN RESETLOGS Statement" at http://docs.oracle.com/cd/E11882_01/server.112/e25608/manage_ps.htm#i1026480
Hemant K Chitale

How to apply archive in Standby Database?

Hello,
My Database are running in linux plateform. I am seeing that archives which are generating are not copying to standby server & not applying.
Can anybody suggest me how to copy archive from primary database(ASM file system) to standby Database & apply those archives?
Thanks

Hi,
I am having similar problem. The primary logs are shipping on to standby but are not getting applied.
Here are the outputs:
From primary
SQL > select thread#,max(sequence#) from v$archived_log where archived='YES' group by thread#;
THREAD# MAX(SEQUENCE#)
1 27908
2 28476
3 31643
select max(sequence#) from gv$archived_log;
MAX(SEQUENCE#)
31643
From Standby
SQL > select thread#,max(sequence#) from v$archived_log where applied ='YES' group by thread#;
THREAD# MAX(SEQUENCE#)
1 26862
2 27580
3 30874
select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
31643
Any help is appreciated.
Thanks in advance.

Standby not applying the online redo logs

Hi,
The redo apply process does not seem to apply the current logs to the standby database.
The output from the query
Select last_change#, sequence# from v$standby_log;
LAST_CHANGE# GROUP# SEQUENCE#
4 0
10120537 5 8586
6 0
7 0
gives me the current SCN as that of the primary.
But the CURRENT_SCN from v$database on the standby lags from that of the output above.
Select CURRENT_SCN from v$database;
CURRENT_SCN
10119641
The STATUS and PROCESS information from the v$managed_standby show the following:
PROCESS STATUS SEQUENCE#
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
RFS IDLE 0
RFS IDLE 0
RFS IDLE 8586
RFS IDLE 0
RFS IDLE 0
RFS IDLE 0
RFS IDLE 0
PROCESS STATUS SEQUENCE#
MRP0 APPLYING_LOG 8586
Any thoughts on why the standby has not applied the recived logs from the primary?
I am currently using version Oracle 11.2.0.2 for Active dataguard setup. I currently have a primary server and one standy server.
Thanks

I had sent the output of the queries in the earlier post. Here it is again
The output for the query
select thread#, max(sequence#) from v$archived_log group by thread#; (on primary)
THREAD# MAX(SEQUENCE#)
1 8585
The output for
select thread#, max(sequence#) from v$archived_log where applied = 'YES' group by thread#; (on standby)
THREAD# MAX(SEQUENCE#)
1 8585
Also the query
select LAST_CHANGE#, STATUS from V$STANDBY_LOG;
gives me the current scn generated at the primary.
LAST_CHANGE# STATUS
10149990 ACTIVE
10146538 ACTIVE
10150844 ACTIVE
But the current_scn from v$database is lagging.
select current_scn from v$database;
CURRENT_SCN
10146535
Also the query
select THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# from v$archive_gap;
returns no rows. So there are no archive logs missing on the standby either.
So I beleive that the RFS has recieved the logs from the primary but the logs have not been applied at the standby.
Thanks

Archive log registered,but showing as not applied in standby db + oracle 9i

Hi all,
In my standby database some of the archive log files are not applied.found through the following command
SQL > select sequence#,applied from v$archived_log where applied='NO';
sequence# APP FIRST_TIME
18425 NO 05-FEB-10
but when try to register manually
SQL > alter database register logfile '/disk12/arch/A00123000018425.arc';
ERROR at line 1
ORA-16089:archive log has already been registered.
"recover standby database" also asking for the new archive file. how will i apply that?
any solutions?

user11919409 wrote:
I have did that so many times from 05-feb-10 onwards.
even then only one archive gap???
or only one is not applied? if yes may be archive file which exist at standby may be corrupt try to restore it from backup and recover.
also check for some clues at logs at standby and primary.. what actually happen. if archive gap is huge and you have all archvies then you may have to do manual recovery then keep it back to auto recovery mode.
Hope that may help you.
Anil Malkai

Archive logs not applied on standby!!

Hi Guys,
I am trying to set up physical standby on windows 2003 server. I am using oracle 10.2.0.4.0. I get the following error in my alert file on standby
Failed to request gap sequence
Following is the results of some queries :
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
MR(fg) WAIT_FOR_GAP 1 10004 0 0
SQL> select * from v$archive_gap;
no rows selected
SQL> select message from v$dataguard_status;
MESSAGE
ARC0: Archival started
ARC1: Archival started
ARC2: Archival started
ARC3: Archival started
ARC4: Archival started
ARC5: Archival started
ARC6: Archival started
ARC7: Archival started
ARC8: Archival started
ARC9: Archival started
ARC0: Becoming the 'no FAL' ARCH
MESSAGE
ARC0: Becoming the 'no SRL' ARCH
ARC1: Becoming the heartbeat ARCH
Attempt to start background Managed Standby Recovery process
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery not using Real Time Apply
Media Recovery Waiting for thread 1 sequence 10004
Fetching gap sequence in thread 1, gap sequence 10004-10017
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 10004-10017
DBID 2422302575 branch 670594799
FAL[client]: All defined FAL servers have been attempted.
MESSAGE
MRP0: Background Media Recovery cancelled with status 16037
MRP0: Background Media Recovery process shutdown
Managed Standby Recovery Canceled
Media Recovery Start: Managed Standby Recovery
Managed Standby Recovery not using Real Time Apply
Media Recovery Waiting for thread 1 sequence 10004
Fetching gap sequence in thread 1, gap sequence 10004-10017
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 10004-10017
DBID 2422302575 branch 670594799
FAL[client]: All defined FAL servers have been attempted.
SQL>SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG
where applied= 'YES'
no rows selected
##Modification to primary##
*.log_archive_dest_2='SERVICE=STANDBY'
*.fal_client='STUTEST'
*.fal_server='STUSTANDBY'
*.log_archive_config='DG_CONFIG=(STUTEST,STUSTANDBY)'
##Modification to standby##
*.db_unique_name='STANDBY'
*.log_archive_dest_2='SERVICE=STANDBY'
*.log_archive_dest_state_2='ENABLE'
*.Fal_server=STUTEST
*.Fal_client=STUSTANDBY
*.db_file_name_convert='H:\ORACLE\ORADATA\STUTEST\','I:\ORACLE\ORADATA\STUTEST\s_'
*.log_file_name_convert='D:\oracle\oradata\STUTEST\','D:\oracle\oradata\STUTEST\s_'
Nore: I used RMAN to create the standby database. The following are brief steps
Below are the steps to accomplish the task :
Step 1: Backup the database that includes backup of datafiles, archivelogs and controlfile for standby
backup current controlfile for standby;
Step 2: Move the backups to the standby server and restore control file from backup
Step 3: Make changes in the parameter files of both primary and standby database
Step 4: Do the restore and recover on standby database
Step 5: Put the standby database in recover managed mode
Thanks for help guys!!!!!

Hi sb92075
Alert log on standby
alter database mount standby database
Mon Jul 26 14:10:40 2010
Setting recovery target incarnation to 1
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=21, OS id=6708
ARC1 started with pid=22, OS id=3892
ARC2 started with pid=23, OS id=4380
ARC3 started with pid=24, OS id=4896
ARC4 started with pid=25, OS id=6348
ARC5 started with pid=26, OS id=5868
ARC6 started with pid=27, OS id=6904
ARC7 started with pid=28, OS id=4428
ARC8 started with pid=29, OS id=5008
Mon Jul 26 14:10:40 2010
ARC0: Archival started
ARC9 started with pid=30, OS id=5804
Mon Jul 26 14:10:41 2010
ARC1: Archival started
ARC2: Archival started
ARC3: Archival started
ARC4: Archival started
ARC5: Archival started
ARC6: Archival started
ARC7: Archival started
ARC8: Archival started
ARC9: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
Mon Jul 26 14:10:41 2010
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
ARC0: Thread not mounted
Mon Jul 26 14:10:41 2010
Successful mount of redo thread 1, with mount id 2477113436
Mon Jul 26 14:10:41 2010
Physical Standby Database mounted.
Mon Jul 26 14:10:42 2010
ARC1: Becoming the heartbeat ARCH
Completed: alter database mount standby database
Mon Jul 26 14:10:42 2010
Errors in file c:\oracle\admin\stustandby\udump\stustandby_ora_6604.trc:
Mon Jul 26 14:11:41 2010
alter database recover managed standby database disconnect from session
MRP0 started with pid=19, OS id=3696
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 7 processes
Mon Jul 26 14:11:46 2010
Waiting for all non-current ORLs to be archived...
Media Recovery Waiting for thread 1 sequence 10004
Fetching gap sequence in thread 1, gap sequence 10004-10017
Mon Jul 26 14:11:47 2010
Completed: alter database recover managed standby database disconnect from session
Mon Jul 26 14:12:16 2010
*FAL[client]: Failed to request gap sequence*
GAP - thread 1 sequence 10004-10017
DBID 2422302575 branch 670594799
*FAL[client]: All defined FAL servers have been attempted.*
Alert log on primary
Mon Jul 26 13:50:11 2010
db_recovery_file_dest_size of 40960 MB is 49.73% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Mon Jul 26 13:50:12 2010
Successfully onlined Undo Tablespace 19.
Mon Jul 26 13:50:12 2010
SMON: enabling tx recovery
Mon Jul 26 13:50:12 2010
Database Characterset is WE8ISO8859P1
Opening with internal Resource Manager plan
where NUMA PG = 1, CPUs = 8
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=38, OS id=3776
Mon Jul 26 13:50:14 2010
Completed: ALTER DATABASE OPEN
Mon Jul 26 13:51:10 2010
Shutting down archive processes
Mon Jul 26 13:51:15 2010
ARCH shutting down
ARCa: Archival stopped
Mon Jul 26 14:11:47 2010
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
*FAL[server]: DGID from FAL client not in Data Guard configuration*
*FAL[server]: FAL request for destination STUSTANDBY was:*
GAP - thread 1 sequence 10004-10017
DBID 2422302575 branch 670594799
Mon Jul 26 15:04:10 2010
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
*FAL[server]: DGID from FAL client not in Data Guard configuration*
*FAL[server]: FAL request for destination STUSTANDBY was:*
GAP - thread 1 sequence 10004-10017 DBID 2422302575 branch 670594799

Archives are not applying on 2nd standby

Hi,
i have one primary and two standby DBs in different servers.
archives are applying to one standby only,not appling to another.
what are the things i need to check? please guide me

Hi,
archives are not applying that are received from primary
on standby DB:
SQL>select SEQUENCE#,APPLIED from v$archived_log;
UENCE# APP
393 NO
387 NO
388 NO
389 NO
on standby ihaven't seen MRP process,but i have given sql comd like
SQL> alter database recover managed standby database disconnect from session;
on standby it's displying
SQL> select PROCESS,STATUS from v$managed_standby;
PROCESS STATUS
ARCH CLOSING
ARCH CLOSING
RFS WRITING
RFS RECEIVING
RFS RECEIVING
here there is no MRP process,plz tell me where is the mistake.

Standby database is not applying redo logs due to missing archive log

We use 9.2.0.7 Oracle Database. My goal is to create a physical standby database.
I have followed all the steps necessary to fulfill this in Oracle Data Guard Concepts and Administration manual. Archived redo logs are transmitted from primary to standby database regularly. But the logs are not applied due to archive log gap.
SQL> select process, status from v$managed_standby;
PROCESS STATUS
ARCH CONNECTED
ARCH CONNECTED
MRP0 WAIT_FOR_GAP
RFS RECEIVING
RFS ATTACHED
SQL> select * from v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
1 503 677
I have tried to find the missing archives on the primary database, but was unable to. They have been deleted (somehow) regularly by the existing backup policy on the primary database. I have looked up the backups, but these archive logs are too old to be in the backup. Backup retention policy is 1 redundant backup of each file. I didn't save older backups as I didn't really need them from up to this point.
I have cross checked (using rman crosscheck) the archive log copies on the primary database and deleted the "obsolete" copies of archive logs. But, v$archived_log view on the primary database only marked those entries as "deleted". Unfortunately, the standby database is still waiting for those logs to "close the gap" and doesn't apply the redo logs at all. I am reluctant to recreate the control file on the primary database as I'm afraid this occurred through the regular database backup operations, due to current backup retention policy and it probably might happen again.
The standby creation procedure was done by using the data files from 3 days ago. The archive logs which are "producing the gap" are older than a month, and are probably unneeded for standby recovery.
What shall I do?
Kind regards and thanks in advance,
Milivoj

On a physical standby database
To determine if there is an archive gap on your physical standby database, query the V$ARCHIVE_GAP view as shown in the following example:
SQL> SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
1 7 10
The output from the previous example indicates your physical standby database is currently missing log files from sequence 7 to sequence 10 for thread 1.
After you identify the gap, issue the following SQL statement on the primary database to locate the archived redo log files on your primary
database (assuming the local archive destination on the primary database is LOG_ARCHIVE_DEST_1):
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND 2> SEQUENCE# BETWEEN 7 AND 10;
NAME
/primary/thread1_dest/arcr_1_7.arc /primary/thread1_dest/arcr_1_8.arc /primary/thread1_dest/arcr_1_9.arc
Copy these log files to your physical standby database and register them using the ALTER DATABASE REGISTER LOGFILE statement on your physical standby database. For example:
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_7.arc';
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_8.arc';
After you register these log files on the physical standby database, you can restart Redo Apply.
Note:
The V$ARCHIVE_GAP fixed view on a physical standby database only returns the next gap that is currently blocking Redo Apply from continuing. After resolving the gap and starting Redo Apply, query the V$ARCHIVE_GAP fixed view again on the physical standby database to determine the next gap sequence, if there is one. Repeat this process until there are no more gaps.
Restoring the archived logs from the backup set
If the archived logs are not available in the archive destination then at that time we need to restore the required archived logs from the backup step. This task is accomplished in the following way.
To restore range specified archived logs:
Run {
Set archivelog destination to '/oracle/arch/arch_restore'
Restore archivelog from logseq=<xxxxx> until logseq=<xxxxxxx>
To restore all the archived logs:
Run {
Set archivelog destination to '/oracle/arch/arch_restore';
Restore archivelog all;
}

Standby do not applied archives

Similar Messages

Maybe you are looking for