Physical Standby DB - failover setup

Can you please help me with the following questions:
1. XELUSP1 is Production database, XELUSS1 is physical standby database for XELUSP1. During XELUSP1 crash, we brought up XELUSS1 as primary database manually. Post XELUSP1 is back to primary, Can we use XELUSS1 as standby database as it was?
2. What are the steps to be done in order to make XELUSS1 as primary during failover scenario from XELUSP1?
3.What is the impact in client/server environment in 1st case? How it can be fixed?

Hi,
1.No, u can't use it again in case of failover but this thing is possible in switchover mode.
2.diff commands for diff oracle version.tell me on which version u want to perform it.
3.littile downtime when role of server becomes changing.
Thanks
Kuljeet

Similar Messages

Physical standby on 9.2 failover fails

Hello,
I have setup physical standby database and it seems to be transferring data correctly. I tested it also be going into read only mode and querying for changes.
My problem is attempting to do a failover. I simply disconnect the primary to simulate the outtage and attempt to bring secondary by doing the following. Note that I tried both commit to switchover and activate standby.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
Database altered.
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
ALTER DATABASE ACTIVATE STANDBY DATABASE
ERROR at line 1:
ORA-00261: log 4 of thread 1 is being archived or modified
ORA-00312: online log 4 thread 1: '/u02/oradata/digidsgn/stdby_redo04a.log'
ORA-00312: online log 4 thread 1: '/u03/oradata/digidsgn/stdby_redo04b.log'
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
2 ;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
ERROR at line 1:
ORA-16139: media recovery required
The log transfer method is by LGWR...
LOG_ARCHIVE_DEST_2='SERVICE=DIGIDSGN.STBY LGWR ASYNC NOAFFIRM'
Primary database is in MAXIMIZE PERFORMANCE mode.
What am I doing wrong? I do have standby logs created, on standby the names are different from the primary ones.
Another question:
Is the switchover/failover operation suppose to create a normal control file and normal redo logs automatically?
thanks.

Well, this is gonna sound crazy, but I did a fair amount of digging and realized that I couldn't re-select my system disk as my startup disk as well (Error message said "Building boot caches on boot helper partition failed"). I was thinking the installer was trying to modify some settings on my boot volume and couldn't figure out what volume my boot volume really was.
I thought this issue and the update installer issue was related based on something in the iTunes error log looking for "Volumes/Boot OS X".
I figured if I could fix the Startup Disk issue, the other issue would be fixed as well. So I decided to poke around and figure out why I couldn't select my boot volume in the Startup Disk Preference Pane and found these instructions:
Create a new files in Terminal using this command:
*sudo nano /Library/Preferences/SystemConfiguration/com.apple.Boot.plist*
In that file, inserted the default code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://
www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string></string>
</dict>
</plist>
Once that file was created with the proper contents, I went back to the Startup Disk Preference Pane and could select my system disk.
At that point I attempted to install the Trackpad/Magic Trackpad Updater... and it worked! HA! Then I tried iTunes... and success was found there as well.
Hope you have the same luck that I did...
Cheers,
Sapridyne

Data Guard Physical Standby Failover

I need clarification on Physical Standby Failovers. Say I have a Primary db (A) and a physical standby (B), (A) fails and (B) is now the primary, can (A) be setup to become a standby of (B)? I've read 2 different statements in Oracle 10g Data Guard Concepts and Admin
"During failovers involving a physical standby database: In all cases, after a failover, the original primary database can no longer participate in the Data Guard configuration."
vice
"After a fast-start failover occurs, the old primary database will automatically reconfigure itself as a new standby database upon reconnection to the configuration."
Much thanks.

