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...

Similar Messages

Is there a way to apply archive logs, standby DB is opened with 'resetlogs'

Hi All,
I have setup a standby database (Oracle 10g SE). I applied hot backup and archive logs to the standby database till yesterday. I have opened the standby database using 'alter database open resetlogs;" and validated the application functionality using the standby database.
Now I want to regularly apply logs from the Primary database to the standby database, but today I have opened the standby database using 'alter database open resetlogs;"
Need assistance to know the way to apply archive logs, once the standby database is opened with 'resetlogs' option to keep it in sync with the Primary database.
Thanks
Kunal

Welcome to OTN,
I have setup a standby database (Oracle 10g SE). I applied hot backup and archive logs to the standby database till yesterday. I have opened the standby database using 'alter database open resetlogs;" and validated the application functionality using the standby database.Standby opened with *resetlogs* ? What you did? have you performed failover of standby database?
Now I want to regularly apply logs from the Primary database to the standby database, but today I have opened the standby database using 'alter database open resetlogs;"
Need assistance to know the way to apply archive logs, once the standby database is opened with 'resetlogs' option to keep it in sync with the Primary database.Have you enabled Flashback & created Restore point? If so you can do it.. If not rebuild standby again.
Check this scenario How To Open Physical Standby For Read Write Testing and Flashback [ID 805438.1]

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:

Could u tell me last applyed archive log in disaster recovery server

