Archive not applying on dr database

Hi All,
Archive log are transferring from primary db to standby db.but archive are not applying on dr database.
Below alert log of dr database
ORA-16037: user requested cancel of managed recovery operation
Fri Jan 14 17:05:40 2011
MRP0: Background Media Recovery process shutdown (QMSSTB)
Fri Jan 14 17:05:41 2011
Managed Standby Recovery Canceled (QMSSTB)
Fri Jan 14 17:05:41 2011
Completed: alter database recover managed standby database cancel
Fri Jan 14 17:07:56 2011
alter database recover managed standby database disconnect from session
Fri Jan 14 17:07:56 2011
Attempt to start background Managed Standby Recovery process (QMSSTB)
MRP0 started with pid=19, OS id=823510
Fri Jan 14 17:07:56 2011
MRP0: Background Managed Standby Recovery process started (QMSSTB)
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 2 processes
Fri Jan 14 17:08:01 2011
Waiting for all non-current ORLs to be archived...
Clearing online redo logfile 1 /oradb/oradata/QMSPROD/redo01.log
Clearing online log 1 of thread 1 sequence number 3401
Fri Jan 14 17:08:01 2011
Errors in file /oradb/oradata/QMSPROD/bdump/qmsstb_mrp0_823510.trc:
ORA-19527: physical standby redo log must be renamed
ORA-00312: online log 1 thread 1: '/oradb/oradata/QMSPROD/redo01.log'
Clearing online redo logfile 1 complete
Media Recovery Waiting for thread 1 sequence 3401 (in transit)
Fri Jan 14 17:08:02 2011
Completed: alter database recover managed standby database disconnect from session

Hi all,
Dr database query
SQL> select sequence#,applied from v$archived_log order by 1;
SEQUENCE# APP
3401 NO
3401 NO
3402 NO
3403 NO
3404 NO
3405 NO
3406 NO
3407 NO
3408 NO
3409 NO
3410 NO
SEQUENCE# APP
3411 NO
3412 NO
3413 NO
3414 NO
3415 NO
3416 NO
3417 NO
3418 NO
3419 NO
3420 NO
3421 NO
SEQUENCE# APP
3422 NO
3423 NO
3424 NO
SQL> select process,status,sequence# from v$managed_standby
2 ;
PROCESS STATUS SEQUENCE#
ARCH CONNECTED 0
ARCH CONNECTED 0
MRP0 WAIT_FOR_LOG 3401
RFS IDLE 3401
RFS RECEIVING 0
RFS RECEIVING 0

Similar Messages

Redo log files are not applying to standby database

Hi everyone!!
I have created standby database on same server ( windows XP) and using oracle 11g . I want to synchronize my standby database with primary database . So I tried to apply redo logs from primary to standby database as follow .
My standby database is open and Primary database is not started (instance not started) because only one database can run in Exclusive Mode as DB_NAME is same for both database. I run the following command on the standby database.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
It returns "Database altered" . But when I checked the last archive log on primary database, its sequence is 189 while on standby database it is 177. That mean archived redo logs are not applied on standby database.
The tnsnames.ora file contains entry for both service primary & standby database and same service has been used to transmit and receive redo logs.
1. How to resolve this issue ?
2.Is it compulsory to have Primary database open ?
3. I have created standby control file by using command
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘D:\APP\ORACLE\ORADATA\TESTCAT\CONTROLFILE\CONTROL_STAND1.CTL‘;
So database name in the standby control file is same as primary database name (PRIM). And hence init.ora file of standby database also contains DB_NAME = 'PRIM' parameter. I can't change it because it returns error of mismatch database name on startup. Should I have different database name for both or existing one is correct ?
Can anybody help me to come out from this stuck ?
Thanks & Regards
Tushar Lapani

Thank you Girish. It solved my redo apply problem. I set log_archive_dest parameter again and then I checked archive redo log sequence number. It was same for both primary and standby database. But still table on standby database is not being refresh.
I did following scenario.
1. Inserted 200000 rows in emp table of Scott user on Primary database and commit changes.
2. Then I synchronized standby database by using Alter database command. And I also verify that archive log sequence number is same for both database. It mean archived logs from primary database has been applied to standby database.
3. But when I count number of rows in emp table of scott user on standby database, it returns only 14 rows even of redo log has been applied.
So my question is why changes made to primary database is not reflected on standby database although redo logs has been applied ?
Thanks

Archive logs not applied on logical database.