In all cases, after a failover, the original primary database can no longer participate in the Data Guard configuration.
TRUE ! But this doesn't mean that you cannot make your failed primary a new standby database !.
You can achieve this using FLASHBACK DATABASE option:
From the documentation:
After a failover occurs, the original primary database can no longer participate in the Data Guard configuration until it is repaired and established as a standby database in the new configuration. To do this, you can use the Flashback Database feature to recover the failed primary database to a point in time before the failover occurred, and then convert it into a physical or logical standby database in the new configuration.
Read the following documents:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/role_management.htm#sthref995
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/scenarios.htm#i1049997
In addition to this I'd like to mention that you can achieve the same with doing an incomplete recovery instead of using FLASHBACK DATABASE.
"After a fast-start failover occurs, the old primary database will automatically reconfigure itself as a new standby database upon reconnection to the configuration."
TRUE. If you enable Fast-Start Failover:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14230/sofo.htm#CHDDFFEC
Cheers!

Status of Logical Standby In case of Failover to Physical Standby

I am using oracle 9.2.0.8 database . I have one logical and one physical standby database in place. If I perform failover to my physical standby, will my logical standby still continue to work with new primary database?

Thank you for your kind reply.
I performed failover to my physical standby and now archives are going on my logical standby from new primary but changes are not getting applied on my logical standby database.
when i tried to register the logical logfile from new primary on my logical standby i am getting following error.
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 'E:\orcl1\stdb\archives\TESTDBT001S00001.ARC';
ALTER DATABASE REGISTER LOGICAL LOGFILE 'E:\orcl1\stdb\archives\TESTDBT001S00001.ARC'
ERROR at line 1:
ORA-01287: file is from a different database incarnation

Failover To Physical Standby Database

We have 3 node RAC 11.2.0.3 Primary database data guarded to a 3 node RAC 11.2.0.3 Standby database. There is an activity scheduled to perform some of order extracts in the database which is going to result in a lot of changes. Currently the discussion is on whether what should be the quickest way to go back to a point in time before the extract process starts in case of any issues. The options that we are looking at are:
1) Create a guaranteed restore point on both the Primary and Standby and use this to flashback the database (Quick but we have had issues where in the guaranteed restore point still does not guarantee the availability of the flashback logs) - Tested
2) Use RMAN backup from a day before to restore and recover to point in time before the extract process began (Time consuming) - Tested
3) Use export backup to perform a redirected restore i.e import the data from before the extract process (Time consuming) - Tested
4) Create a guaranteed restore point on both Primary and Standby, stop the Redo Apply/Ship at the time we create the guaranteed restore point and at a point we face some issue and need to go back, simply failover to the physical standby database and then reinstate the new standby database - This has not been tested yet but seems a viable option
With regard to the point 4, note that we are not concerned about data loss as the whole point of stopping the redo apply is to prevent the standby to be caught up with Primary during the run of the extract process. The question is whether the dataguard broker will allow failover of the primary to standby, in a situation described in bullet point 4). Please advice.

HI,
Please check this link:
Physical Standby Database SWITCHOVER &amp; FAILOVER Operations | Talip Hakan Ozturk&#039;s ORACLE BLOG
Thank you

Failover to Physical Standby