Hi DBA'S,
we are using oracle 9.2.0.8 my production database has dr(our dr is not a stand by it is created in diff way) server every time one cron job sync the database and transfer the new logs from production server to dr server. i want to know last applied archive in dr server.
i am using this query select max(sequence#) from v$log_history; it is showing same results in boath production and dr when ever we backup 2 days before archive to some backup directory sync is going to fail
please tell me correct query to find out the last applied archived log in dr server
Thanks&Regards
Tirupathi

we are using oracle 9.2.0.8 my production database has dr(our dr is not a stand by it is created in diff way) server every time one cron job sync the database and transfer the new logs from production server to dr server. i want to know last applied archive in dr server.i am using this query select max(sequence#) from v$log_history; it is showing same results in boath production and dr when ever we backup 2 days before archive to some backup directory sync is going to fail
please tell me correct query to find out the last applied archived log in dr server>
As you are running cron job to bring the dr in sync, i suppose v$log_history might give you the wrong results.In your case check :-
select sequence#,applied from v$archived_log where applied='YES';
select max(sequence#) from v$archived_log where applied='YES';Would like to know, why manual recovery (archive logs being manually applied) is being performed, and not automatic.
In case you switch to automatic below query would be useful :-
select al.thrd "Thread", almax "Last Seq Received", lhmax "Last Seq Applied"
    from (select thread# thrd, max(sequence#) almax
            from v$archived_log
           where resetlogs_change#=(select resetlogs_change# from v$database)
           group by thread#) al,
         (select thread# thrd, max(sequence#) lhmax
           from v$log_history
            where first_time=(select max(first_time) from v$log_history)
           group by thread#) lh
          where al.thrd = lh.thrd;Refer [http://aprakash.wordpress.com/2010/07/21/use-of-varchived_log-and-vlog_history-on-physical-standby/]
HTH
Anand

Delete only applied archive logs

Hi,
I am new to RMAN. What is the command to delete all applied archive logs using RMAN in 11g Release2 ?
Thx

Hi,
What is your os ?
If it s linux/unix then try this shell script.
#!/bin/bash
ALERT=/oracle/app/oracle/diag/rdbms/dgbrm/dgbrm/trace/alert_dgbrm.log
tail -30000 $ALERT | grep "Media Recovery Log" | cut -d " " -f 4 | head --lines=-2 > files.txt
awk '{ system( "rm -rf " $_ ) }' files.txt
source: http://emrebaransel.blogspot.in/2009/03/delete-applied-archivelogs-on-standby.html
Thanks,
Ranjith

Recover DB which don have backup and not in archive log mode

Hi
today one of our DB in oracle 10gR2 in AIX got crashed which is not in archive log and which does not have any backup. It was maintained by the Developers and they need it to be recovered. When trying to open it says message like getting error with system01.dbf needs to more recover. Can any body help me. Very Urgent... Is there any way to recover the db??
Thanks
Ram

Hello Mr.Sybrand Bakkar,
Thanks for your suggestion. Being a DBA i myself knows that without anything I wont be able to. I m just trying to get some suggestions whether is there any way to recover it or has some experts came across these situations and got some answers. When we are not able to think beyond our limit, we come to the forums and post question. I know that this is not the place to write where i can be rude, Hence please change ur perception. When i say urgent, it means that unfortunately they have messed up their DB and came to DB Team for assistance to get their data back which has to be given to their process partners and As a support team we are trying our best to recover it. Anyhow thanks for your reply and suggestion. Have a great day.
Thanks
Ram

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

Manually apply archived log to standby database.

Hi all,
I am working on oracle 10g EE(10.2.0.4).I am having a very difficult database switchover case in my hand.
1.> There are two database .one primary(prim) and another standby(standby).
2.> Initially both of them was configured as oracle data guard, where prim was primary and standby was standby using rman .(RMAN>duplicate target database for
standby dorecover).
3.>But the rate of generation of archivelog is very high( 20 archivelog per hour with 200mb each).
4.> So automatic shipping of archivelog has been disabled from primary.(log_archive_dest_state_2=defer and nullifying the value of log_archive_dest_2).
5> Now after a period of time archived logs are shipped to dr site manually and applied manually.(alter database recover automatic standby database;)
6.> Now there is a hardware problem occured at primary..it will take 72 hours to come up.
How can i use standby database as primary for that 72 hour.As archive log apply is manually done and parameters are being changed,can i switch over these two?
Is it possible to switchover and switch back these two database with such a configuration?

How can i use standby database as primary for that 72 hour.As archive log apply is manually done and parameters are being changed,can i switch over these two?
Is it possible to switchover and switch back these two database with such a configuration?
As of now you can perform failover your standby to primary database. you should have flashaback enabled, so you have to create a restore point.
Then it can be opened in read & write mode, So once you finished again you can go back to that point.
http://docs.oracle.com/cd/B19306_01/server.102/b14239/manage_ps.htm#i1017111
The above case applicable if you ready to loose, But it doesnt make sense. But in your case this doesnt work. Because once you start use of Standby as primary, there would be live/production data, which you need very much.
So there is lot of work to do.
You have to rebuild standby database and then switchover back to same location. So its a little trip work.
Have you enabled Dataguard Broker ?
Edited by: CKPT on Mar 13, 2012 1:43 PM

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

Log is not applied, subsequent log applied are "yes"

Hi all,
I am building a new standby.
It is brand new, and I have turned on the managed recovery for the first time after restoring my database.
--> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Why does the first line show "NO" for applied log? (and all the logs after it shows "YES"?)
Is there something wrong, or can I ignore this as it is normal?
SQL> SELECT sequence#, first_time, next_time, applied
FROM v$archived_log
ORDER BY sequence#; 2 3
SEQUENCE# FIRST_TIME NEXT_TIME APP
2653893 30-OCT-2012 23:03:21 30-OCT-2012 23:03:25 NO
2653894 30-OCT-2012 23:03:25 30-OCT-2012 23:23:04 YES
2653895 30-OCT-2012 23:23:04 30-OCT-2012 23:23:28 YES
2653896 30-OCT-2012 23:23:28 30-OCT-2012 23:26:32 YES
2653897 30-OCT-2012 23:26:32 30-OCT-2012 23:26:49 YES
2653898 30-OCT-2012 23:26:49 30-OCT-2012 23:31:05 YES
2653899 30-OCT-2012 23:31:05 31-OCT-2012 00:00:41 YES
2653900 31-OCT-2012 00:00:41 31-OCT-2012 00:31:04 YES
2653901 31-OCT-2012 00:31:04 31-OCT-2012 01:01:03 YES
2653902 31-OCT-2012 01:01:03 31-OCT-2012 01:31:17 YES
Edited by: user8875620 on Nov 8, 2012 11:20 PM

user8875620 wrote:
Hi all,
I am building a new standby.
It is brand new, and I have turned on the managed recovery for the first time after restoring my database.
--> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Why does the first line show "NO" for applied log? (and all the logs after it shows "YES"?)
Is there something wrong, or can I ignore this as it is normal?
SQL> SELECT sequence#, first_time, next_time, applied
FROM v$archived_log
ORDER BY sequence#; 2 3
SEQUENCE# FIRST_TIME NEXT_TIME APP
2653893 30-OCT-2012 23:03:21 30-OCT-2012 23:03:25 NO
2653894 30-OCT-2012 23:03:25 30-OCT-2012 23:23:04 YES
2653895 30-OCT-2012 23:23:04 30-OCT-2012 23:23:28 YES
2653896 30-OCT-2012 23:23:28 30-OCT-2012 23:26:32 YES
2653897 30-OCT-2012 23:26:32 30-OCT-2012 23:26:49 YES
2653898 30-OCT-2012 23:26:49 30-OCT-2012 23:31:05 YES
2653899 30-OCT-2012 23:31:05 31-OCT-2012 00:00:41 YES
2653900 31-OCT-2012 00:00:41 31-OCT-2012 00:31:04 YES
2653901 31-OCT-2012 00:31:04 31-OCT-2012 01:01:03 YES
2653902 31-OCT-2012 01:01:03 31-OCT-2012 01:31:17 YES
Edited by: user8875620 on Nov 8, 2012 11:20 PMWhat is the version you are using?
Are you using Data Guard broker?
Assuming you are not using Real-time apply.
Basically there are so many bugs with the views specific to Data Guard they are v$archived_gap, v$archived_log depending on the environments.
One of note for this bug.
'APPLIED'-Column not updated if Heartbeat-ARCH hangs [ID 1369630.1]
v$archived_log: applied column is not marked if recovery applied the redo from SRL [ID 1481927.1]
Thanks

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

Primary/standby and 3rd archive log destination?

Running Oracle EE 10.2.0.4 linux 64 bit. I have a primary and standby configuration using data guard, with appropriate LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2 for the primary and standby - all works as expected. I want to multiplex the log files by adding a 3rd archive log destination to a different disk. I'm not clear on whether or not specifying a second 'primary' archive destination will write to both dest_1 and dest_3 or just alternate between the 2? I want to make sure that both DEST_1 and DEST_3 are written to (there can be a lag for DEST_3) -
Is the following all I need or are there additional parameters to LOG_ARCHIVE_DEST_n I'm missing?
LOG_ARCHIVE_DEST_3 = 'valid_for=(ONLINE_LOGFILE,ALL_ROLES)', 'location="/myThirdLoc"'
Thanks -

The database hang because of the redo log file is full. my test database is 16.7G and I gave the recovery filesystem 19 G for the redo log. Apparently it is not enough. After i set up the backup with daily incremental and run for 5 days, the recovery is full and db hang. How do you free up the space or set up the backup so that it can recycle the space? My DB is 10g r2 on RHEL3.

RMAN: How to apply Archive Logs after recoverying of all physical files

Hi;
I am using RMAN Oracle10g; my test database has being corrupted. I have already taken 0 level backup through this command
run {
allocate channel c1 type disk;
backup incremental level 0 tag = Test_Weekly_database format 'O:\rman\backup\Full_Weekly_%d_%s_%p_%t'(database);
release channel c1;
configure controlfile autobackup format for device type disk to 'O:\rman\backup\Auto_Ctrl_weekly_%F';
allocate channel c1 type disk;
sql 'alter system archive log current';
BACKUP tag = Test_Weekly_Arch ARCHIVELOG UNTIL TIME 'SYSDATE-7' format 'O:\rman\backup\Archive_weekly_%d_%s_%p_%t';
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';
release channel c1;
After backing up I inserted few records in TEST123 table. And switch current log file.
Then my database has been corrupted. Now I have last 0 level backup (RMAN) and archive logs files on OS level.
I am recovering my database with the following commands; but archive logs have not being applied. And my inserted records were not presented in TEST123 table.
Kindly guide me
SQL> startup nomount
CMD> RMAN target=/
RMAN>set DBID 1168995671
RMAN>RUN {
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'O:\rman\backup\Auto_Ctrl_weekly_%F';
RESTORE CONTROLFILE from autobackup;
RMAN> ALTER DATABASE MOUNT;
RMAN> RESTORE DATABASE CHECK READONLY;
RMAN> RECOVER DATABASE NOREDO;
RMAN> restore archivelog all;
SQL> startup mount
SQL> alter database backup controlfile to trace;
SQL> shut immediate
SQL> startup nomount
SQL> CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS ARCHIVELOG................;
SQL> alter database open resetlogs
---Database altered.
SQL> select * from TEST123;
Not record found
regards;
Asim

Dear Khurram;
Kindly advise where i m worrg???????
C:\>RMAN target=/
RMAN> set DBID 1168995671
executing command: SET DBID
RMAN> RUN {
2> SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'O:\rman\backup\Auto_Ctrl_weekly_%F';
3> RESTORE CONTROLFILE from autobackup;
4> }
executing command: SET CONTROLFILE AUTOBACKUP FORMAT
Starting restore at 27-DEC-07
using channel ORA_DISK_1
recovery area destination: O:\rman\backup
database name (or database unique name) used for search: ORCL
channel ORA_DISK_1: no autobackups found in the recovery area
channel ORA_DISK_1: looking for autobackup on day: 20071227
channel ORA_DISK_1: autobackup found: O:\rman\backup\Auto_Ctrl_weekly_c-11689956
71-20071227-04
channel ORA_DISK_1: control file restore from autobackup complete
output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL01.CTL
output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL02.CTL
output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL03.CTL
Finished restore at 27-DEC-07
RMAN> ALTER DATABASE MOUNT;
database mounted
released channel: ORA_DISK_1
RMAN> RESTORE DATABASE CHECK READONLY;
Starting restore at 27-DEC-07
Starting implicit crosscheck backup at 27-DEC-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=154 devtype=DISK
Crosschecked 9 objects
Finished implicit crosscheck backup at 27-DEC-07
Starting implicit crosscheck copy at 27-DEC-07
using channel ORA_DISK_1
using channel ORA_DISK_2
Finished implicit crosscheck copy at 27-DEC-07
searching for all files in the recovery area
cataloging files...
no files cataloged
using channel ORA_DISK_1
using channel ORA_DISK_2
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
restoring datafile 00002 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
restoring datafile 00003 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
restoring datafile 00004 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
restoring datafile 00005 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST.DBF
restoring datafile 00006 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST2
channel ORA_DISK_1: reading from backup piece O:\RMAN\BACKUP\FULL_WEEKLY_ORCL_3_
1_642420573
channel ORA_DISK_1: restored backup piece 1
piece handle=O:\RMAN\BACKUP\FULL_WEEKLY_ORCL_3_1_642420573 tag=Test_WEEKLY_DATAB
ASE
channel ORA_DISK_1: restore complete, elapsed time: 00:00:46
Finished restore at 27-DEC-07
RMAN> restore archivelog all;
archive log thread 1 sequence 1 is already on disk as file O:\ARCHIVE\ARC00001_0642356125.001
archive log thread 1 sequence 2 is already on disk as file O:\ARCHIVE\ARC00002_0642356125.001
archive log thread 1 sequence 3 is already on disk as file O:\ARCHIVE\ARC00003_0642356125.001
archive log thread 1 sequence 4 is already on disk as file O:\ARCHIVE\ARC00004_0642356125.001
archive log thread 1 sequence 5 is already on disk as file O:\ARCHIVE\ARC00005_0642356125.001
archive log thread 1 sequence 6 is already on disk as file O:\ARCHIVE\ARC00006_0642356125.001
archive log thread 1 sequence 7 is already on disk as file O:\ARCHIVE\ARC00007_0642356125.001
archive log thread 1 sequence 8 is already on disk as file O:\ARCHIVE\ARC00008_0642356125.001
archive log thread 1 sequence 9 is already on disk as file O:\ARCHIVE\ARC00009_0642356125.001
archive log thread 1 sequence 10 is already on disk as file O:\ARCHIVE\ARC00010_0642356125.001
archive log thread 1 sequence 11 is already on disk as file O:\ARCHIVE\ARC00011_0642356125.001
archive log thread 1 sequence 12 is already on disk as file O:\ARCHIVE\ARC00012_0642356125.001
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=15
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=16
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=17
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=18
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=19
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=20
channel ORA_DISK_1: reading from backup piece O:\RMAN\BACKUP\ARCHIVE_WEEKLY_ORCL_5_1_642420630
channel ORA_DISK_1: restored backup piece 1
piece handle=O:\RMAN\BACKUP\ARCHIVE_WEEKLY_ORCL_5_1_642420630 tag=Test_WEEKLY_ARCH
channel ORA_DISK_1: restore complete, elapsed time: 00:00:08
Finished restore at 27-DEC-07
RMAN> ALTER DATABASE OPEN;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 12/27/2007 10:27:10
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF'
Regards;
Asim

Applied archived log

Hi,
on 11g R2 dataguard,
on Primary I have :
SQL> select MAX(SEQUENCE#), THREAD# from gv$log where status='CURRENT'
group by THREAD#
order by THREAD# asc;
2    3
MAX(SEQUENCE#)    THREAD#
        700602          1
        259893          2
        261564          3
        259332          4On standby :
SQL> select MAX(SEQUENCE#), THREAD# from gv$log where status='CURRENT'
group by THREAD#
order by THREAD# asc;
2    3
MAX(SEQUENCE#)    THREAD#
        700602          1
        259893          2
        261564          3
        259331          4Then very small gap (only one sequence of thread 4.
But whith the following query on standby :
select THREAD#,SEQUENCE#,to_char(completion_time,'DD-MM-YYYY HH24:MI:SS' ),applied from v$archived_log where to_char(completion_time,'DD-MM-YYYY HH24:MI:SS' ) like '%14-08-2012%'and applied='NO' and THREAD#=4;
   THREAD# SEQUENCE# TO_CHAR(COMPLETION_ APPLIED
         4     259325 14-08-2012 15:14:57 NO
         4     259327 14-08-2012 15:15:12 NO
         4     259326 14-08-2012 15:15:19 NO
         4     259328 14-08-2012 15:17:56 NO
         4     259329 14-08-2012 15:18:01 NO
         4     259330 14-08-2012 15:20:36 NO
         4     259331 14-08-2012 15:20:56 NO
260 rows selected.Can any one be kind to tell me why 260 rows from this query as not applied ?
Thank you.

thank you.
here they are :
SQL> select * from v$archive_gap;
no rows selected
SQL> select THREAD#,SEQUENCE#,to_char(completion_time,'DD-MM-YYYY HH24:MI:SS' ),applied from v$archived_log where to_char(completion_time,'DD-MM-YYYY HH24:MI:SS' ) lik        e '%16-08-2012%'and applied='NO';
   THREAD# SEQUENCE# TO_CHAR(COMPLETION_ APPLIED
         3     136579 16-08-2012 10:11:05 NO
         1     137179 16-08-2012 10:11:05 NO
         4     354265 16-08-2012 10:11:06 NO
select PROCESS, STATUS, GROUP#, THREAD#, SEQUENCE#, BLOCK#, BLOCKS, DELAY_MINS from
         v$managed_standby where PROCESS like 'MR%';
PROCESS   STATUS       GROUP#                                      THREAD# SEQUENCE#     BLOCK#     BLOCKS DELAY_MINS
MRP0      WAIT_FOR_LOG N/A                                               3     136580          0          0          0

New standby not applying archive log

Similar Messages

Maybe you are looking for