I have 10.2.04 oracle logical dataguard on windows:
The logs are trasported smoothly from primary to stanby;
But they are not applied to the logical standby;
There are no GAPS.
This is the message i got from DG broker wehn i ran verify configuration
Initializing
Connected to instance I-AG1101:tito
Starting alert log monitor...
Updating Data Guard link on database homepage...
Data Protection Settings:
Protection mode : Maximum Performance
Redo Transport Mode settings:
hclistg: ASYNC
hclidg: ASYNC
Checking standby redo log files.....OK
Checking Data Guard status
hclistg : Normal
hclidg : Normal
Checking Inconsistent Properties
Checking agent status
hclistg ... OK
hclidg ... WARNING: No credentials available for target. I-SAG1151
Attempting agent ping ... OK
Switching log file 420.Done
Checking applied log on hclidg.......WARNING:
Timed out after 60 seconds waiting for log to be applied.
Processing completed.
This is the results of query: SELECT SEQUENCE#, FIRST_TIME, APPLIED
FROM DBA_LOGSTDBY_LOG
ORDER BY SEQUENCE#;
SEQUENCE#|FIRST_TIME|APPLIED
391|3/31/2010 1:08:27 PM|CURRENT
392|3/31/2010 3:10:19 PM|NO
393|3/31/2010 3:47:05 PM|NO
394|3/31/2010 3:47:13 PM|NO
395|3/31/2010 3:47:40 PM|NO
396|3/31/2010 3:47:46 PM|NO
397|3/31/2010 3:50:14 PM|NO
398|3/31/2010 3:50:20 PM|NO
399|3/31/2010 3:54:01 PM|NO
400|3/31/2010 3:54:36 PM|NO
401|3/31/2010 3:54:43 PM|NO
402|3/31/2010 3:56:24 PM|NO
403|3/31/2010 3:56:30 PM|NO
404|3/31/2010 4:00:46 PM|NO
405|3/31/2010 4:34:03 PM|NO
406|3/31/2010 4:35:31 PM|NO
407|3/31/2010 5:38:57 PM|NO
408|4/1/2010 7:30:25 AM|NO
409|4/1/2010 11:45:23 AM|NO
410|4/1/2010 11:47:06 AM|NO
411|4/1/2010 2:26:25 PM|NO
412|4/1/2010 2:26:43 PM|NO
413|4/1/2010 2:26:44 PM|NO
414|4/1/2010 2:28:13 PM|NO
415|4/1/2010 5:08:12 PM|NO
416|4/1/2010 5:08:19 PM|NO
417|4/1/2010 5:08:52 PM|NO
418|4/2/2010 10:31:19 AM|NO
419|4/2/2010 10:35:06 AM|NO
420|4/2/2010 11:24:27 AM|NO
Please help,,,

i am getting this error when i run alter database mount standby database
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 1610612736 bytes
Fixed Size 1299288 bytes
Variable Size 545262760 bytes
Database Buffers 1056964608 bytes
Redo Buffers 7086080 bytes
SQL> alter database mount standby database;
alter database mount standby database
ERROR at line 1:
ORA-01665: control file is not a standby control file
I configured my logical DG using Grid control

Archive not applying

Setup: - Oracle 10.2.0.4 EE on HP-UX 11.23
Two weeks ago we got our DG physical standby setup working, initial tests looked good, I could tail both primary and standby alert logs and see results of log switches, everything looked good for about a week. Then ..
One morning I came in and logs weren't shipping. Checked the standby site and it had lost its mounts to the NAS. So far out setup was more proof of concept and I was getting ready to take a week off. So on the primary I set log arch dest 2 status to DEFER. In my absence our SA fixed the problem with mounting the fs and restarted the standby db (he's not a dba and just did a normal startup). I returned to the office this morning and find dest2 status back to ENABLE. But it appears that archivelogs are not applying.
Prior to the crash, as redo was received at the standy, its alert would show
Wed May 25 18:38:11 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[39]: Successfully opened standby log 5: '/oradata/ora_redo/BOSTON/sbyredo05a.rdo'
Wed May 25 18:38:17 2011
Media Recovery Waiting for thread 1 sequence 3123 (in transit)
Wed May 25 18:38:17 2011
Recovery of Online Redo Log: Thread 1 Group 5 Seq 3123 Reading mem 0
Mem# 0: /oradata/ora_redo/BOSTON/sbyredo05a.rdo
Mem# 1: /archive/ora_redo/BOSTON/sbyredo05b.rdoAfter the standby was restarted, I don't see the above sequence, but instead get
Fri Jun 3 07:27:09 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[28]: Successfully opened standby log 4: '/oradata/ora_redo/BOSTON/sbyredo04a.rdo'
Fri Jun 3 07:28:49 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[28]: Successfully opened standby log 5: '/oradata/ora_redo/BOSTON/sbyredo05a.rdo'
Fri Jun 3 07:31:15 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[28]: Successfully opened standby log 4: '/oradata/ora_redo/BOSTON/sbyredo04a.rdo'
Fri Jun 3 08:39:47 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[28]: Successfully opened standby log 5: '/oradata/ora_redo/BOSTON/sbyredo05a.rdo'It appears that I have exceeded control_file_record_keep_time. This showed up in the standby alert
Mon Jun 6 08:25:47 2011
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 3126-3224
DBID 2542058214 branch 737468006
FAL[client]: All defined FAL servers have been attempted.
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.
-------------------------------------------------------------On primary:
SQL> show parameter CONTROL_FILE_RECORD_KEEP_TIME
NAME TYPE VALUE
control_file_record_keep_time integer 7
SQL>I could take the "easy" way out and rebuild the standby from a fresh backup of primary, but before doing that would like to learn what I can from this, as I'm still pretty new to managaing a DB setup.