Hi All,
I have a configured data guard in my local system . Please find the below configuration of the Data guard
Data Guard Type : - Physical Standby (Oracle version 11g)
Service Responsible for Log Transport : - ARCH
No Standby Redo log : - Neither in Primary Nor in Standby
I am trying to fail over by using command "alter database recover managed standby database finish"
Please find the below alert log info after this command .
Tue Dec 03 01:42:14 2013
alter database recover managed standby database finish
Attempt to do a Terminal Recovery (PRD)
Media Recovery Start: Managed Standby Recovery (PRD)
Fast Parallel Media Recovery enabled
Managed Standby Recovery not using Real Time Apply
Media Recovery Waiting for thread 1 sequence 145
Terminal Recovery timestamp is '12/03/2013 01:42:15'
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 145 redo required
Media Recovery Waiting for thread 1 sequence 145
Terminal Recovery: End-Of-Redo log allocation
Terminal Recovery: standby redo logfile 3 created '/data/PRD_DR/arch/arch_1_0_831359165.arch'
This standby redo logfile is being created as part of the failover
operation. This standby redo logfile should be deleted after the
switchover to primary operation completes.
Media Recovery Log /data/PRD_DR/arch/arch_1_0_831359165.arch
Terminal Recovery: log 3 reserved for thread 1 sequence 145
Recovery of Online Redo Log: Thread 1 Group 3 Seq 145 Reading mem 0
Mem# 0: /data/PRD_DR/arch/arch_1_0_831359165.arch
Identified End-Of-Redo for thread 1 sequence 145
Incomplete recovery applied all redo ever generated.
Recovery completed through change 559773 time 11/23/2013 13:38:13
Media Recovery Complete (PRD)
Terminal Recovery: successful completion
Resetting standby activation ID 1895332757 (0x70f87b95)
Completed: alter database recover managed standby database finish
Tue Dec 03 01:42:50 2013
alter database commit to switchover to primary
ALTER DATABASE SWITCHOVER TO PRIMARY (PRD)
Maximum wait for role transition is 15 minutes.
Backup controlfile written to trace file /apps/oracle/diag/rdbms/stand/PRD/trace/PRD_ora_9466.trc
tkcrrxms: Killing 3 processes (all RFS)
Standby terminal recovery start SCN: 559772
RESETLOGS after complete recovery through change 559773
Online log /data/PRD_DR/REDOLOG11.LOG: Thread 1 Group 1 was previously cleared
Online log /data/PRD_DR/REDOLOG21.LOG: Thread 1 Group 2 was previously cleared
Standby became primary SCN: 559771
Tue Dec 03 01:42:53 2013
Here my question is , why oracle implicitly creates a standby redo log in Standby database for successful completion of 'alter database recover managed standby database finish'.
Thanks,

Terminal Recovery timestamp is '12/03/2013 01:42:15'
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 145 redo required
Media Recovery Waiting for thread 1 sequence 145
Terminal Recovery: End-Of-Redo log allocation
Terminal Recovery: standby redo logfile 3 created '/data/PRD_DR/arch/arch_1_0_831359165.arch'
This standby redo logfile is being created as part of the failover
operation. This standby redo logfile should be deleted after the
switchover to primary operation completes.
Media Recovery Log /data/PRD_DR/arch/arch_1_0_831359165.arch
Terminal Recovery: log 3 reserved for thread 1 sequence 145
Recovery of Online Redo Log: Thread 1 Group 3 Seq 145 Reading mem 0
Mem# 0: /data/PRD_DR/arch/arch_1_0_831359165.arch
Identified End-Of-Redo for thread 1 sequence 145
Looks like, its due to the following bug.
Bug 5889025 : FINISH FAILOVER GENERATES INCORRECT STANDBY REDO LOG.

Switchover/Failover to physical standby

Hi All,
I have dataguard configured between Primary and physical standby. I would like to know how can i switch over to physical stanby when the network link is down between primary and physical standby.
I mean what steps I can follow to make physical standby to primary and primary to staandby even when the network connectivity is down between them.
Regards,
Raj

