Recovering Physical Standby Database

I created a simple script to recover/synchronies physical standby database. This script runs on schedule basis and finds if any recovery is required and if so, it applies the required archived files, or otherwise it will give an error showing the suggested file is not found. I want to suppress that error message and I wonder if there is a way to do that, so Oracle will exit the session without displaying the error message.
Thanks

in earlier u ask about the error controling now younis u r asking about manual setup for standby.
anyways yes it is possible.
u create the replica of your database
like install the other server with same version and same datafile location and alll...
there is no automatic transmission from oracle but u can automate from script like using rpc and in windows its more easy to copy archive anyways
shutdown ur primary database copy all relevant files
and paste it to ur secondary database
now your database is ready in other machine as well.
now what routine you have to follow for doing manual standby is
you have copy all archives daily after copy of physical db files and also your control file from the primary database.
than recover database;
regards,
umair

Similar Messages

Problem in recover physical standby database(Data Guard) by rman

Hello to all
I have created a physical standby database ,I want make backup of it by rman and when I lose it's datafile I can restore it ,making backup and restore is fine but in recovery I encounter some problem
scenarios is follow
1- In rman I create a backup of standby database by this command:
backup database plus archivelog delete all input;
2- I run this comman in rman for recover standby database
run{
2> set until scn 1392701;
3> restore database;
4> recover database;
5> }
(1392701 is extracted from this query "SELECT MAX(NEXT_CHANGE#)+1 UNTIL_SCN FROM V$LOG_HISTORY LH,
V$DATABASE DB WHERE LH.RESETLOGS_CHANGE#=DB.RESETLOGS_CHANGE# AND LH.RESETLOGS_TIME =
DB.RESETLOGS_TIME;" "http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/rman.htm")
but RMAN result is like this:
executing command: SET until clause
Starting restore at 13-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from
backup set
restoring datafile 00001 to /u01/app/oracle/oradata/sari/system01.dbf
restoring datafile 00002 to /u01/app/oracle/oradata/sari/undotbs01.dbf
restoring datafile 00003 to /u01/app/oracle/oradata/sari/sysaux01.dbf
restoring datafile 00004 to /u01/app/oracle/oradata/sari/users01.dbf
restoring datafile 00005 to /u01/app/oracle/oradata/sari/example01.dbf
restoring datafile 00006 to /u01/app/oracle/oradata/sari/users02.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/0ek24dt4_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/backup/0ek24dt4_1_1
tag=TAG20081213T042506
channel ORA_DISK_1: restore complete, elapsed time: 00:01:07
Finished restore at 13-DEC-08
Starting recover at 13-DEC-08
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 116 is already on disk as file /u01/app/oracle/oradata/archive/1_116_666786084.arc
archive log thread 1 sequence 117 is already on disk as file /u01/app/oracle/oradata/archive/1_117_666786084.arc
archive log filename=/u01/app/oracle/oradata/archive/1_116_666786084.arc thread=1 sequence=116
archive log filename=/u01/app/oracle/oradata/archive/1_117_666786084.arc thread=1 sequence=117
unable to find archive log
archive log thread=1 sequence=118
RMAN-03002: failure of recover command at 12/13/2008 05:14:13
RMAN-06054: media recovery requesting unknown log: thread 1
seq 118 lowscn 1392700
3- then I decline 1392701 to 1392700 and i run this command
run{
2> set until scn 1392700;
3> restore database ;
4> recover database;
5> }
executing command: SET until clause
Starting restore at 13-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from
backup set
restoring datafile 00001 to /u01/app/oracle/oradata/sari/system01.dbf
restoring datafile 00002 to /u01/app/oracle/oradata/sari/undotbs01.dbf
restoring datafile 00003 to /u01/app/oracle/oradata/sari/sysaux01.dbf
restoring datafile 00004 to /u01/app/oracle/oradata/sari/users01.dbf
restoring datafile 00005 to /u01/app/oracle/oradata/sari/example01.dbf
restoring datafile 00006 to /u01/app/oracle/oradata/sari/users02.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/0ek24dt4_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/backup/0ek24dt4_1_1 tag=TAG20081213T042506
channel ORA_DISK_1: restore complete, elapsed time: 00:01:08
Finished restore at 13-DEC-08
Starting recover at 13-DEC-08
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 116 is already on disk as
file /u01/app/oracle/oradata/archive/1_116_666786084.arc
archive log thread 1 sequence 117 is already on disk as
file /u01/app/oracle/oradata/archive/1_117_666786084.arc
archive log filename=/u01/app/oracle/oradata/archive/1_116_666786084.arc thread=1
sequence=116archive log
filename=/u01/app/oracle/oradata/archive/1_117_666786084.arc
thread=1 sequence=117Oracle Error:
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: '/u01/app/oracle/oradata/sari/system01.dbf'
media recovery complete, elapsed time: 00:00:10
Finished recover at 13-DEC-08
4- if I run
run{
restore database;
recover database;
I will recieve that error of step 2 (RMAN-06054: media recovery requesting unknown log: thread 1
seq 118 lowscn 1392700)
5- if I just restore the database and I don't perform recovery by rman and I restart redo apply all thing seem fine
but in opening database I'll recieve ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/u01/app/oracle/oradata/sari/system01.dbf' error)
do you know what is problem
thanks
Edited by: ARKH on Dec 12, 2008 11:06 PM

hi
I myself have found the solution , when I recover the standby database
it do recovery but at the end of recovery it raise the error(RMAN-06054: media recovery requesting unknown log: thread 1
seq 118 lowscn 1392700) but if I begain redo apply before open the database
and I wait till all redo apply process start and communication between the
standby database and the primary database start, then I can
open the standby database and no error will raise
but if befor restarting redo apply I open the database I'll recieve the
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/u01/app/oracle/oradata/sari/system01.dbf' error
thanks

Error while trying to open physical standby database - (DATA GUARD)

Hi Everyone,
I have problems in opening the database of the physical standby in read- write mode/ read only mode. I have a primary server which is running on 2 node RAC and the standby on a seperate single server being used as DR. I recently got this server and my aim was to isolate the standby server from primary server and perform few test. As it has never been tested even once.
Primary Database spec: (2 Node Rac on ASM)
Oracle Version : 10.2.0.3.0
O/s : HP-UX B.11.23
Standby Database spec: (Single Node)
Oracle Version : 10.2.0.3.0
O/s: HP-UX db01 B.11.23
Error:
alter database recover managed standby database cancel;
Database altered.
SQL> alter database open
2 ;
alter database open
ERROR at line 1:
ORA-16004: backup database requires recovery
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '+DATA/dprod/datafile/system01.dbf'
Parameters :
log_archive_dest_2 string SERVICE=PROD1 LGWR ASYNC VALID
FOR=(ONLINELOGFILES,PRIMARY_
ROLE) DB_UNIQUE_NAME=PROD
remote_archive_enable string true
fal_client string DPROD
fal_server string PROD1, PROD2
Steps tried so far:
Changed log_archive_dest_2 = DEFER on both the primary nodes
Standby :
startup nomount
alter database mount standby database;
alter database recover managed standby database disconnect;
alter database recover managed standby database cancel;
alter database open/readonly (tried both)
Same error.
On Primary:
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
55702
on Standby:
MAX(SEQUENCE#)
33289
Primary Database:
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIME NEXT_TIME
55700 13-JUN-11 13-JUN-11
55700 13-JUN-11 13-JUN-11
55701 13-JUN-11 13-JUN-11
55701 13-JUN-11 13-JUN-11
55702 13-JUN-11 13-JUN-11
60824 rows selected.
Standby Database:
SEQUENCE# FIRST_TIME NEXT_TIME
55698 13-JUN-11 13-JUN-11
55699 13-JUN-11 13-JUN-11
55700 13-JUN-11 13-JUN-11
55701 13-JUN-11 13-JUN-11
15206 rows selected.
Additional Information :
There is a delay of 20 minutes before the logs get applied. which has been intentional set by team.
Any help will be highly appreciated. Thanks in advance
Sadiq

Hi,
Primary Database:
select status,checkpoint_count from v$datafile_header;
STATUS CHECKPOINT_COUNT
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
STATUS CHECKPOINT_COUNT
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 59736
ONLINE 59736
ONLINE 59736
ONLINE 59736
ONLINE 59736
STATUS CHECKPOINT_COUNT
ONLINE 57717
ONLINE 57717
57 rows selected.
Standby Database;
select status,checkpoint_count from v$datafile_header;
STATUS CHECKPOINT_COUNT
ONLINE 672445072
ONLINE 672445072
ONLINE 672445072
ONLINE 672445072
ONLINE 672445072
ONLINE 672445072
ONLINE 672445072
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
STATUS CHECKPOINT_COUNT
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
ONLINE 32742
ONLINE 32742
ONLINE 32742
ONLINE 32742
ONLINE 32742
STATUS CHECKPOINT_COUNT
ONLINE 30723
ONLINE 30723
57 rows selected.
Archieve log list :
Primary database:
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 49110
Next log sequence to archive 49111
Current log sequence 49111
Standby Database:
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 49110
Next log sequence to archive 0
Current log sequence 49111
I tried log switch multiple times in primary database i saw that its getting highlighted in standby database.

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

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>

Starting Physically Standby Database in Mount Mode

Hi All
I have configured Data Guard using Oracle 10g 10.2.0.4.0 (64 bits) on Windows 2008 Server (64 bits) Release 2 Enterprise.
Data guard configuration was OK as the message from "Enable Configuration DG1" was "SUCCESS" for both
Primary and Standby Database. I have also set both Databases and TNS to start Automatically whenever Windows Starts.
The Problem is as long as the Standby Server is running, there is No issue.
But when we Restarts the Backup Server, Physically Standby Database is Started and TNS is also Started,
but Archives are not received until I physically do the following steps so that it can received the Archives.
SQL> startup nomount;
SQL> alter database mount standby database;
SQL> alter database recover managed standby database disconnect from session;
Is there a way to start Physically Standby Database in Mount mode when windows started.
Regards
Thunder2777

Hi Mihael
I have created 2 files. 1 Bat file 2nd sql file which contains all commands as written above.
When I execute start.bat file
1. set ORACLE_HOME=C:\oracle\product\10.2.0\db_1
2. set ORACLE_SID=UMISBK
3. sqlplus / [email protected]
1 & 2 executed properly. At 3 it just display SQL help for login as shown below.
SQL*Plus: Release 10.2.0.4.0 - Production
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Usage 1: sqlplus -H | -V
    -H             Displays the SQL*Plus version and the usage help.
    -V             Displays the SQL*Plus version.
Usage 2: sqlplus [ [<option>] [<logon>] [<start>] ]
<option> is: [-C <version>] [-L] [-M "<options>"] [-R <level>] [-S]
It Did Not execute start.sql file to excute sql commands.
Regards
Thunder2777

Physical Standby database Vs. Logical Standby database

I have few questions regarding capability of Logical Standby Database against Physical Standby database.
1. How efficient is Logical Standby database in terms of Physical Standby Database?? How both differ from each other and can I use Logical Standby Database for disaster Recovery?? Can It be use for recovering the failed Primary Instance?? If yes how efficient and reliable it is??
2. What are the known bugs and roadblocks for logical standby database on Oracle 10.2.0.1 on Soalris X86-64?
3.As logical standby database not going to replicate each and every schema of Primary database?? how is the change management effects to the logical standby from primary?? I mean there are some parameters and job that we create on primary how can it be transferred over to the logical standby??

1. How efficient is Logical Standby database in terms
of Physical Standby Database?? How both differ from
each other and can I use Logical Standby Database for
disaster Recovery?? Can It be use for recovering the
failed Primary Instance?? If yes how efficient and
reliable it is??I'm not sure what sort of "efficiency" you're talking about here...
Physical standby is just the old, tried and true application of archived logs to recover a database. Very solid, very old school.
Logical standby, on the other hand, is parsing the redo log, extracting logical change records, and applying them to the standby database. This obviously takes a bit more processing effort, it's newer technology, it doesn't have quite the level of support that physical standby does (i.e. certain data types are excluded), etc. You certainly can use it for failover, but it isn't quite as robust as a physical standby. Of course, this is getting better and better all the time and is definitely a focus of Oracle's development efforts.
On the other hand, logical standby systems can do things other than act as a warm standby. They can be open serving reports, for example. You can create additional structures (i.e. new materialized views) to support reporting. A physical standby is pretty much always going to be in managed recovery mode, so it cannot be queried.
2. What are the known bugs and roadblocks for logical
standby database on Oracle 10.2.0.1 on Soalris
X86-64?a) You'll want to do a Metalink search
b) If you're talking about a high-availability solution, why are you looking at a base release of the database? Why wouldn't you apply the latest patchset?
3.As logical standby database not going to replicate
each and every schema of Primary database?? how is
the change management effects to the logical standby
from primary?? I mean there are some parameters and
job that we create on primary how can it be
transferred over to the logical standby??I'm not sure I understand... Changes made to the primary generate redo. Oracle parses that redo, generates a LCR, and sends that to the standby database where that change record gets applied.
Justin