Mon Jun 6 08:25:47 2011
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 3126-3224
DBID 2542058214 branch 737468006
FAL[client]: All defined FAL servers have been attempted.
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.
-------------------------------------------------------------Actually these information from alert logfile regarding CONTROL_FILE_RECORD_KEEP_TIME it shows any Archive gap found on standby even if it set to *30* days. It is very generic information, Nothing to worry,
Fri Jun 3 07:27:09 2011
Primary database is in MAXIMUM PERFORMANCE mode<RFS[28]: Successfully opened standby log 4: '/oradata/ora_redo/BOSTON/sbyredo04a.rdo'
In above information, Whenever a archive ship from primary to standby it will assigned to logfile on standby. This is also very normal behaviour.
I could take the "easy" way out and rebuild the standby from a fresh backup of primary, but before doing that would like to learn what I can from this, as I'm still pretty new to managaing a DB setup.
According to your archive log gap GAP - thread 1 sequence 3126-3224 it is not an big, Why you want to rebuild.?
Check what is the errors on primary alert log file.
Post from PRIMARY:-
show parameter dest_state_2select ds.dest_id id
, ad.status
, ds.database_mode db_mode
, ad.archiver type
, ds.recovery_mode
, ds.protection_mode
, ds.standby_logfile_count "SRLs"
, ds.standby_logfile_active active
, ds.archived_seq#
from v$archive_dest_status ds
, v$archive_dest ad
where ds.dest_id = ad.dest_id
and ad.status != 'INACTIVE'
order by
ds.dest_id
select error_code,timestamp, message from v$dataguard_status where dest_id=2;Thanks.

All logs received but not applied | Physical Standby Database