user12263161 wrote:
Hi All,
I have dataguard configured between Primary and physical standby. I would like to know how can i switch over to physical stanby when the network link is down between primary and physical standby. You can only failover in this case, but, if you have flashback on, you can reinstate ex-Primary to standby like described [url http://nikolayivankin.wordpress.com/2012/02/14/dgmgrl-reinstating-ex-primary-to-standby-by-flashback-database-feature/]here

Data Guard - Physical Standby Setup by RMAN

I am trying to set up a physical standby using RMAN. After I brought up the standby db, I failed to turn on redo apply. I found out that the standby redo log files were not copied over to the standby.
The back up script I use is as follows.
run {
allocate channel ch2 type disk;
backup current controlfile for standby format '/backups/sitv/cf_%d_t%t_s%s_p%p';
backup format '/backups/sitv/%U.bkup' database;
sql 'alter system archive log current';
backup format '/backups/sitv/al_t%t_s%s_p%p.bkup' archivelog all;
release channel ch2;
What command should I use to be able to make a backup of the standby log files as well?
Thanks.

Hi Sybrand,
Thank for the reply. Let me give a little bit more detailed information on what I did.
I followed the documentation as follows to set up the physical standby
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/create_ps.htm#g88234
I created the standby log files per section 3.1.3 on the primary db before the standby is created.
I used the following command to restore the standby on a different server.
run {
allocate auxiliary channel ch1 device type disk;
duplicate target database for standby dorecover nofilenamecheck;}
My question is the standby log files did not show up on the standby server. However, the log files showed in the v$logfile table. After I tured on the redo apply, the changes I made in primary db did not happen in the standby db.
Any idea on how to fix it?
Thanks.

Step by step 10g Dataguard , physical standby database setup metalink notes

On metalink i saw this note, but unable to find now if someone can help....

Note:248382.1 Creating a 10g Data Guard Physical Standby on Linux

Problems while creating a physical Standby

Hi,
I am trying to setup a physical standby database with oracle 10g.
I configured a specific log archive destination:
LOG_ARCHIVE_DEST_3 = 'SERVICE=ORAMPSEC REOPEN=60 MAX_FAILURE=3 LGWR SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORAMPSEC'
The service is reachable via network.
To establish the standby database I copied all datafiles from the primary database using scp. I also created a standby controlfile and a modified pfile. In addition I added a standby redo logfile which has the same size as the online redo log files on the primary database.
After starting the standby database in open read only mode I receive the following error message:
Database mounted.
ORA-16004: backup database requires recovery
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oradata/ORAMPPRD/data/system01.dbf'
I tried to recover using "recover standby database" I receive the following message:
ORA-00279: change 884348 generated at 07/18/2006 17:08:07 needed for thread 1
ORA-00289: suggestion : /oradata/ORAMPPRD/archive/1_30_595767954.dbf
ORA-00280: change 884348 for thread 1 is in sequence #30
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Although I transmitted all archived log files from the primary database the archived log file mentioned above is not available. After hitting RETURN I get this message:
ORA-00308: cannot open archived log
'/oradata/ORAMPPRD/archive/1_30_595767954.dbf'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oradata/ORAMPPRD/data/system01.dbf'
Here is a listing of all archived logfiles from the primary database:
bash-3.00$ ls -latr
total 494144
drwxr-xr-x 6 oracle oinstall 512 Jul 14 11:03 ..
-rw-r----- 1 oracle oinstall 20732928 Jul 17 11:47 1_6_595767954.dbf
-rw-r----- 1 oracle oinstall 86013440 Jul 17 13:56 1_7_595767954.dbf
-rw-r----- 1 oracle oinstall 214016 Jul 17 13:57 1_8_595767954.dbf
-rw-r----- 1 oracle oinstall 1986560 Jul 17 14:10 1_9_595767954.dbf
-rw-r----- 1 oracle oinstall 150016 Jul 17 14:10 1_10_595767954.dbf
-rw-r----- 1 oracle oinstall 504320 Jul 17 14:17 1_11_595767954.dbf
-rw-r----- 1 oracle oinstall 1807872 Jul 17 14:22 1_12_595767954.dbf
-rw-r----- 1 oracle oinstall 589824 Jul 17 14:25 1_13_595767954.dbf
-rw-r----- 1 oracle oinstall 1190912 Jul 17 14:37 1_14_595767954.dbf
-rw-r----- 1 oracle oinstall 584704 Jul 17 14:42 1_15_595767954.dbf
-rw-r----- 1 oracle oinstall 80896 Jul 17 14:45 1_16_595767954.dbf
-rw-r----- 1 oracle oinstall 6050816 Jul 17 15:08 1_17_595767954.dbf
-rw-r----- 1 oracle oinstall 4238848 Jul 17 16:04 1_18_595767954.dbf
-rw-r----- 1 oracle oinstall 4920832 Jul 17 17:21 1_19_595767954.dbf
-rw-r----- 1 oracle oinstall 1520128 Jul 17 17:30 1_20_595767954.dbf
-rw-r----- 1 oracle oinstall 360960 Jul 17 17:35 1_21_595767954.dbf
-rw-r----- 1 oracle oinstall 89186304 Jul 18 10:52
1_22_595767954.dbf
-rw-r----- 1 oracle oinstall 16216576 Jul 18 14:18
1_23_595767954.dbf
-rw-r----- 1 oracle oinstall 12288 Jul 18 14:18 1_24_595767954.dbf
-rw-r--r-- 1 oracle oinstall 2073 Jul 18 14:26 sqlnet.log
-rw-r----- 1 oracle oinstall 14387200 Jul 18 16:56
1_25_595767954.dbf
-rw-r----- 1 oracle oinstall 116736 Jul 18 16:58 1_26_595767954.dbf
-rw-r----- 1 oracle oinstall 1536000 Jul 18 17:04 1_27_595767954.dbf
-rw-r----- 1 oracle oinstall 156672 Jul 18 17:05 1_28_595767954.dbf
drwxr-xr-x 2 oracle oinstall 1024 Jul 18 17:08 .
-rw-r----- 1 oracle oinstall 65536 Jul 18 17:08 1_29_595767954.dbf
Nothing known about the *30*dbf file.
Although there still seems to be something wrong, the archived log file transmission seems to work since there is no error reported on the log archive destination:
SQL> select status, error from v$archive_dest where dest_id = 3;
STATUS ERROR
VALID
And after I manually force a log switch I see that archived redo logs were applied on the standby database:
select sequence#, applied from v$archived_log order by sequence#;
SEQUENCE# APPLIED
27 YES
28 NO
28 YES
29 NO
29 YES
Unfortunately because of the recovering problem I cannot open the database to see if the changes were applied. So my first question is, how can I get the standby database completely recovered ??
In addition to this I was expecting that the changes to the standby database were made immediately since I choosed LGWR sync but I have to manually force the logfile switch. As I already mentioned a standby redo log file is available as well.
Thanks for your help,
Philipp.

Hi,
since it does not seem to work with just copying the datafiles I switched to RMAN. I created a full database backup from Enterprise Manager. Similiar to http://dizwell.com/main/content/view/81/122/1/1/ I tried to duplicate the database to the standby instance (running on a different server). But unfortunately I receive error messages that the files, previously created, cannot be found:
channel d1: starting datafile backupset restore channel d1: specifying datafile(s) to restore from backup set restoring datafile 00001 to /oradata/ORAMPPRD/data/1.dbf restoring datafile 00002 to /oradata/ORAMPPRD/data/2.dbf restoring datafile 00003 to /oradata/ORAMPPRD/data/3.dbf restoring datafile 00004 to /oradata/ORAMPPRD/data/4.dbf channel d1: reading from backup piece /opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1
ORA-19870: error reading backup
piece /opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1
ORA-19505: failed to identify file
"/opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory Additional information: 3 failover to previous backup
But when I crosscheck my backup inside RMAN it clearly shows the backup files:
RMAN> crosscheck backup;
backup piece
handle=/opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1 recid=7
stamp=596207811
crosschecked backup piece: found to be 'AVAILABLE'
I already checked the file permissions, everybody on the system is able to access this file.
Do you know what is going wrong here ??
Cheers,
Philipp.

Physical standby database in RAC system

Hi EXperts,
We have a 4 nodes 11.2 cluster system. i will set a data guard as a disaster recovery mothods.
As a physical standby database set, does we need to configure same nodes (4 nodes) in other city as primary database cluster system?
Can we set physical standby database is in 2 nodes cluster system and primary database is in 4 nodes cluster system?
Thanks explaining!
Jin

Can we set physical standby database is in 2 nodes cluster system and primary database is in 4 nodes cluster system?Yes. You can setup 2 node RAC as physical standby and also with different memory parameters. But, the only issue is when DB failover from primary to standby, the applications connect to 2 node RAC in place of 4 node RAC and may be overloaded.

Standby database failover flashback restart as standby gap 1-100

Hi,
I have setup a physical standby database for a 3 node RAC primary database and configured the database to run in MAXIMUM AVAILABILITY mode. Both the primary and standby databases use ASM for managing the IO. I have enabled FLASHBACK ON on both the databases.
I did failover to standby database with primary db SHUTDOWN for doing some testing. After testing is done, I flashbacked the (standby, currently primary)database to the point when it became primary and start it as standby again and the old primary as primary.
Following are the steps:
Failover steps
.Shutdown the primary database
To finisish the recovery at standby
SQL>alter database recover managed standby database finish;
To start as primary
SQL>alter database commit to switchover to primary;
do some DML on the new primary
SQL>flashback database to scn <standby_became_primary_scn>;
SQL>alter database create standby controlfile as '/backup/standby.ctl';
Changed the spfile to point control_files to '/backup/standby.ctl';
Restarted the standby db in mount mode and
created the required stanbdy logs on it.
Then issued
SQL>alter database recover managed standby database using current logfile disconnect;
I have the following message in v$dataguard_status at standby db;
Fetching gap sequence in thread 1 branch(resetlogs_id) 653234404, gap seq 1-100
DBID 2651011616 branch 653234404
GAP - thread 1 sequence 1-100
FAL[client]: Failed to request gap sequence
FAL[client]: All defined FAL servers have been attempted.
The same error is found in alert log file also.
The status of the varioud managed standby db are as follows.
SQL> select process, status from v$managed_standby;
PROCESS STATUS
ARCH CLOSING
ARCH CLOSING
ARCH CLOSING
MRP0 WAIT_FOR_GAP
RFS IDLE
RFS IDLE
RFS IDLE
RFS IDLE
RFS IDLE
RFS IDLE
RFS IDLE
PROCESS STATUS
RFS IDLE
RFS IDLE
RFS IDLE
RFS IDLE
15 rows selected.
SQL>
Could you please help me how to resolve the above error.
Thanks,
Sreekanth

Sreekanth,
I think your steps are right on for your requirement, except instead of
alter database create standby controlfile as '/backup/standby.ctl';
you can do this:
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
(although perhaps it achieves the same thing internally but you don't need to repoint to new controlfile).
So far as the GAP - thread 1 sequence 1-100
Let me guess, your current sequences are probably well ahead of this reported gap?
If so, this is a bogus gap in a sense that your standby has long ago applied them, but for some reason standby controlfile gets a little confused and starts asking for them again.
I have had this issue and opened multiple TAR's with Oracle since 10.2.0.1, got a few patches and advises to upgrade, but still occasionally get it now in 10.2.0.3
I strongly believe this is related to combination of RAC (i.e. multiple threads of redo) and dataguard.
It is also pretty hard to reproduce (I have not figured out how to reproduce this reliably, if you have, let me know), so I can understand why Oracle has so far been unable to fix this.
Anyway, the workaround is to re-create standby controlfile with a copy generated on primary, and move it in place of the existing (and confused) controlfiles on standby.

Oracle DataGuard - Standy Redo log on physical Standby db

Hello Guys,
A quick question on my 10.2.0.2 db with Windows 2003 x64 OSs.
I have 2 machines - One for primary & the other for physical standby
I have successfully setup DG with Real Time Apply and also tested switchover & failover scenarios and they work well and as expected...
But I have a query which popped up when I was trying to set this up at home.
I create the physical standby db by shutting the primary db and copying all the datafiles, tempfiles,online redo logs and then creating a standby control file which will be used for the physical standby db to start off with.
After mounting the standby db, I tried to create standby redo logs files starting with Group 4 but I got error that standby group 4 already exists.
Upon querying v$logfile view, I noticed that the standby redo logs that I created on primary are also showing up on the standby db which I understand is from the standby control file.
So here is my quesiton: What is correct method of creating these standby redo logs on the standby database?
I know that I could drop those 4 standby redo logs from the standby db and recreate them but all the DG docs online and the documents that I have referred say that I should create the standby redo logs on the standby as I did on the primary but how can this duplication be avoided i.e. from the standby control file?
I know that I could use another method to create a hot backup such as RMAN etc...but I wanted to follow this way of shutting down the primary and copy the relevant database files.
Any help appreciated...and thanks in advance guys!
-Bharath

so with the setup that I used, i.e. create a standby control file which contains info about the standby redo logs at the primary site, should I also copy over the standby redo logs from the primary to standby as I only copied the datafiles, tempfile(s) & online redo logs? But then the filenames of the standby redo logs will be the exact same as that of the primary. Will that cause any issue during a switchover/failover?
I don't remember exactly how I did it when I got the whole thing working but I have a vague remembrance that I drop the std. redo log files entries from the std database and then recreate new ones with different filenames (as compared to primary).
Thanks

About Data Guard - Physical Standby Database

Dear All,
I have read many documents regading Data Guard.
I am about to setup Data Guard in our current environment but want to clear few tings.
I have a confusion between physical and logical standby database.
What I have read from different documents is:
-Physical Standby Database in (11g)
1) It is the most efFicient
2) I can be either in mount or open state
3) Select queries and reporting can be done to improve performance of the primary database.
4) Schema on primary and standby database is always the same
-- Logical Standby Database
1) You can create additional tables, indexes, etc.
2) Always in open mode
3) Select queries and reporting can be done to improve performance of the primary database
Now our scenerio is, that we have one server at the moment, OS is linux and operating system is 11g. We want to setup an other server in another country, will also be 11g on Linux in a way that it acts as standby/backup server. Schema and data is always the same. In case due to unavailability of primary server, standby server acts as the primary server (This has to be automated). The reason for unavailability could be any like maintenance work on primary server, network or hardware failure at primary server. The last and the most important thing is that users from this country where we will setup standby database will insert/update data on the primary server BUT queries and reporting will be done from this newly created standby data.
Kindly recomend the best Data Guard in this scenerio and kindly correct me where I am wrong.
Thanks, Imran