RE logical/physical standby database

1. Why logical standby database is SQL apply, and Physical standby database is redo apply? What ‘s the meaning/objective for that? (pls don’t tell me what is SQL/redo apply)
2. As we know, a logical standby database can be used for reporting and querying if primary database is down, why we still need a physical standby database (it can’t do that during recovering process, it just a same copy of primary database)? Why not just go ahead to set up only a perfect logical standby database? (just because logical one can’t accommodate all kinds of data type???)
3. Combined with Real time Apply and maximum protection, we can achieve a zero data loss, but could we achieve a zero downtime? Why or why not?

Go Through Below link
>>>Can you convert a Logical standby to a Physical Standby?

Configuring a physical standby database in 9i

Hi all,
   SO: Solaris 10 SPARC x64
   DB: 9.2.0.6 x64
   I have a task of creating a physical standby database in a solaris 10 - Oracle 9.2.0.6 env. I am used to do this configuration on the 11.2 version of Oracle, and because of that i have some doubts regarding the possible different configurations necessary to do in a 9i Database.
   1) The main doubt that i have is regarding the RMAN use. I Would like to know if it is possible to restore a normal backup of my primary database into the standby database, and after that, apply the necessary archived logs to sync the standby with the primary? The controlfile that i would use would be the one created by the "BACKUP CURRENT CONTROLFILE FOR STANDBY" RMAN command. The RMAN script woulb be like the one below:
run {
allocate channel ch01 device type disk;
allocate channel ch02 device type disk;
allocate channel ch03 device type disk;
allocate channel ch04 device type disk;
restore controlfile from 'standby_controlfile.ctl';
sql 'alter database mount';
restore database;
recover database;
   2) The directory structure will be the same, so i think it is not necessary to use the SET NEWNAME and the DB_FILE_NAME_CONVERT/LOG_FILE_NAME_CONVERT, is that correct?
   3) Do you have any other considerations regarting the differences between a 9i and a 11g Physical Standby Configuration?
Thanks for your attention and pacience.

Hello;
On question 1 - See this:
http://docs.oracle.com/cd/B10500_01/server.920/a96566/rcmstand.htm
On question 2 - Assuming RMAN work then DB_FILE_NAME_CONVERT/LOG_FILE_NAME_CONVERT would NOT have to be set for the same directory structure.
On question 3 - double check this:
http://docs.oracle.com/cd/B10500_01/server.920/a96653.pdf
Best Regards
mseberg

About physical standby database

We have physical standby database(10g). what are steps to put standby database in ready only mode for time being and then put it back in primary-secondary relationship once cheking is done?

Cancel the redo Apply
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;Open The database
SQL>ALTER DATABASE OPEN;Do your stuff.
Once done, shut it down, then mount it again and resume the redo apply
SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP NOMOUNT;
SQL>ALTER DATABASE MOUNT STANDBY DATABASE;
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;If you use real-time redo apply, you may want to issue the following command instead of the previous one.
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;...and pretty much that is it.
Be aware that while running it in read-only mode, no logs from the primary are being applied. Also you may hit some bugs when you open your standby database. So if this standby is your production one, make sure you know how to deal in a situation when you need to resolve possible issues.
Jason Arnell has explained one possible buggy scenario on his blog - LINK.
--Mihajlo