All,
Need your help....
We have physical standby database setup as below
Primary : 2 node RAC
Stdby : Standalone physical standby database.
When I verify the stdby database status, I could see all the logs are received from primary but still not applied many.. Could any one please help me what is the issue and how to resolve it ...?
Primary :
=====
SQL> SELECT THREAD# "Thread",SEQUENCE# "Last Sequence Generated"
FROM V$ARCHIVED_LOG
WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)
ORDER BY 1 2 3 4 ;
Thread Last Sequence Generated
1 8073
1 8073
2 4521
2 4521
stdby:
====
SQL> SELECT ARCH.THREAD# "Thread",
2 ARCH.SEQUENCE# "Last Sequence Received",
3 APPL.SEQUENCE# "Last Sequence Applied",
4 (ARCH.SEQUENCE# - APPL.SEQUENCE#) "Difference"
5 FROM
6 (SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE (THREAD#,FIRST_TIME ) IN
7 (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH,
8 (SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY WHERE (THREAD#,FIRST_TIME ) IN
(SELECT THREAD#,MAX(FIRST_TIME) FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL
9 10 WHERE ARCH.THREAD# = APPL.THREAD# ORDER BY 1;
Thread Last Sequence Received Last Sequence Applied Difference
1 8073 8055 18
2 4521 4510 11
--Below are tailed messages from standby alert log:
Fri Nov 04 10:45:15 2011
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance BWFCCSTD - Archival Error
ORA-16014: log 6 sequence# 8058 not archived, no available destinations
ORA-00312: online log 6 thread 1: '+ASM_DATA01/bwfccstd/onlinelog/group_6.418.766235259'
ORA-00312: online log 6 thread 1: '+ASM_FRA01/bwfccstd/onlinelog/group_6.307.766235263'
Fri Nov 04 10:50:15 2011
Archiver process freed from errors. No longer stopped
Fri Nov 04 10:50:15 2011
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance BWFCCSTD - Archival Error
ORA-16014: log 6 sequence# 8058 not archived, no available destinations
ORA-00312: online log 6 thread 1: '+ASM_DATA01/bwfccstd/onlinelog/group_6.418.766235259'
ORA-00312: online log 6 thread 1: '+ASM_FRA01/bwfccstd/onlinelog/group_6.307.766235263'
Fri Nov 04 10:50:15 2011
Archiver process freed from errors. No longer stopped
Fri Nov 04 10:55:15 2011
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance BWFCCSTD - Archival Error
ORA-16014: log 6 sequence# 8058 not archived, no available destinations
ORA-00312: online log 6 thread 1: '+ASM_DATA01/bwfccstd/onlinelog/group_6.418.766235259'
ORA-00312: online log 6 thread 1: '+ASM_FRA01/bwfccstd/onlinelog/group_6.307.766235263'
Fri Nov 04 11:00:15 2011
Archiver process freed from errors. No longer stopped
Fri Nov 04 11:00:15 2011
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance BWFCCSTD - Archival Error
ORA-16014: log 6 sequence# 8058 not archived, no available destinations
ORA-00312: online log 6 thread 1: '+ASM_DATA01/bwfccstd/onlinelog/group_6.418.766235259'
ORA-00312: online log 6 thread 1: '+ASM_FRA01/bwfccstd/onlinelog/group_6.307.766235263'
Fri Nov 04 11:00:15 2011
Archiver process freed from errors. No longer stopped
Fri Nov 04 11:05:16 2011
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance BWFCCSTD - Archival Error
ORA-16014: log 6 sequence# 8058 not archived, no available destinations
ORA-00312: online log 6 thread 1: '+ASM_DATA01/bwfccstd/onlinelog/group_6.418.766235259'
ORA-00312: online log 6 thread 1: '+ASM_FRA01/bwfccstd/onlinelog/group_6.307.766235263'
Fri Nov 04 11:05:16 2011
Archiver process freed from errors. No longer stopped

Primary:
=====
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination +ASM_FRA01
Oldest online log sequence 8073
Next log sequence to archive 8074
Current log sequence 8074
SQL>
Stdby:
=====
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination ?/dbs/arch
Oldest online log sequence 8074
Next log sequence to archive 0
Current log sequence 8074
Enough space is available :
=================
SQL> set lines 180 pages 50000;
SQL> set lines 100
col name format a60
select name
, floor(space_limit / 1024 / 1024) "Size MB"
, ceil(space_used / 1024 / 1024) "Used MB"
from v$recovery_file_dest
order by nameSQL> SQL> 2 3 4 5 ;
NAME Size MB Used MB
+ASM_FRA01 70000 531
Edited by: 889828 on 2011/11/04 2:26 AM

Logs not applying on Standby Database

I am afraid I am back.
I now have a primary database and a standby database and logs are being shipped but not applied. Done some research and I have got to the point where in my alert log I find the following when I try to start MRP:
Fri Jun 29 15:03:40 2012
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (SAPDS)
Fri Jun 29 15:03:40 2012
MRP0 started with pid=29, OS id=23272
MRP0: Background Managed Standby Recovery process started (SAPDS)
started logmerger process
Fri Jun 29 15:03:45 2012
Managed Standby Recovery not using Real Time Apply
Read of datafile '/var/hpsrp/drforp03/oradata/u04/SAPDS/DRFSAPDS/sysaux01.dbf' (fno 2) header failed with ORA-01206
Rereading datafile 2 header failed with ORA-01206
MRP0: Background Media Recovery terminated with error 1110
Errors in file /var/hpsrp/drforp03/oradata/u04/SAPDS/admin/diag/rdbms/drfsapds/SAPDS/trace/SAPDS_pr00_23308.trc:
ORA-01110: data file 2: '/var/hpsrp/drforp03/oradata/u04/SAPDS/DRFSAPDS/sysaux01.dbf'
ORA-01122: database file 2 failed verification check
ORA-01110: data file 2: '/var/hpsrp/drforp03/oradata/u04/SAPDS/DRFSAPDS/sysaux01.dbf'
ORA-01206: file is not part of this database - wrong database id
Recovery Slave PR00 previously exited with exception 1110
Errors in file /var/hpsrp/drforp03/oradata/u04/SAPDS/admin/diag/rdbms/drfsapds/SAPDS/trace/SAPDS_mrp0_23272.trc:
ORA-01110: data file 2: '/var/hpsrp/drforp03/oradata/u04/SAPDS/DRFSAPDS/sysaux01.dbf'
ORA-01122: database file 2 failed verification check
ORA-01110: data file 2: '/var/hpsrp/drforp03/oradata/u04/SAPDS/DRFSAPDS/sysaux01.dbf'
ORA-01206: file is not part of this database - wrong database id
MRP0: Background Media Recovery process shutdown (SAPDS)
Completed: alter database recover managed standby database disconnect from session
My question therefore is how can I get out of this and get my logs to apply on standby?

Hello again;
Do you think if I tried to repeat the duplicate?
Yes I think you should do this.
Give me a few minutes and I will review my Word document and provide a step by step overview here as insurance.
I always cleanup the standby before trying another dup
OVERVIEW
Step 1 - Password file fro standby - Copy from primary and rename
Step 2 - Directory Structure on the remote server - Make sure noting is missing
Step 3 - Oracle Net Setup - entry for the CLONE in your TNSNAMES.ORA on both servers
Step 4 - SID_LIST_LISTENER addition ( assumes listener named LISTENER )
Step 5 - Timeouts set in listener.ora and sqlnet.ora Both Servers
Step 6 - Initialization Parameter File for the Auxiliary Instance
Step 7 - Set SID for Auxiliary Instance
Step 8 - Create an SPFILE for the new database by using a pfile with the INIT settings
Step 9 - Shutdown and startup nomount on new Spfile ( Auxiliary Instance )
Step 10 - Start RMAN and run the DUPLICATE Command
SID_LIST_LISTENER Example from mine
SID_LIST_LISTENER =
   (SID_LIST =
       (SID_DESC =
       (SID_NAME = PLSExtProc)
       (ORACLE_HOME = /u01/app/oracle/product/11.2.0.2)
       (PROGRAM = extproc)
       (SID_DESC =
       (global_dbname = CLONE.hostname)
       (ORACLE_HOME = /u01/app/oracle/product/11.2.0.2)
       (sid_name = CLONE)
Prevent Timeouts
Add these to both servers
To listener.ora
INBOUND_CONNECT_TIMEOUT_ = 120
To sqlnet.ora
SQLNET.INBOUND_CONNECT_TIMEOUT = 120
Then stop and start the listener.
RMAN
$ORACLE_HOME/bin/rman target=sys/@primary auxiliary=sys/@standby
Connect should return something like this
connected to target database: RECOVER9 (DBID=3806912436)
connected to auxiliary database: CLONE (not mounted)RMAN>duplicate target database for standby from active database NOFILENAMECHECK;
INIT Extras
To avoid ORA-09925 make sure the PFILE has audit_file_dest and core_dump_dest set
Best Regards
mseberg
Edited by: mseberg on Jun 29, 2012 11:12 AM

Managed folder policy will not apply to entire database

Exch2007 sp3
I have run several versions of this pshell command trying to set a MRM policy for a specific Exch2007 database, but the policy is not getting applied…..the mailboxes don’t show the policy
Get-Mailbox -domaincontroller DC.domain.com | Where{$_.Database -eq "mail\sg1\private information store"} | Set-Mailbox -ManagedFolderMailboxPolicy "90day"
When I run this version, it returns info about a corrupted mailbox.
If this mailbox is what is stopping the cmd from completing, is there a parameter to skip bad mailboxes?
Thanks!

Hi,
What's the error/warning of that corrupted mailbox? Since it’s a corrupted mailbox, I suggest to disable this mailbox then run command to apply managed folder mailbox policy.
In addition, just set the policy on DB isn’t enough to see the effects in user’s Outlook. To do this we need to schedule the managed folder assistant to run on a mailbox server
For EMC:
“Server Configuration”->”Mailbox”->locate related mailbox role and right-click it->choose “Properties”
In the “Messaging Records Management” tab->set the running schedule
For EMS:
Start-ManagedFolderAssistant
https://technet.microsoft.com/en-us/library/bb691428%28EXCHG.80%29.aspx?f=255&MSPPError=-2147217396
Document for reference
Managing Messaging Records Management
https://technet.microsoft.com/en-us/library/bb123507(EXCHG.80).aspx
Best Regards.
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]
Lynn-Li
TechNet Community Support

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

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;
}

I have one problem with Data Guard. My archive log files are not applied.

I have one problem with Data Guard. My archive log files are not applied. However I have received all archive log files to my physical Standby db
I have created a Physical Standby database on Oracle 10gR2 (Windows XP professional). Primary database is on another computer.
In Enterprise Manager on Primary database it looks ok. I get the following message Data Guard status Normal
But as I wrote above the archive log files are not applied
After I created the Physical Standby database, I have also done:
1. I connected to the Physical Standby database instance.
CONNECT SYS/SYS@luda AS SYSDBA
2. I started the Oracle instance at the Physical Standby database without mounting the database.
STARTUP NOMOUNT PFILE=C:\oracle\product\10.2.0\db_1\database\initluda.ora
3. I mounted the Physical Standby database:
ALTER DATABASE MOUNT STANDBY DATABASE
4. I started redo apply on Physical Standby database
alter database recover managed standby database disconnect from session
5. I switched the log files on Physical Standby database
alter system switch logfile
6. I verified the redo data was received and archived on Physical Standby database
select sequence#, first_time, next_time from v$archived_log order by sequence#
SEQUENCE# FIRST_TIME NEXT_TIME
3 2006-06-27 2006-06-27
4 2006-06-27 2006-06-27
5 2006-06-27 2006-06-27
6 2006-06-27 2006-06-27
7 2006-06-27 2006-06-27
8 2006-06-27 2006-06-27
7. I verified the archived redo log files were applied on Physical Standby database
select sequence#,applied from v$archived_log;
SEQUENCE# APP
4 NO
3 NO
5 NO
6 NO
7 NO
8 NO
8. on Physical Standby database
select * from v$archive_gap;
No rows
9. on Physical Standby database
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
ARCa: Archival started
ARCb: Archival started
ARCc: Archival started
ARCd: Archival started
ARCe: Archival started
ARCf: Archival started
ARCg: Archival started
ARCh: Archival started
ARCi: Archival started
ARCj: Archival started
ARCk: Archival started
ARCl: Archival started
ARCm: Archival started
ARCn: Archival started
ARCo: Archival started
ARCp: Archival started
ARCq: Archival started
ARCr: Archival started
ARCs: Archival started
ARCt: Archival started
ARC0: Becoming the 'no FAL' ARCH
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
MRP0: Background Media Recovery terminated with error 1110
MRP0: Background Media Recovery process shutdown
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 2148
RFS[1]: Identified database type as 'physical standby'
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 2384
RFS[2]: Identified database type as 'physical standby'
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 3188
RFS[3]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: No standby redo logfiles created
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[4]: Assigned to RFS process 3168
RFS[4]: Identified database type as 'physical standby'
RFS[4]: No standby redo logfiles created
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: No standby redo logfiles created
10. on Physical Standby database
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
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
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
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 1 9 13664 2
RFS IDLE 0 0 0 0
10) on Primary database:
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
ARCa: Archival started
ARCb: Archival started
ARCc: Archival started
ARCd: Archival started
ARCe: Archival started
ARCf: Archival started
ARCg: Archival started
ARCh: Archival started
ARCi: Archival started
ARCj: Archival started
ARCk: Archival started
ARCl: Archival started
ARCm: Archival started
ARCn: Archival started
ARCo: Archival started
ARCp: Archival started
ARCq: Archival started
ARCr: Archival started
ARCs: Archival started
ARCt: Archival started
ARCm: Becoming the 'no FAL' ARCH
ARCm: Becoming the 'no SRL' ARCH
ARCd: Becoming the heartbeat ARCH
Error 1034 received logging on to the standby
Error 1034 received logging on to the standby
LGWR: Error 1034 creating archivelog file 'luda'
LNS: Failed to archive log 3 thread 1 sequence 7 (1034)
FAL[server, ARCh]: Error 1034 creating remote archivelog file 'luda'
11)on primary db
select name,sequence#,applied from v$archived_log;
NAME SEQUENCE# APP
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00003_0594204176.001 3 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00004_0594204176.001 4 NO
Luda 4 NO
Luda 3 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00005_0594204176.001 5 NO
Luda 5 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00006_0594204176.001 6 NO
Luda 6 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00007_0594204176.001 7 NO
Luda 7 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00008_0594204176.001 8 NO
Luda 8 NO
12) on standby db
select name,sequence#,applied from v$archived_log;
NAME SEQUENCE# APP
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00004_0594204176.001 4 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00003_0594204176.001 3 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00005_0594204176.001 5 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00006_0594204176.001 6 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00007_0594204176.001 7 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00008_0594204176.001 8 NO
13) my init.ora files
On standby db
irina.__db_cache_size=79691776
irina.__java_pool_size=4194304
irina.__large_pool_size=4194304
irina.__shared_pool_size=75497472
irina.__streams_pool_size=0
*.audit_file_dest='C:\oracle\product\10.2.0\admin\luda\adump'
*.background_dump_dest='C:\oracle\product\10.2.0\admin\luda\bdump'
*.compatible='10.2.0.1.0'
*.control_files='C:\oracle\product\10.2.0\oradata\luda\luda.ctl'
*.core_dump_dest='C:\oracle\product\10.2.0\admin\luda\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_file_name_convert='luda','irina'
*.db_name='irina'
*.db_unique_name='luda'
*.db_recovery_file_dest='C:\oracle\product\10.2.0\flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP) (SERVICE=irinaXDB)'
*.fal_client='luda'
*.fal_server='irina'
*.job_queue_processes=10
*.log_archive_config='DG_CONFIG=(irina,luda)'
*.log_archive_dest_1='LOCATION=C:/oracle/product/10.2.0/oradata/luda/ VALID_FOR=(ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=luda'
*.log_archive_dest_2='SERVICE=irina LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=irina'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_max_processes=30
*.log_file_name_convert='C:/oracle/product/10.2.0/oradata/irina/','C:/oracle/product/10.2.0/oradata/luda/'
*.open_cursors=300
*.pga_aggregate_target=16777216
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=167772160
*.standby_file_management='AUTO'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='C:\oracle\product\10.2.0\admin\luda\udump'
On primary db
irina.__db_cache_size=79691776
irina.__java_pool_size=4194304
irina.__large_pool_size=4194304
irina.__shared_pool_size=75497472
irina.__streams_pool_size=0
*.audit_file_dest='C:\oracle\product\10.2.0/admin/irina/adump'
*.background_dump_dest='C:\oracle\product\10.2.0/admin/irina/bdump'
*.compatible='10.2.0.1.0'
*.control_files='C:\oracle\product\10.2.0\oradata\irina\control01.ctl','C:\oracle\product\10.2.0\oradata\irina\control02.ctl','C:\oracle\product\10.2.0\oradata\irina\control03.ctl'
*.core_dump_dest='C:\oracle\product\10.2.0/admin/irina/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_file_name_convert='luda','irina'
*.db_name='irina'
*.db_recovery_file_dest='C:\oracle\product\10.2.0/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP) (SERVICE=irinaXDB)'
*.fal_client='irina'
*.fal_server='luda'
*.job_queue_processes=10
*.log_archive_config='DG_CONFIG=(irina,luda)'
*.log_archive_dest_1='LOCATION=C:/oracle/product/10.2.0/oradata/irina/ VALID_FOR=(ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=irina'
*.log_archive_dest_2='SERVICE=luda LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=luda'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_max_processes=30
*.log_file_name_convert='C:/oracle/product/10.2.0/oradata/luda/','C:/oracle/product/10.2.0/oradata/irina/'
*.open_cursors=300
*.pga_aggregate_target=16777216
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=167772160
*.standby_file_management='AUTO'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='C:\oracle\product\10.2.0/admin/irina/udump'
Please help me!!!!

Hi,
After several tries my redo logs are applied now. I think in my case it had to do with the tnsnames.ora. At this moment I have both database in both tnsnames.ora files using the SID and not the SERVICE_NAME.
Now I want to use DGMGRL. Adding a configuration and a stand-by database is working fine, but when I try to enable the configuration DGMGRL gives no feedback and it looks like it is hanging. The log, although says that it succeeded.
In another session 'show configuration' results in the following, confirming that the enable succeeded.
DGMGRL> show configuration
Configuration
Name: avhtest
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
avhtest - Primary database
avhtestls53 - Physical standby database
Current status for "avhtest":
Warning: ORA-16610: command 'ENABLE CONFIGURATION' in progress
It there anybody that experienced the same problem and/or knows the solution to this?
With kind regards,
Martin Schaap

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:

Data Guard. My archive log files are not applied.

I have one problem with Data Guard. My archive log files are not applied. However I have received all archive log files to my physical Standby db
I have created a Physical Standby database on Oracle 10gR2 (Windows XP professional). Primary database is on another computer.
In Enterprise Manager on Primary database it looks ok. I get the following message Data Guard status Normal
But as I wrote above the archive log files are not applied
After I created the Physical Standby database, I have also done:
1. I connected to the Physical Standby database instance.
CONNECT SYS/SYS@luda AS SYSDBA
2. I started the Oracle instance at the Physical Standby database without mounting the database.
STARTUP NOMOUNT PFILE=C:\oracle\product\10.2.0\db_1\database\initluda.ora
3. I mounted the Physical Standby database:
ALTER DATABASE MOUNT STANDBY DATABASE
4. I started redo apply on Physical Standby database
alter database recover managed standby database disconnect from session
5. I switched the log files on Physical Standby database
alter system switch logfile
6. I verified the redo data was received and archived on Physical Standby database
select sequence#, first_time, next_time from v$archived_log order by sequence#
SEQUENCE# FIRST_TIME NEXT_TIME
3 2006-06-27 2006-06-27
4 2006-06-27 2006-06-27
5 2006-06-27 2006-06-27
6 2006-06-27 2006-06-27
7 2006-06-27 2006-06-27
8 2006-06-27 2006-06-27
7. I verified the archived redo log files were applied on Physical Standby database
select sequence#,applied from v$archived_log;
SEQUENCE# APP
4 NO
3 NO
5 NO
6 NO
7 NO
8 NO
8. on Physical Standby database
select * from v$archive_gap;
No rows
9. on Physical Standby database
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
ARCa: Archival started
ARCb: Archival started
ARCc: Archival started
ARCd: Archival started
ARCe: Archival started
ARCf: Archival started
ARCg: Archival started
ARCh: Archival started
ARCi: Archival started
ARCj: Archival started
ARCk: Archival started
ARCl: Archival started
ARCm: Archival started
ARCn: Archival started
ARCo: Archival started
ARCp: Archival started
ARCq: Archival started
ARCr: Archival started
ARCs: Archival started
ARCt: Archival started
ARC0: Becoming the 'no FAL' ARCH
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
MRP0: Background Media Recovery terminated with error 1110
MRP0: Background Media Recovery process shutdown
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 2148
RFS[1]: Identified database type as 'physical standby'
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 2384
RFS[2]: Identified database type as 'physical standby'
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 3188
RFS[3]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: No standby redo logfiles created
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[4]: Assigned to RFS process 3168
RFS[4]: Identified database type as 'physical standby'
RFS[4]: No standby redo logfiles created
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: No standby redo logfiles created
10. on Physical Standby database
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
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
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
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 1 9 13664 2
RFS IDLE 0 0 0 0
10) on Primary database:
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
ARCa: Archival started
ARCb: Archival started
ARCc: Archival started
ARCd: Archival started
ARCe: Archival started
ARCf: Archival started
ARCg: Archival started
ARCh: Archival started
ARCi: Archival started
ARCj: Archival started
ARCk: Archival started
ARCl: Archival started
ARCm: Archival started
ARCn: Archival started
ARCo: Archival started
ARCp: Archival started
ARCq: Archival started
ARCr: Archival started
ARCs: Archival started
ARCt: Archival started
ARCm: Becoming the 'no FAL' ARCH
ARCm: Becoming the 'no SRL' ARCH
ARCd: Becoming the heartbeat ARCH
Error 1034 received logging on to the standby
Error 1034 received logging on to the standby
LGWR: Error 1034 creating archivelog file 'luda'
LNS: Failed to archive log 3 thread 1 sequence 7 (1034)
FAL[server, ARCh]: Error 1034 creating remote archivelog file 'luda'
11)on primary db
select name,sequence#,applied from v$archived_log;
NAME SEQUENCE# APP
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00003_0594204176.001 3 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00004_0594204176.001 4 NO
Luda 4 NO
Luda 3 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00005_0594204176.001 5 NO
Luda 5 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00006_0594204176.001 6 NO
Luda 6 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00007_0594204176.001 7 NO
Luda 7 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00008_0594204176.001 8 NO
Luda 8 NO
12) on standby db
select name,sequence#,applied from v$archived_log;
NAME SEQUENCE# APP
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00004_0594204176.001 4 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00003_0594204176.001 3 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00005_0594204176.001 5 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00006_0594204176.001 6 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00007_0594204176.001 7 NO
C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00008_0594204176.001 8 NO
13) my init.ora files
On standby db
irina.__db_cache_size=79691776
irina.__java_pool_size=4194304
irina.__large_pool_size=4194304
irina.__shared_pool_size=75497472
irina.__streams_pool_size=0
*.audit_file_dest='C:\oracle\product\10.2.0\admin\luda\adump'
*.background_dump_dest='C:\oracle\product\10.2.0\admin\luda\bdump'
*.compatible='10.2.0.1.0'
*.control_files='C:\oracle\product\10.2.0\oradata\luda\luda.ctl'
*.core_dump_dest='C:\oracle\product\10.2.0\admin\luda\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_file_name_convert='luda','irina'
*.db_name='irina'
*.db_unique_name='luda'
*.db_recovery_file_dest='C:\oracle\product\10.2.0\flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP) (SERVICE=irinaXDB)'
*.fal_client='luda'
*.fal_server='irina'
*.job_queue_processes=10
*.log_archive_config='DG_CONFIG=(irina,luda)'
*.log_archive_dest_1='LOCATION=C:/oracle/product/10.2.0/oradata/luda/ VALID_FOR=(ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=luda'
*.log_archive_dest_2='SERVICE=irina LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=irina'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_max_processes=30
*.log_file_name_convert='C:/oracle/product/10.2.0/oradata/irina/','C:/oracle/product/10.2.0/oradata/luda/'
*.open_cursors=300
*.pga_aggregate_target=16777216
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=167772160
*.standby_file_management='AUTO'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='C:\oracle\product\10.2.0\admin\luda\udump'
On primary db
irina.__db_cache_size=79691776
irina.__java_pool_size=4194304
irina.__large_pool_size=4194304
irina.__shared_pool_size=75497472
irina.__streams_pool_size=0
*.audit_file_dest='C:\oracle\product\10.2.0/admin/irina/adump'
*.background_dump_dest='C:\oracle\product\10.2.0/admin/irina/bdump'
*.compatible='10.2.0.1.0'
*.control_files='C:\oracle\product\10.2.0\oradata\irina\control01.ctl','C:\oracle\product\10.2.0\oradata\irina\control02.ctl','C:\oracle\product\10.2.0\oradata\irina\control03.ctl'
*.core_dump_dest='C:\oracle\product\10.2.0/admin/irina/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_file_name_convert='luda','irina'
*.db_name='irina'
*.db_recovery_file_dest='C:\oracle\product\10.2.0/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.dispatchers='(PROTOCOL=TCP) (SERVICE=irinaXDB)'
*.fal_client='irina'
*.fal_server='luda'
*.job_queue_processes=10
*.log_archive_config='DG_CONFIG=(irina,luda)'
*.log_archive_dest_1='LOCATION=C:/oracle/product/10.2.0/oradata/irina/ VALID_FOR=(ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=irina'
*.log_archive_dest_2='SERVICE=luda LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=luda'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_max_processes=30
*.log_file_name_convert='C:/oracle/product/10.2.0/oradata/luda/','C:/oracle/product/10.2.0/oradata/irina/'
*.open_cursors=300
*.pga_aggregate_target=16777216
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=167772160
*.standby_file_management='AUTO'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='C:\oracle\product\10.2.0/admin/irina/udump'
Please help me!!!!