A logical standby has various limitations on things like data types. It's also a much more complex architecture, which makes it more likely that something will break periodically and require attention. Applying redo to a physical standby is code that has been around forever and is as close to bullet-proof as you'll get. And you would generally prefer to fail over to a physical standby-- if you do things like create new objects in the logical standby, you may have to get rid of those objects during a failover to get acceptable OLTP performance.
Justin

Avoid read-only access at physical standby

Hi!
DB=11.2.0.2
when I start the standby with
SQL> startup
the db is open read-only.
Is there a way to configure the db so that startup command only mounts the db and start redo apply?
this is the config:
DGMGRL> show configuration verbose;
Configuration - w
Protection Mode: MaxPerformance
Databases:
w_01 - Primary database
w_02 - (*) Physical standby database
(*) Fast-Start Failover target
Properties:
FastStartFailoverThreshold = '30'
OperationTimeout = '30'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
Fast-Start Failover: ENABLED
Threshold: 30 seconds
Target: w_02
Observer: ora
Lag Limit: 30 seconds
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Configuration Status:
SUCCESS
DGMGRL> show database w_02
Database - w_02
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: OFF
Instance(s):
w
Database Status:
SUCCESS
br
Daniel

If Data Guard is setup correctly the application is not losing data, you cannot read from it, but it will apply logs:
Ex.
/home/oracle:STANDBY >sqlplus "/ as sysdba"
SQL> select * from BIGSHOW.CUSTOMER;
select * from BIGSHOW.CUSTOMER
ERROR at line 1:
ORA-01219: database not open: queries allowed on fixed tables/views only
So even as the SYS user I cannot read from my test user's tables.
ORA-01219 is expected when the standby is in this state.
You can open READ ONLY if you have Active Data Guard, but generally that will cost you extra.
OR, you can do thing to check your data:
To open a standby database for read-only access when it is currently performing managed recovery:
Cancel log apply services:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Open the database for read-only access:
SQL> ALTER DATABASE OPEN READ ONLY;
At some point you have start the recovery again, you probably don't have an issue.
If you want more peace of mind on this you have to setup a test Data Guard system and bang on it.
Best Regards
mseberg

Physical Standby DB - failover setup

Similar Messages

Maybe you are looking for