Physical standby database error

Hi,
I try to create physical standby in my local machine using oracle 10g
version :10.2.0.1.0
Os: windows xp.
I followed steps and parameter files
on primary :-
sql>alter database force logging;
orcl.__db_cache_size=155189248
orcl.__java_pool_size=4194304
orcl.__large_pool_size=4194304
orcl.__shared_pool_size=75497472
orcl.__streams_pool_size=0
*.audit_file_dest='D:\oracle\product\10.2.0/admin/orcl/adump'
*.background_dump_dest='D:\oracle\product\10.2.0/admin/orcl/bdump'
*.compatible='10.2.0.1.0'
*.control_files='D:\oracle\product\10.2.0\oradata\orcl\control01.ctl','D:\oracl
e\product\10.2.0\oradata\orcl\control02.ctl','D:\oracle\product\10.2.0\orad
ata\orcl\control03.ctl'
*.core_dump_dest='D:\oracle\product\10.2.0/admin/orcl/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='orcl'
*.db_unique_name='orcl'
*.log_archive_config='DG_CONFIG=(orcl,stby)'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.job_queue_processes=10
*.open_cursors=300
*.pga_aggregate_target=80740352
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=244318208
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='D:\oracle\product\10.2.0/admin/orcl/udump'
*.log_archive_dest_1='LOCATION=D:\oracle\archive
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl'
*.log_archive_dest_2='SERVICE=stby LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stby'
*.log_archive_format=%t_%s_%r.arc
*.log_archive_dest_state_1=ENABLE
*.log_archive_dest_state_2=ENABLE
On standby
orcl.__db_cache_size=155189248
orcl.__java_pool_size=4194304
orcl.__large_pool_size=4194304
orcl.__shared_pool_size=75497472
orcl.__streams_pool_size=0
*.audit_file_dest='D:\stby\adump'
*.background_dump_dest='D:\stby\bdump'
*.compatible='10.2.0.1.0'
*.control_files='D:\stby\ctrl.ctl'
*.core_dump_dest='D:\stby\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='orcl'
*.db_unique_name='stby'
*.log_archive_config='DG_CONFIG=(orcl,stby)'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.job_queue_processes=10
*.open_cursors=300
*.pga_aggregate_target=80740352
*.processes=150
*.remote_login_passwordfile='NONE'
*.sga_target=244318208
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='D:\stby\udump'
*.db_file_name_convert='D:\oracle\product\10.2.0\oradata\orcl','D:\stby'
*.log_file_name_convert='D:\oracle\product\10.2.0\oradata\orcl','D:\stby'
*.log_archive_dest_1='LOCATION=D:\oracle\archive
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=stby'
*.log_archive_dest_2='SERVICE=orcl LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=orcl'
*.standby_archive_dest='D:\stby\archive'
*.log_archive_dest_state_1=ENABLE
*.log_archive_dest_state_2=ENABLE
*.standby_file_management='AUTO'
*.fal_server='orcl'
*.fal_client='stby'
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup pfile=D:\stby\initstby.ora nomount;
ORACLE instance started.
Total System Global Area 247463936 bytes
Fixed Size 1248332 bytes
Variable Size 79692724 bytes
Database Buffers 159383552 bytes
Redo Buffers 7139328 bytes
SQL> alter database mount standby database;
Database altered.
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> alter database open read only;
alter database open read only
ERROR at line 1:
ORA-01154: database busy. Open, close, mount, and dismount not allowed now
SQL> recover managed standby database cancel;
Media recovery complete.
SQL> alter database open read only;
Database altered.
SQL> select sequence#,first_time,next_time from v$archived_log order by sequence
no rows selected
No archive s generated in standby ..
what i mistake.
Reagrds
S.Azar