Hi,
After several tries my redo logs are applied now. I think in my case it had to do with the tnsnames.ora. At this moment I have both database in both tnsnames.ora files using the SID and not the SERVICE_NAME.
Now I want to use DGMGRL. Adding a configuration and a stand-by database is working fine, but when I try to enable the configuration DGMGRL gives no feedback and it looks like it is hanging. The log, although says that it succeeded.
In another session 'show configuration' results in the following, confirming that the enable succeeded.
DGMGRL> show configuration
Configuration
Name: avhtest
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
avhtest - Primary database
avhtestls53 - Physical standby database
Current status for "avhtest":
Warning: ORA-16610: command 'ENABLE CONFIGURATION' in progress
It there anybody that experienced the same problem and/or knows the solution to this?
With kind regards,
Martin Schaap

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 are being shipped, but are not applied

Hi everyone,
Some strange things are happening when I try to configure an Oracle Data Guard setup. Currently I am at the point where the configuration has been completed, and I just need to sync the standby database to the primary one. I can see in the log files that the archive logs are being shipped, but they are not applied on the standby system.
If I run "recover standby database;" manually in sqlplus I can see that it is trying to apply an archive log which is way too old (ORA-00279: change 9656498443 generated at 04/29/2008 08:45:08 needed for thread 1).
In the alert log I can also see this error: Warning: Recovery target destination is in a sibling branch of the controlfile checkpoint. Recovery will only recover changes to datafiles.
At this point I was thinking that the standby database might be on a different incarnation compared to the primary, but this is not the case, they are both in incarnation 6:
6 6 MVF 4023175798 CURRENT 48493546257 13-06-21
Does anyone have an idea how this could happen, and how I could fix this issue?
Thanks, JM.

