Issue with physical standby database not in sync with primary

Hi,
I created an physical standby database couple of Hours back . I am trying to keep the standby database in Managed recovery mode to make the standby in sync with primary but it is throwing the below erros. Please share your suggestion ...
SQL> select thread#,max(sequence#) from v$log_history group by thread#;
THREAD# MAX(SEQUENCE#)
1 7
PROCESS STATUS THREAD# SEQUENCE#
ARCH CONNECTED 0 0
ARCH CONNECTED 0 0
RFS OPENING 1 12
ALERT LOG :
Tue Mar 20 07:31:32 2012
alter database recover managed standby database disconnect from session
Tue Mar 20 07:31:32 2012
Attempt to start background Managed Standby Recovery process (PRIMARY)
MRP0 started with pid=18, OS id=16370
Tue Mar 20 07:31:32 2012
MRP0: Background Managed Standby Recovery process started (PRIMARY)
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 8 processes
Media Recovery Log /oracle/STDBY/arch/1_3_777567883.dbf
Tue Mar 20 07:31:39 2012
Completed: alter database recover managed standby database disconnect from session
Tue Mar 20 07:31:54 2012
Incomplete recovery applied all redo ever generated.
Recovery completed through change 9677325080303
Tue Mar 20 07:31:54 2012
MRP0: Media Recovery Complete (PRIMARY)
Tue Mar 20 07:31:55 2012
MRP0: Background Media Recovery process shutdown (PRIMARY)
Thanks,
Rakesh