Anand... wrote:
Firstly you can use "*select sequence#,first_time,next_time from v$archived_log order by sequence#;"* command in mount stage itself.No need to open the standby database in ready only mode.
No rows selected in mount stage also.
The V$ARCHIVED_LOG fixed view on the physical standby database shows all the archived redo log files received from the primary database.
sql> select * from v$archived_log;
no rows selected.
and No archived logs received from primary database to physical standby . i think here i wrongly configure parameter file.
sql> RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; -- > start Redo Apply
When you do log switch on the primary are the archive logs getting transferred to the standby database???Is there some error in the alert log file in the primary database.
No..
>
[http://advait.wordpress.com/2007/06/12/setting-up-oracle-dataguard-for-10g/]
Regards
S.Azar

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?

Downtime for logical or physical standby database

Hi ,
Are there any downtime required to refresh the data from the primary database to logical standby or physical standby database. What are the pros and cons of
using logical and physical standby database approach. which one is advisable to use in production environment.
Regards,
Richard

Hi Richard,
I'd suggest you read the documentation as a starting point, to answer your questions on here would be quite lengthy,
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/toc.htm
In a nutshell you dont need downtime to maintain a standby, you can create them from a hot backup of your primary and get them recovering whilst it is open, in terms of which type of standby to use (physical or logical) that depends on your requirements for the use of the standby ... as I said read the doco (chapter 2 has a section on the benefits of each type).
HTH
Paul

Physical standby database

My physical standby database is on Win 2003 server, Oracle version is 9.2.0.3.
Windows team asked me to shutdown the standby database and i did the same. After server reboot i put the standby in managed recovery mode but logs were not shipping even though i gave log switches at the primary side.
I executed the below command
startup nomount
alter database mount standby database;
alter database recover managed standby database disconnect from session;
I again bounced the standby database but this time i gave
recover managed standby database disconnect from session;
Instead of alter database recover managed...
Below are the logs from alert log file of the primary database
ARC1: Beginning to archive log 4 thread 1 sequence 19165
Creating archive destination LOG_ARCHIVE_DEST_1: 'G:\ORACLE\ORADATA\ALERTSP\ARCHIVE\ALERTSPT001S19165.DBF'
ARC1: Completed archiving log 4 thread 1 sequence 19165
Fri Nov 23 13:06:08 2007
ARC0: Begin FAL archive (thread 1 sequence 19164 destination T_STANDBYALERTSP)
Creating archive destination LOG_ARCHIVE_DEST_2: 'T_STANDBYALERTSP'
ARC0: Complete FAL archive (thread 1 sequence 19164 destination T_STANDBYALERTSP)
Fri Nov 23 13:06:12 2007
ARC1: Begin FAL archive (thread 1 sequence 19165 destination T_STANDBYALERTSP)
Creating archive destination LOG_ARCHIVE_DEST_2: 'T_STANDBYALERTSP'
ARC1: Complete FAL archive (thread 1 sequence 19165 destination T_STANDBYALERTSP)
could some one let me know the difference between specifying alter database and not specifying alter database???

There's no difference, two ways to reach the same target. 'Recover' (without alter database) is listed as pure sqlplus statement and 'alter database recover' an option of the 'alter database' statement.
Werner

Physical standby database fail-over

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

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

Recovering Physical Standby Database

Similar Messages

Maybe you are looking for