The restore did not cause any errors to be displayed, so I assumed everything was ok.
That's fair enough.
One thing I think might cause this behaviour is that the backup on the primary database is incremental,
Yes...that may be an issue. Best bet is to re-run your standby creation.....as you are doing.
With version 11gR2 you also have the option of duplicate from active database which negates the need to copy your backupsets over to do the restore: I find it a much simpler process than the rman backup, copy files over, restore and then recover process.
http://www.oracle-base.com/articles/11g/data-guard-setup-11gr2.php
Something worth considering.

Redo data not applied on logical standby database 10g

after a network problem within the primary and the logical standby database. The redo data is not applied on the logical standby even if all the archived log are sent to it.
The below is the output from v$archive_gap and DBA_LOGSTDBY_LOG
SQL> select * from v$archive_gap;
no rows selected
SQL> SELECT SEQUENCE#, FIRST_TIME, APPLIED
FROM DBA_LOGSTDBY_LOG
ORDER BY SEQUENCE#; 2 3
SEQUENCE# FIRST_TIME APPLIED
3937 24-FEB-10 01:48:23 CURRENT
3938 24-FEB-10 10:31:22 NO
3939 24-FEB-10 10:31:29 NO
3940 24-FEB-10 10:31:31 NO
3941 24-FEB-10 10:33:44 NO
3942 24-FEB-10 11:54:17 NO
3943 24-FEB-10 12:05:30 NO
Any help?
Thanks

ORA-00600: internal error code, arguments: [krvxgirp], [], [], [], [], [], [], []
LOGSTDBY Analyzer process P003 pid=48 OS id=8659 stopped
Wed Feb 24 16:49:04 2010
Errors in file /oracle/product/10.2.0/admin/umarket/bdump/oradb_lsp0_8651.trc:
ORA-12801: error signaled in parallel query server P003
ORA-00600: internal error code, arguments: [krvxgirp], [], [], [], [], [], [], []
and below an Warning: Apply error received: ORA-26714: User error encountered while applying. Clearing. from oradb_lsp0_8651.trc
Thanks

Archive not applying on dr database

Similar Messages

Maybe you are looking for