HI CKPT,
Thanks for the reply. All the Archives from primary are transferred to the standby by RFS. Also i tried to register the log files manually even but it says already registered. They are no errors in the primary instance alert log file. Please find the log
SEVERITY ERROR_CODE MESSAGE TO_CHAR(TIMESTAMP,'D
Informational 0 ARC0: Archival started 20-MAR-2012 06:51:36
Informational 0 ARC1: Archival started 20-MAR-2012 06:51:36
Informational 0 ARC0: Becoming the 'no FAL' ARCH 20-MAR-2012 06:51:36
Informational 0 ARC0: Becoming the 'no SRL' ARCH 20-MAR-2012 06:51:36
Informational 0 ARC1: Becoming the heartbeat ARCH 20-MAR-2012 06:51:36
Informational 0 Redo Shipping Client Connected as PUBLIC 20-MAR-2012 06:52:07
Informational 0 -- Connected User is Valid 20-MAR-2012 06:52:07
Informational 0 RFS[1]: Assigned to RFS process 15934 20-MAR-2012 06:52:07
Informational 0 RFS[1]: Identified database type as 'physical standby' 20-MAR-2012 06:52:07
Warning 0 RFS[1]: No standby redo logfiles created 20-MAR-2012 06:52:07
Control 0 Attempt to start background Managed Standby Recovery process 20-MAR-2012 06:52:42
Control 0 MRP0: Background Managed Standby Recovery process started 20-MAR-2012 06:52:42
Informational 0 Managed Standby Recovery not using Real Time Apply 20-MAR-2012 06:52:47
Informational 0 Media Recovery Log /oracle/STDBY/arch/1_3_777567883.d 20-MAR-2012 06:52:49
bf
Control 0 MRP0: Media Recovery Complete 20-MAR-2012 06:53:04
Control 0 MRP0: Background Media Recovery process shutdown 20-MAR-2012 06:53:06
Informational 0 Managed Standby Recovery not using Real Time Apply 20-MAR-2012 06:53:24
Control 0 Media Recovery Complete 20-MAR-2012 06:53:43
Control 0 Attempt to start background Managed Standby Recovery process 20-MAR-2012 06:54:55
Control 0 MRP0: Background Managed Standby Recovery process started 20-MAR-2012 06:54:55
Informational 0 Managed Standby Recovery not using Real Time Apply 20-MAR-2012 06:55:00
Informational 0 Media Recovery Log /oracle/STDBY/arch/1_3_777567883.d 20-MAR-2012 06:55:01
bf
Control 0 MRP0: Media Recovery Complete 20-MAR-2012 06:55:17
Control 0 MRP0: Background Media Recovery process shutdown 20-MAR-2012 06:55:18
Informational 0 Redo Shipping Client Connected as PUBLIC 20-MAR-2012 07:31:03
Informational 0 -- Connected User is Valid 20-MAR-2012 07:31:03
Informational 0 RFS[2]: Assigned to RFS process 16366 20-MAR-2012 07:31:03
Informational 0 RFS[2]: Identified database type as 'physical standby' 20-MAR-2012 07:31:03
Warning 0 RFS[2]: No standby redo logfiles created 20-MAR-2012 07:31:04
Warning 0 RFS[2]: No standby redo logfiles created 20-MAR-2012 07:31:06
Control 0 Attempt to start background Managed Standby Recovery process 20-MAR-2012 07:31:32
Control 0 MRP0: Background Managed Standby Recovery process started 20-MAR-2012 07:31:32
Informational 0 Managed Standby Recovery not using Real Time Apply 20-MAR-2012 07:31:37
Informational 0 Media Recovery Log /oracle/STDBY/arch/1_3_777567883.d 20-MAR-2012 07:31:38
bf
Control 0 MRP0: Media Recovery Complete 20-MAR-2012 07:31:54
Control 0 MRP0: Background Media Recovery process shutdown 20-MAR-2012 07:31:55
36 rows selected.
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /oracle/STDBY/arch/
Oldest online log sequence 13
Next log sequence to archive 0
Current log sequence 14
SQL> ho ls -ltra /oracle/STDBY/arch/
total 3754456
drwxr-xr-x 4 oracle dba 4096 Feb 13 17:38 ..
-rw-r----- 1 oracle dba 908516864 Mar 20 06:37 1_8_777567883.dbf
-rw-r----- 1 oracle dba 770419200 Mar 20 06:40 1_3_777567883.dbf
-rw-r----- 1 oracle dba 757698048 Mar 20 06:41 1_4_777567883.dbf
-rw-r----- 1 oracle dba 5171712 Mar 20 06:41 1_5_777567883.dbf
-rw-r----- 1 oracle dba 1060801024 Mar 20 06:43 1_6_777567883.dbf
-rw-r----- 1 oracle dba 323025920 Mar 20 06:43 1_7_777567883.dbf
-rw-r----- 1 oracle dba 1558016 Mar 20 06:43 1_9_777567883.dbf
-rw-r----- 1 oracle dba 4608 Mar 20 06:43 1_10_777567883.dbf
-rw-r----- 1 oracle dba 1579008 Mar 20 06:52 1_11_777567883.dbf
-rw-r----- 1 oracle dba 11876864 Mar 20 07:31 1_12_777567883.dbf
-rw-r----- 1 oracle dba 2560 Mar 20 07:31 1_13_777567883.dbf
drwxr-xr-x 2 oracle dba 36864 Mar 20 07:31 .
SQL>

Similar Messages

Logical Standby Database Not Getting Sync With Primary Database

Hi All,
I am using a Primary DB and Logical Standby DB configuration in Oracle 10g:-
Version Name:-
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE 10.2.0.5.0 Production
TNS for Solaris: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
We have build the logical standby last week and till date the Logical DB is not sync. I have checked the init parameters and I wont see any problems with it. Also archive log destinations are also fine enough.
We have a important table named "HPD_HELPDESK" where record count is growing gradually whereas in logical standby it's not growing. There are some 19K record difference in the both the tables.
I have checked the alert log but it is also not giving any error message. Please find the last few lines of the alert log in logical Database:-
RFS LogMiner: Registered logfile [oradata_san1/oradata/remedy/arch/ars1_1703_790996778.arc] to LogMiner session id [1]
Tue Aug 28 14:56:52 GMT 2012
RFS[2853]: Successfully opened standby log 5: '/oracle_data/oradata/remedy/stbyredo01.log'
Tue Aug 28 14:56:58 GMT 2012
RFS LogMiner: Client enabled and ready for notification
Tue Aug 28 14:57:00 GMT 2012
RFS LogMiner: Registered logfile [oradata_san1/oradata/remedy/arch/ars1_1704_790996778.arc] to LogMiner session id [1]
Tue Aug 28 15:06:40 GMT 2012
RFS[2854]: Successfully opened standby log 5: '/oracle_data/oradata/remedy/stbyredo01.log'
Tue Aug 28 15:06:47 GMT 2012
RFS LogMiner: Client enabled and ready for notification
Tue Aug 28 15:06:49 GMT 2012
RFS LogMiner: Registered logfile [oradata_san1/oradata/remedy/arch/ars1_1705_790996778.arc] to LogMiner session id [1]
I am not able to trace the issue that why the records are not growing in logical DB. Please provide your inputs.
Regards,
Arijit

How do you know that there's such a gap between the tables?
If your standby db is a physical standby, then it is not open and you can't query your table without cancelling the recovery of the managed standby database.
What does it say if you execute this sql?
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;The ARCH processes should be connected and MRP waiting for a file.
If you query for the archive_gaps, do you get any hits?
select * from gv$archive_gapIf you're not working in a RAC environment you need to query v$archive_gap, instead!
Did you check whether the archives generated from the primary instance are transferred and present in the file system of your standby database?
I believe your standby is not in recovery_mode anymore or has an archive_gap, which is the reason why it doesn't catch up anymore.
Hope it helps a little,
Regards,
Sebastian
PS: I'm working on 11g, so unfortunately I'm not quite sure if the views are exist in 10gR2. It's worth a try though!
Edited by: skahlert on 31.08.2012 13:46

Manual Standby Database not in sync with missing archivelogs

Hello,
OS: Solaris
DB: Oracle 11.2.0.1 EE
Not Using ASM or RAC
I have a Production database that is in archivelog mode and a Standby DR server.
Both servers (Prod, Standby) have exact same structure and db name/version.
We manually scp archive logs and recover them to a manual standby database via SQL Scripts "cron". (I.E. set autorecovery on; recover standby database;)
We recently got out of sync with our log files and have not been applying them to the standby. As part of Prod Maintenance, these log files were deleted and are not available anymore.
I've tried several ways to "rebuild" our standby database. I have tried to Shutdown prod, backup all the db files and scp them to standby, re-create standby controlfile and startup mount and recover standby.
Every time I try to apply a new archive log via recover standby, these are the errors:
ORA-00279: change 211077622 generated at 1/27/2012 12:18:42 needed for thread 1
ORA-00289: suggestion : /oradump/arch/PROD/PROD_arch_1_69486_736618850.arc
ORA-00280: change 211077622 for thread 1 is in sequence #69486
ORA-00308: cannot open archived log '/oradump/arch/PROD/PROD_arch_1_69486_736618850.arc'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-10879: error signaled in parallel recovery slave
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/oradevices/PROD/oraPRODsystem1.dbf'
When I check v$log_history, the new logs have not been applied.
I've also tried the "Restore from incremental backup via SCN" method with same results.
Is there a way to re-create the standby clean and ensure that the log chain that is currently broken gets fixed or reset?
I would eventually like to get DataGuard in here, but that's not the case at the moment.
Thanks for your suggestions.
-Dav

if you are using the cold backup to create the standby database, Check that have you followed the following steps or not.
1. remove
all the datafiles and controlfiles from the standby database.
2. Create a new standby controlfile of the production for standby using the following cmd
'alter database create standby controlfile as 'Location';'
3. move the new controlfile to standby database server location as specified in initialization parameter file.
4. Restore all the datafiles to its appropriate loaction which was taken through cold backup.
5. startup nomount
6. alter database mount standby database;
7. recover standby database.
scp the archive log sequence that is asked by the database, from production.
You can try this steps.

Issue on physical standby database

Hi
I've a problem on standby database.
I recently added a datafile on primary database, then I scp'ed the data file to physical standby database.On physical standby database I tried performing recovery.
I get following message in my alert log
WARNING! Recovering data file 88 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
ORA-279 signalled during: ALTER DATABASE RECOVER standby database ...
how can I fix this now.
We keep physical standby database 2 day behind, and apply logs manually.
Physical standby database is maintained manually.
Could someone help me in getting out of this problem.
Oracle 9.2.0.7
solaris

Versus keeping it in manual mode, you can specify a time "delay" for the application of the logs:
From http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/log_apply.htm#i1022811
6.2.2 Specifying a Time Delay for the Application of Archived Redo Log Files
In some cases, you may want to create a time lag between the time when redo data is received from the primary site and when it is applied to the standby database. You can specify a time interval (in minutes) to protect against the application of corrupted or erroneous data to the standby database. When you set a DELAY interval, it does not delay the transport of the redo data to the standby database. Instead, the time lag you specify begins when the redo data is completely archived at the standby destination.
Note:
If you define a delay for a destination that has real-time apply enabled, the delay is ignored.
Specifying a Time Delay
You can set a time delay on primary and standby databases using the DELAY=minutes attribute of the LOG_ARCHIVE_DEST_n initialization parameter to delay applying archived redo log files to the standby database. By default, there is no time delay. If you specify the DELAY attribute without specifying a value, then the default delay interval is 30 minutes.
Canceling a Time Delay
You can cancel a specified delay interval as follows:
For physical standby databases, use the NODELAY keyword of the RECOVER MANAGED STANDBY DATABASE clause:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
For logical standby databases, specify the following SQL statement:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
These commands result in log apply services immediately beginning to apply archived redo log files to the standby database, before the time interval expires. Also, see:
Section 12.8, "Using a Physical Standby Database with a Time Lag"
Oracle Database SQL Reference for the DELAY attribute of the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement

Ora-38500 physical standby database not started

hiiii,
When i executed the command at physical standby database server.
it give error:
To start real-time apply:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> USING CURRENT LOGFILE;
Error at line 1:
ORA: 38500 using current logfile option not available without stand.
please help me how could i start physical standby database
Regards
Vaibhav Dixit

Hi Vaibhav,
What exactly do you want to do?
Alter database recover managed standby database; --->it will be in Manged Recovery mode.
Alter database mount standby database; ----> it will be mounted, but no log files applies.
Alter database open read only; ----> it will be open with read only option, but archeive logs will NOT be applied
If you want to apply the Archive logs which are trasfered from Primary, then you need to fire the below commands
Alter database recover managed standby database;
Alter database recover managed standby database using current logfile;
Alter database recover managed standby database using current logfile disconnect from session;
To stop applying archives then,
Alter database recover managed standby database cancel;
Thanks and Regards.
tnaresh1982

Creating physical standby database on same machine with dataguard

hi every one
i m new in oracle databases,
i read documentation to create physical standby databases,
now i install virtual machine (vmware) on my system,
i install windows xp on this vm and oracle 9i
now i want to create standby database on the same machine in some other drive configured with datagurd
virtual machine
OS windows xp
database oracle 9i
plz reply me how i do this
explain clearly step by step.
plz reply me in detail

When you need to have the standby database on the same server as the master, use lock_name_space in the init.ora.
This parameter permits this to occur without having to worry about changing the db_name.
http://www.oug-ottawa.org/pls/htmldb/f?p=103:21:729607614317189728::::P21_TIP_NUM:821

Physical Standby Database Lags Far Behind the Primary Database scenario

Hi,
Have anyone successfully implemented described in the Oracle Documentation following
scenario?
For me it does not work at all.
After implementing all steps current_scn of standby database remains the same and when trying to push recovery using redo it asks for non-existing archived log which I can't restore on primary database as all backups containing that archived log already gone.
The only option is to recreate standby database from backup again.
Best Regards,
Alex

I already found the reason.
Just for your information:
Recovering a Standby database from a missing archivelog
Unfortunately documentation missed that important step of standby controlfile recreation.
To my luck I was copying the whole backup to the standby server when found this link.

Goldengate replicate physical standby database

Friends,
I did not get a answer in data guard place
Could we use oracle golden gate to replicate a data guard physical standby database into a new logical database?
Or we must replicate data guard primary database into a new logical database?
Thanks
newdba

Thanks for your help. In the physical standby database, the log_mode shows archive log. per your statement, we can configure golden gate Extract parameter TRANLOGOPTIONS with the ARCHIVEDLOGONLY option to replicate physical standby database into new customer DB.
But I have other question, As I understand, data guard physical standby database requested the same as primary database.
If you install golden gate in physical standby database host, are there any issue for data guard configuration?
Thanks
newdba

Physical standby database Version 11g Creation over grid control 10g

We are useing oracale 11g enterprise edition and want to create a physical standby database on another machine:
On primary host we've installed "standard database" and turned on archive log mode over em.
On the standby host we've installed only oracle without a database and without a listener.
On a third machine we've installed grid control and registered the primary and standby hosts. Using EM with Data Grid I'm attempting to create a Physical Standby on standby host. Everything is working except for the last part as noted here:
SQL*Plus: Release 11.1.0.6.0 - Production on Do Apr 3 11:21:17 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
SQL> SQL> Bei einer nicht hochgefahrenen Instance angemeldet.
SQL> SQL> ORA-32004: obsolete and/or deprecated parameter(s) specified
ORACLE-Instance hochgefahren.
Total System Global Area 535662592 bytes
Fixed Size          1334380 bytes
Variable Size          167773076 bytes
Database Buffers     360710144 bytes
Redo Buffers          5844992 bytes
SQL>
Datenbank wurde geändert.
SQL> Verbindung zu Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options beendet
dgcreate.DGrenameFiles: ALTER DATABASE RENAME FILE 'C:\ORACLE\ORADATA\TTDB1\SYSTEM01.DBF' to 'c:\oracle\product\11.1.0\db_1\oradata\dg3\SYSTEM01.dbf'
dgcreate.DGrenameFiles: SELECT STATUS FROM V$DATAFILE WHERE NAME = 'C:\ORACLE\ORADATA\TTDB1\SYSTEM01.DBF'
dgcreate.DGrenameFiles: ALTER DATABASE RENAME FILE 'C:\ORACLE\ORADATA\TTDB1\SYSAUX01.DBF' to 'c:\oracle\product\11.1.0\db_1\oradata\dg3\SYSAUX01.dbf'
dgcreate.DGrenameFiles: SELECT STATUS FROM V$DATAFILE WHERE NAME = 'C:\ORACLE\ORADATA\TTDB1\SYSAUX01.DBF'
dgcreate.DGrenameFiles: ALTER DATABASE RENAME FILE 'C:\ORACLE\ORADATA\TTDB1\UNDOTBS01.DBF' to 'c:\oracle\product\11.1.0\db_1\oradata\dg3\UNDOTBS01.dbf'
dgcreate.DGrenameFiles: SELECT STATUS FROM V$DATAFILE WHERE NAME = 'C:\ORACLE\ORADATA\TTDB1\UNDOTBS01.DBF'
dgcreate.DGrenameFiles: ALTER DATABASE RENAME FILE 'C:\ORACLE\ORADATA\TTDB1\USERS01.DBF' to 'c:\oracle\product\11.1.0\db_1\oradata\dg3\USERS01.dbf'
dgcreate.DGrenameFiles: SELECT STATUS FROM V$DATAFILE WHERE NAME = 'C:\ORACLE\ORADATA\TTDB1\USERS01.DBF'
dgcreate.DGrenameFiles: ALTER DATABASE RENAME FILE 'C:\ORACLE\ORADATA\TTDB1\EXAMPLE01.DBF' to 'c:\oracle\product\11.1.0\db_1\oradata\dg3\EXAMPLE01.dbf'
dgcreate.DGrenameFiles: SELECT STATUS FROM V$DATAFILE WHERE NAME = 'C:\ORACLE\ORADATA\TTDB1\EXAMPLE01.DBF'
dgcreate.DGrenameFiles: ALTER DATABASE RENAME FILE 'C:\ORACLE\ORADATA\TTDB1\REDO01.LOG' to 'c:\oracle\product\11.1.0\db_1\oradata\dg3\REDO01.log'
dgcreate.DGrenameFiles: ALTER DATABASE RENAME FILE 'C:\ORACLE\ORADATA\TTDB1\REDO02.LOG' to 'c:\oracle\product\11.1.0\db_1\oradata\dg3\REDO02.log'
dgcreate.DGrenameFiles: ALTER DATABASE RENAME FILE 'C:\ORACLE\ORADATA\TTDB1\REDO03.LOG' to 'c:\oracle\product\11.1.0\db_1\oradata\dg3\REDO03.log'
dgcreate.DGrenameFiles: ALTER DATABASE CLEAR LOGFILE GROUP 1
dgcreate.DGrenameFiles: ALTER DATABASE CLEAR LOGFILE GROUP 2
dgcreate.DGrenameFiles: ALTER DATABASE CLEAR LOGFILE GROUP 3
dgcreate.DGgetRecoverySCN: SELECT MAX(NEXT_CHANGE#) FROM V$ARCHIVED_LOG
dgcreate.DGrecoverStby: ALTER DATABASE RECOVER AUTOMATIC FROM '%ORACLE_HOME%\RDBMS' STANDBY DATABASE UNTIL CHANGE 1061001
dgcreate.DGrecoverStby: ALTER DATABASE RECOVER CANCEL
dgcreate.DGrecoverStby: ALTER DATABASE OPEN READ ONLY
SQL Error: ORA-16004: Sciherungs-Datenbank muss wiederhergestellt werden
ORA-01152: Backup-Datei zum Wiederherstellen der Datei 1 war nicht alt genug
ORA-01110: Datendatei 1: 'C:\ORACLE\PRODUCT\11.1.0\DB_1\ORADATA\DG3\SYSTEM01.DBF' (DBD ERROR: OCIStmtExecute)
What is to do?
What mean's in this case:
"ORA-01152 file string was not restored from a sufficiently old backup
Cause: An incomplete recovery session was started, but an insufficient number of redo logs were applied to make the database consistent. This file is still in the future of the last redo log applied. The most likely cause of this message is forgetting to restore the file from backup before doing incomplete recovery.
Action: Apply additional redo log files until the database is consistent or restore the datafiles from an older backup and repeat recovery."

Thanks for your immediate reply,
but there's a problem: We don't create the standby database manually. The creation is done by data guard over grid control. And the "automatic" creation stopps at this point.
Unfortunatly we don't know, wich steps of a manuall standby database creation are done and wich steps are not done at this point.
The oracle documentation (for release 11g) to create a manuall standby database is "B28294-02". But there's no step 5 "alter database recover managed standby database disconnect from session". Do you mean step 4 of chapter 3.2.6?
Is there no way, to create a standby database automatically over grid control? Or do we have to do something else before creating the physical standby database? Perhaps we have to create a full backup after switching to archive log mode?

Patching with physical standby document

There is this old document targeting 9i. Is there anything for 11g of a similar nature:
Applying Patch Sets / Interim Patches with Physical Standby Database in Place in Oracle 9i [ID 187242.1]

You require others to search for free on your behalf?
Shame on you!
Sybrand Bakker
Senior Oracle DBA

Standby not in sync with primary

Hi,
I am having oracle 9.2.0.7 on AIX and having physical standby database running on another server. Since the last 2 days it is not in sync and the required archivelog files are removed from production.
Could you please help me out to resolve the issue?
Thanx

Hi
Step 1 On the standby database, find the SCN which will be used for the incremental
backup at the primary database:
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
Step 2 In RMAN, connect to the primary database and create an incremental backup
from the SCN derived in the previous step:
Step 3 RMAN> BACKUP INCREMENTAL FROM SCN <SCN from previous step>
DATABASE FORMAT '/tmp/ForStandby_%U' tag 'FORSTANDBY';
step 4 Transfer all backup sets created on the primary system to the standby system
SCP /tmp/ForStandby_* standby:/tmp
Step 5 Connect to the standby database as the RMAN target, and catalog all incremental
backup pieces:
RMAN> CATALOG START WITH '/tmp/ForStandby';
Step 6 Recover the standby database with the cataloged incremental backup:
RMAN> RECOVER DATABASE NOREDO;
Step 7 In RMAN, connect to the primary database and create a standby control file
backup:
RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/tmp/ForStandbyCTRL.bck';
Step 8 Copy the standby control file backup to the standby system. For example:
SCP /tmp/ForStandbyCTRL.bck standby:/tmp
Step 9 Shut down the standby database and startup nomount:
RMAN> SHUTDOWN;
RMAN> STARTUP NOMOUNT;
Step 10 In RMAN, connect to standby database and restore the standby control file:
RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/ForStandbyCTRL.bck';
Step 11 Shut down the standby database and startup mount:
RMAN> SHUTDOWN;
RMAN> STARTUP MOUNT;
Step 12 If the primary and standby database data file directories are identical, skip to step13. If the primary and standby database data file directories are different, then in
RMAN, connect to the standby database, catalog the standby data files, and switch
the standby database to use the just-cataloged data files. For example:
RMAN> CATALOG START WITH '+DATA_1/CHICAGO/DATAFILE/';
RMAN> SWITCH DATABASE TO COPY;
Step 13 If the primary and standby database redo log directories are identical, skip to step 14. Otherwise, on the standby database, use an OS utility or the asmcmd utility (if
it is an ASM-managed database) to remove all online and standby redo logs from
the standby directories and ensure that the LOG_FILE_NAME_CONVERT parameter
is properly defined to translate log directory paths. For example, LOG_FILE_
NAME_CONVERT=’/BOSTON/’,’/CHICAGO/’.
Step 14 On the standby database, clear all standby redo log groups (there may be more
than 3):
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 3;
Step 15 On the standby database, restart Flashback Database:
SQL> ALTER DATABASE FLASHBACK OFF;
SQL> ALTER DATABASE FLASHBACK ON;
Step 16 On the standby database, restart MRP:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
With this you can recvoer your Standby . I wish it will works for You.
Thanks
Karan

Data Guard - MRP stuck issues on a physical standby database

Hi,
Oracle 11.2.0.3 DG running. When i do a switchover the physical standby database has error with following error
ARC0: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance <primaryDB> - Archival Error
On standby DB
SQL>select process, thread#, sequence#, status from v$managed_standby where process='MRP0';
PROCESS THREAD# SEQUENCE# STATUS
MRP0 1 548 APPLYING_LOG
So according to Oracle support link i executed following
SQL>recover managed standby database cancel;
SQL>recover automatic standby database;
The above seems to resolve the issue. What is causing is this?

Hello again;
Those both look perfect. I combed through my notes and found nothing like this for your version.
Yes, I would open an SR since it appears you have done everything correct.
ORA-600 [3020] "Stuck Recovery" [ID 30866.1]
The "Known Bugs" section of the above has a few 11.2.0.3 entries.
Generally the MRP gets stuck because data Guard thinks there's a GAP, you run out of room in the FRA on the Standby, or redo logs are too small and the system is switching very fast.
Best Regards
mseberg
Later
Never asked you but this "log_archive_max_processes" can be set as high as 30.
Edited by: mseberg on Jul 16, 2012 8:01 PM
h2. Still later
Found this which is closer :
Bug 13553883 - Archiver stuck but no ORA-19xxx error in alert log (messages need changing) [ID 13553883.8]

Standby Database not syncronized with primary.

DB: 10.2.0.4.0
OS RedHat Linux
My standby Database not syncronized with primary, because of space issue mrp process was stopped.
During that we added 4 datafile in primary database in that case how we can sync standby database?
There are no unamed files on standby database.
SQL> select name from v$datafile where name like '%UNNAME%';
no rows selected

Prath wrote:
When i trying to recover database getting below error:
Starting recover at 11-DEC-10
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 12/11/2010 12:00:23
RMAN-06094: datafile 73 must be restored
Note: Datafile 73 not available on standby database.Execute select name from v$datafile statement from standby and post there.
(Of course you can rebuild standby database again ,create standby controlfile and copy all datafiles)

Problem creating physical Standby database with RMAN

Hi All
I am trying to learn oracle dataguard and as part of the process learning creating standby database.
Platform : Sun-Fire-V250 Sparc, Solaris 10
Database Version - Oracle 11R2
I am creating standby database on same server, so directory structure is different.
Following the instructions on Oracle site I managed to create a functional physical standby database. But I am not able to create standby database using RMAN. These are the steps that I followed-
1.Set up all necessary parameters on primary database as done while creating physical standby database manually, eg setting force logging, creating standby logs etc.
2.Edited parameter file on primary database as done while creating manual pysical standby database creation. Some of the changes done are-
On Primary Database:
*.FAL_CLIENT='orcl11020' #Primary database unique name
*.FAL_SERVER='stdby_11' #Standby database unique name
db_file_name_convert='/<dir>/oradata/stdby_11','/<dir>/oradata/orcl11020'
log_file_name_convert='/<dir>/oradata/stdby_11','/<dir>/oradata/orcl11020','/<dir>/oradata/stdby_11/redo_mem','/<dir>/oradata/orcl11020/redo_mem'
standby_file_management=auto
*.log_archive_config='DG_CONFIG=(orcl11020,stdby_11)'
*.log_archive_dest_1='LOCATION=/<dir>/flash_recovery_area/ORCL11020/archivelog
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=orcl11020'
*.log_archive_dest_2='SERVICE=stdby_11 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=stdby_11'
*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'
*.LOG_ARCHIVE_DEST_STATE_2='ENABLE'
*.LOG_ARCHIVE_FORMAT='%t_%s_%r.arc'
*.LOG_ARCHIVE_MAX_PROCESSES=30
Copied same pfile for standby database and modified following-
*.control_files='/<dir>/oradata/stdby_11/stdby_11.ctl','/<dir>/fra_stdby/stdby_11/stdby_11.ctl'
*.db_name='orcl1102'
*.db_unique_name='stdby_11'
*.FAL_CLIENT='stdby_11'
*.FAL_SERVER='orcl11020'
db_file_name_convert='/<dir>/oradata/orcl11020','/<dir>/oradata/stdby_11'
log_file_name_convert='/<dir>/oradata/orcl11020','/<dir>/oradata/stdby_11','/<dir>/oradata/orcl11020/redo_mem','/<dir>/oradata/stdby_11/redo_mem'
standby_file_management=auto
*.log_archive_dest_1='LOCATION=/<dir>/fra_stdby/STDBY_11/archivelog
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=stdby_11'
*.log_archive_dest_2='SERVICE=orcl11020 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=orcl11020'
3. Add relevant information in tnsnames.ora and listener.ora files and then restart listener.
3. Created password file with same credential as primary database.
4.Up-to-date RMAN backup of primary database available.
5.Create standby controlfile with rman
While primary database s open (I tried with primary database in mount mode as well)-
$>rman catalog rman/paswd@rman target /
RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY;
6. Open a new terminal and startup standby database in nomount mode using parameter file created -
$>ORACLE_SID=stdby_11
$>export ORACLE_SID
$>sqlplus / as sysdba
SQL>STARTUP NOMOUNT pfile='<location/initfilename.ora'
SQL>quit
$> rman AUXILIARY / target sys/passwd@orcl11020 catalog rman/passwd@rman
RMAN>DUPLICATE TARGET DATABASE FOR STANDBY DORECOVER;
RMAN finishes without error but archive logs are not being tranported. Looking at the log, following caught my eye-
Error 1017 received logging on to the standby
Check that the primary and standby are using a password file
and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
and that the SYS password is same in the password files.
returning error ORA-16191
FAL[client, ARC2]: Error 16191 connecting to orcl11020 for fetching gap sequence
Errors in file /<>dir>/diag/rdbms/stdby_11/stdby_11/trace/stdby_11_arc2_24321.trc:
ORA-16191: Primary log shipping client not logged on standby
Errors in file /<dir>/diag/rdbms/stdby_11/stdby_11/trace/stdby_11_arc2_24321.trc:
ORA-16191: Primary log shipping client not logged on standby
So on both primary and standby I confirmed
SQL> show parameter remote_login_passwordfile
NAME TYPE VALUE
remote_login_passwordfile string EXCLUSIVE
To make double sure that password files are same, I shutdown both databases, delete password files and recreated with same credentials.
Password files are called - orapworcl11020 and orapwstdby_11
Can someone guide me where thisngs are going wrong here please.

Not sure if I understood it clearly.
SELECT * FROM V$ARCHIVE_GAP;
returns no rows so there is no gap.
But could you please explain me the result of the previous query. To catch up again, on standby when I check
SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG
SEQUENCE# APPLIED
75 NO
74 NO
76 NO
77 NO
I understand that though archive files have been copied across but they are not applied yet.
On primary when I give your query -
SELECT name as STANDBY,SEQUENCE#,applied, completion_time
2 FROM v$archived_log
3 where dest_id=2
4 and sequence# BETWEEN 74 and 80;
I get -
STANDBY SEQUENCE# APPLIED COMPLETIO
stdby_11 74 YES 28-JUN-11
stdby_11 75 YES 28-JUN-11
stdby_11 76 YES 29-JUN-11
stdby_11 77 YES 29-JUN-11
stdby_11 78 YES 29-JUN-11
stdby_11 79 YES 29-JUN-11
stdby_11 80 YES 29-JUN-11
stdby_11 75 NO 07-JUL-11
stdby_11 74 NO 07-JUL-11
stdby_11 76 NO 07-JUL-11
stdby_11 77 NO 07-JUL-11
stdby_11 78 NO 07-JUL-11
I have intentionally given
sequence# BETWEEN 74 and 80
because I know in the current incarnaion of the database, max sequence is 78.
So my understanding is, the rows between 28-29 June are from previous incarnation, correct me if I am wrong
Archive files of the current incarnation, since I successfully created standby database are shipped but yet to be applied - am I right?
Then my final question is, when will these archives be applied to standby database?
I am sorry to ask too many questions but I am just trying to understand how it all works.
Thanks for your help again

Physical Standby Database Creation with RMAN

Hi,
I'm in 10g on Linux. I want to create a standby database on another Linux server. I did not find a clear procedure to create it in Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02
and niether in Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) B14239-04
In the last one chapter 3 sends you to F appendix and F appendix says do nothing before having than all in chapter 3 :
In F.1.1 page F-2 it is said :
See Chapter 3 for a complete discussion of physical standby database preparation,including initialization parameter settings. You must perform all necessary preparation tasks described in these chapters before RMAN can successfully create the standby database files and mount the standby database.
Any way I'm looking for a procedure or clear article to create it.
Many thanks before.

Physical Standby Database Creation with RMAN
Use the DUPLICATE command.
Check out this metalink doc: Note:374069.1 and Note:118409.1
Message was edited by:
STW
Message was edited by:
STW

Issue with physical standby database not in sync with primary

Similar Messages

Maybe you are looking for