Primary database switchover problem

I am getting the following error when i execute 'alter database commit to switchover to standby with session shutdown' in primary database
ora-16416 no viable physical standby switchover targets available
What may be the reason???
I am using Oracle Server-Standard Edition 11g R2
version: 11.2.0.1

Hello Gurus,
I did a switchover and then performed a reverse switchover again. So Primary(original) is Primary now and My Standby(original) is Standby now.
The Problem is when I monitor the Logs Archived and Applied I noticed below:
In PRIMARY SIDE
NAME ARC APPLIED SEQUENCE# DEST_ID
D:\EDRIVE\PRIMARY\ARC\1_55_815075358.ARC YES YES 55 1
D:\EDRIVE\PRIMARY\ARC\1_56_815075358.ARC YES YES 56 1
STANDBY YES YES 56 2
STANDBY YES YES 55 2
STANDBY YES YES 54 2
STANDBY YES YES 53 2
STANDBY YES YES 52 2
STANDBY YES YES 50 2
STANDBY YES YES 51 2
STANDBY YES YES 57 2
D:\EDRIVE\PRIMARY\ARC\1_57_815075358.ARC YES YES 57 1
D:\EDRIVE\PRIMARY\ARC\1_58_815075358.ARC YES YES 58 1
STANDBY YES YES 58 2
STANDBY YES YES 59 2
D:\EDRIVE\PRIMARY\ARC\1_59_815075358.ARC YES YES 59 1
STANDBY YES YES 60 2
D:\EDRIVE\PRIMARY\ARC\1_60_815075358.ARC YES YES 60 1
STANDBY YES YES 61 2
D:\EDRIVE\PRIMARY\ARC\1_61_815075358.ARC YES YES 61 1
STANDBY YES YES 62 2
D:\EDRIVE\PRIMARY\ARC\1_62_815075358.ARC YES YES 62 1
D:\EDRIVE\PRIMARY\ARC\1_63_815075358.ARC YES YES 63 1
STANDBY YES YES 63 2
D:\EDRIVE\PRIMARY\ARC\1_64_815075358.ARC YES YES 64 1
D:\EDRIVE\PRIMARY\ARC\1_65_815075358.ARC YES YES 65 1
D:\EDRIVE\PRIMARY\ARC\1_66_815075358.ARC YES YES 66 1
D:\EDRIVE\PRIMARY\ARC\1_67_815075358.ARC YES YES 67 1
D:\EDRIVE\PRIMARY\ARC\1_68_815075358.ARC YES YES 68 1
D:\EDRIVE\PRIMARY\ARC\1_69_815075358.ARC YES NO 69 1
STANDBY YES YES 69 2
D:\EDRIVE\PRIMARY\ARC\1_70_815075358.ARC YES NO 70 1
STANDBY YES YES 70 2
D:\EDRIVE\PRIMARY\ARC\1_71_815075358.ARC YES NO 71 1
STANDBY YES YES 71 2
STANDBY YES YES 72 2
D:\EDRIVE\PRIMARY\ARC\1_72_815075358.ARC YES NO 72 1
D:\EDRIVE\PRIMARY\ARC\1_73_815075358.ARC YES NO 73 1
STANDBY YES YES 73 2
D:\EDRIVE\PRIMARY\ARC\1_74_815075358.ARC YES NO 74 1
STANDBY YES YES 74 2
D:\EDRIVE\PRIMARY\ARC\1_75_815075358.ARC YES NO 75 1
STANDBY YES YES 75 2
STANDBY YES YES 76 2
D:\EDRIVE\PRIMARY\ARC\1_76_815075358.ARC YES NO 76 1
D:\EDRIVE\PRIMARY\ARC\1_77_815075358.ARC YES NO 77 1
STANDBY YES YES 77 2
In STANDBY SIDE
NAME ARC APPLIED SEQUENCE#
D:\EDRIVE\STANDBY\ARC\1_55_815075358.ARC YES YES 55
D:\EDRIVE\STANDBY\ARC\1_54_815075358.ARC YES YES 54
D:\EDRIVE\STANDBY\ARC\1_53_815075358.ARC YES YES 53
D:\EDRIVE\STANDBY\ARC\1_52_815075358.ARC YES YES 52
D:\EDRIVE\STANDBY\ARC\1_50_815075358.ARC YES YES 50
D:\EDRIVE\STANDBY\ARC\1_51_815075358.ARC YES YES 51
D:\EDRIVE\STANDBY\ARC\1_56_815075358.ARC YES YES 56
D:\EDRIVE\STANDBY\ARC\1_57_815075358.ARC YES YES 57
D:\EDRIVE\STANDBY\ARC\1_58_815075358.ARC YES YES 58
D:\EDRIVE\STANDBY\ARC\1_59_815075358.ARC YES YES 59
D:\EDRIVE\STANDBY\ARC\1_60_815075358.ARC YES YES 60
D:\EDRIVE\STANDBY\ARC\1_61_815075358.ARC YES YES 61
D:\EDRIVE\STANDBY\ARC\1_62_815075358.ARC YES YES 62
D:\EDRIVE\STANDBY\ARC\1_63_815075358.ARC YES YES 63
D:\EDRIVE\STANDBY\ARC\1_64_815075358.ARC YES YES 64
D:\EDRIVE\STANDBY\ARC\1_65_815075358.ARC YES YES 65
PRIMARY YES YES 64
PRIMARY YES YES 65
D:\EDRIVE\STANDBY\ARC\1_66_815075358.ARC YES YES 66
PRIMARY YES YES 66
PRIMARY YES NO 67
D:\EDRIVE\STANDBY\ARC\1_67_815075358.ARC YES YES 67
D:\EDRIVE\STANDBY\ARC\1_68_815075358.ARC YES YES 68
PRIMARY YES NO 68
D:\EDRIVE\STANDBY\ARC\1_69_815075358.ARC YES YES 69
D:\EDRIVE\STANDBY\ARC\1_70_815075358.ARC YES YES 70
D:\EDRIVE\STANDBY\ARC\1_71_815075358.ARC YES YES 71
D:\EDRIVE\STANDBY\ARC\1_72_815075358.ARC YES YES 72
D:\EDRIVE\STANDBY\ARC\1_1_815506630.ARC YES NO 1
D:\EDRIVE\STANDBY\ARC\1_73_815075358.ARC YES YES 73
D:\EDRIVE\STANDBY\ARC\1_74_815075358.ARC YES YES 74
D:\EDRIVE\STANDBY\ARC\1_75_815075358.ARC YES YES 75
D:\EDRIVE\STANDBY\ARC\1_76_815075358.ARC YES YES 76
D:\EDRIVE\STANDBY\ARC\1_77_815075358.ARC YES YES 77
I wonder why in Some cases it is coming as APPLIED=NO and both the Primary and Standby.
Also in Standby D:\EDRIVE\STANDBY\ARC\1_1_815506630.ARC YES NO 1 why sequence number 1 is gerenarated an not applied any where?
Could any one of you please help me to know this?
-Regards,
Saha

Similar Messages

Switchover problem after upgrade from 11.2.0.1 to 11.2.0.2

Hello
I succesfull upgraded my database from 11.2.0.1 to 11.2.0.2 on my test enviroment.
My enviroment works with dataguard configuration.
Data Guard management is dgmgrl.
OS is Linux Redhat x86_64
I have problem with switchover operation:
During switchover operation (with dgmgrl) new primary database is switched succesfull but problem is with new standby database, I have message:
ORA-10458: standby database requires recovery
ORA-01194: datafile 1, needs more recovery to be consistent
ORA-01110: datafile 1: '/u01/app/oracle/oradata/DB1/system01.dbf'
To end switchover operation I should start new standby instance. But if i try startup It i have:
ORA-00845: MEMORY_TARGET not supported on this system
In alert log new standby database I have:
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN
Wed Jan 19 08:15:00 2011
Performing implicit shutdown abort due to switchover to physical standby
Shutting down instance (abort)
License high water mark = 20
USER (ospid: 13290): terminating the instance
Instance terminated by USER, pid = 13290
Wed Jan 19 08:15:02 2011
Instance shutdown complete
ORA-1092 : opitsk aborting process
Wed Jan 19 08:15:06 2011
Starting ORACLE instance (normal)
WARNING! Recovering data file 1 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 2 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 3 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 4 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command..
ARC9: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Media Recovery Log /u01/app/oracle/redologs2/archiveredolog/DB1/1_194_739556401.dbf
Identified End-Of-Redo for thread 1 sequence 194
Wed Jan 19 08:15:20 2011
Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/oradata/DB1/archivelog/
RFS[1]: Assigned to RFS process 13553
RFS[1]: Identified database type as 'physical standby': Client is ARCH pid 3536
Starting Data Guard Broker (DMON)
Wed Jan 19 08:15:21 2011
INSV started with pid=32, OS id=13555
RFS[1]: Selected log 4 for thread 1 sequence 197 dbid 1279411810 branch 739556401
Archived Log entry 44349 added for thread 1 sequence 197 ID 0x4f8d3d29 dest 1:
Archived Log entry 44350 added for thread 1 sequence 197 ID 0x4f8d3d29 dest 2:
Archived Log entry 44351 added for thread 1 sequence 197 ID 0x4f8d3d29 dest 3:
Wed Jan 19 08:15:24 2011
Resetting standby activation ID 0 (0x0)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Applied until change 972405267
Completed standby crash recovery.
Errors in file /u01/app/oracle/diag/rdbms/tdb1nod1/DB1/trace/DB1_ora_13451.trc:
ORA-10458: standby database requires recovery
ORA-01194: plik 1, aby byl spojny, wymaga dalszego przywracania
ORA-01110: plik danych 1: '/u01/app/oracle/oradata/DB1/system01.dbf'
ORA-10458 signalled during: alter database open...
Wed Jan 19 08:15:25 2011
RFS[2]: Assigned to RFS process 13603
RFS[2]: Identified database type as 'physical standby': Client is ARCH pid 3532
Wed Jan 19 08:15:26 2011
RFS[3]: Assigned to RFS process 13619
RFS[3]: Identified database type as 'physical standby': Client is ARCH pid 3536
RFS[3]: Opened log for thread 1 sequence 196 dbid 1279411810 branch 739556401
Wed Jan 19 08:15:26 2011
RFS[4]: Assigned to RFS process 13617
RFS[4]: Identified database type as 'physical standby': Client is ARCH pid 3534
Archived Log entry 44352 added for thread 1 sequence 196 rlc 739556401 ID 0x4f8d3d29 dest 4:
RFS[4]: Opened log for thread 1 sequence 195 dbid 1279411810 branch 739556401
Archived Log entry 44353 added for thread 1 sequence 195 rlc 739556401 ID 0x4f8d3d29 dest 4:
Wed Jan 19 08:15:29 2011
RFS[5]: Assigned to RFS process 13643
RFS[5]: Identified database type as 'physical standby': Client is LGWR ASYNC pid 7251
Primary database is in MAXIMUM PERFORMANCE mode
RFS[5]: Selected log 4 for thread 1 sequence 199 dbid 1279411810 branch 739556401
Wed Jan 19 08:15:30 2011
RFS[6]: Assigned to RFS process 13645
RFS[6]: Identified database type as 'physical standby': Client is ARCH pid 3536
RFS[6]: Selected log 5 for thread 1 sequence 198 dbid 1279411810 branch 739556401
Wed Jan 19 08:15:31 2011
Archived Log entry 44354 added for thread 1 sequence 198 ID 0x4f8d3d29 dest 1:
Archived Log entry 44355 added for thread 1 sequence 198 ID 0x4f8d3d29 dest 2:
Archived Log entry 44356 added for thread 1 sequence 198 ID 0x4f8d3d29 dest 3:
Wed Jan 19 08:15:45 2011
RFS[7]: Assigned to RFS process 13699
RFS[7]: Identified database type as 'physical standby': Client is ARCH pid 3532
Wed Jan 19 08:16:47 2011
RFS[7]: Assigned to RFS process 13699
RFS[7]: Identified database type as 'physical standby': Client is ARCH pid 3532
Wed Jan 19 08:16:47 2011
Starting ORACLE instance (normal)
WARNING: You are trying to use the MEMORY_TARGET feature. This feature requires the /dev/shm file system to be mounted for at least 2147483648 bytes. /dev/shm is either not mounted or is mounted with available space less than this size. Please fix this so that MEMORY_TARGET can work as expected. Current available is 1586806784 and used is 3781902336 bytes. Ensure that the mount point is /dev/shm for this directory.
memory_target needs larger /dev/shm
Wed Jan 19 08:30:17 2011
db_recovery_file_dest_size of 102400 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
It is look like the instance proseses was not shutdown during operation shutdown abort.
If I connect to instance with sqlplus i have message:
Connected with idle instance
Proceses are still active.
Output linux statement ps -aux | grep oracle:
root 13032 0.0 0.0 88060 3248 ? Ss 08:13 0:00 sshd: oracle [priv]
oracle 13039 0.0 0.0 88060 1860 ? S 08:13 0:00 sshd: oracle@pts/1
oracle 13040 0.0 0.0 68248 1676 pts/1 Ss 08:13 0:00 -bash
oracle 13402 0.0 0.3 2328080 22220 ? Ss 08:15 0:00 ora_pmon_DB1
oracle 13404 0.0 0.2 2325832 15536 ? Ss 08:15 0:00 ora_vktm_DB1
oracle 13408 0.0 0.2 2325832 15584 ? Ss 08:15 0:00 ora_gen0_DB1
oracle 13412 0.0 0.2 2325832 15468 ? Ss 08:15 0:00 ora_diag_DB1
oracle 13414 0.0 0.2 2325832 15584 ? Ss 08:15 0:00 ora_dbrm_DB1
oracle 13416 0.0 0.2 2325832 15680 ? Ss 08:15 0:00 ora_psp0_DB1
oracle 13419 0.1 0.4 2327368 25688 ? Ss 08:15 0:08 ora_dia0_DB1
oracle 13422 0.0 0.8 2325832 49152 ? Ss 08:15 0:02 ora_mman_DB1
oracle 13425 0.0 0.4 2332100 27344 ? Ss 08:15 0:00 ora_dbw0_DB1
oracle 13427 0.0 0.2 2325832 16648 ? Ss 08:15 0:00 ora_lgwr_DB1
oracle 13432 0.0 0.3 2325832 21524 ? Ss 08:15 0:00 ora_ckpt_DB1
oracle 13434 0.0 0.2 2325832 17600 ? Ss 08:15 0:00 ora_smon_DB1
oracle 13436 0.0 0.2 2325832 15604 ? Ss 08:15 0:00 ora_reco_DB1
oracle 13438 0.0 0.4 2326468 27976 ? Ss 08:15 0:00 ora_mmon_DB1
oracle 13440 0.0 0.3 2325832 22120 ? Ss 08:15 0:00 ora_mmnl_DB1
oracle 13442 0.0 0.2 2331932 15764 ? Ss 08:15 0:00 ora_d000_DB1
oracle 13444 0.0 0.2 2326896 14784 ? Ss 08:15 0:00 ora_s000_DB1
oracle 13447 0.0 0.2 2325852 16628 ? Ss 08:15 0:00 ora_dmon_DB1
oracle 13527 0.0 0.8 2357896 48984 ? Ss 08:15 0:00 ora_arc0_DB1
oracle 13530 0.0 0.5 2341496 31832 ? Ss 08:15 0:00 ora_arc1_DB1
oracle 13532 0.0 0.8 2359596 50968 ? Ss 08:15 0:00 ora_arc2_DB1
oracle 13534 0.0 0.7 2357896 48844 ? Ss 08:15 0:00 ora_arc3_DB1
oracle 13536 0.0 0.8 2357896 48860 ? Ss 08:15 0:00 ora_arc4_DB1
oracle 13538 0.0 0.5 2341384 31524 ? Ss 08:15 0:00 ora_arc5_DB1
oracle 13540 0.0 0.5 2341384 31536 ? Ss 08:15 0:00 ora_arc6_DB1
oracle 13542 0.0 0.5 2341384 31536 ? Ss 08:15 0:00 ora_arc7_DB1
oracle 13545 0.0 0.5 2341384 31536 ? Ss 08:15 0:00 ora_arc8_DB1
oracle 13547 0.0 0.5 2341384 31536 ? Ss 08:15 0:00 ora_arc9_DB1
oracle 13555 0.0 0.2 2325852 16168 ? Ss 08:15 0:00 ora_insv_DB1
root 18288 0.0 0.0 88060 3240 ? Ss 08:30 0:00 sshd: oracle [priv]
oracle 18290 0.0 0.0 88200 2012 ? S 08:30 0:00 sshd: oracle@notty
oracle 18291 0.0 0.0 54004 2232 ? Ss 08:30 0:00 /usr/libexec/openssh/sftp-server
oracle 18336 0.0 0.2 87132 13336 ? Ssl 08:41 0:00 /u01/app/oracle/product/11.2.0/db_2/bin/tnslsnr LISTENER -inherit
oracle 18607 0.1 0.6 2350168 39972 ? Ss 09:37 0:00 oracleDB1 (LOCAL=NO)
oracle 18609 0.1 1.4 2395944 85880 ? Ss 09:37 0:00 oracleDB1 (LOCAL=NO)
oracle 18611 0.0 0.5 2346216 36100 ? Ss 09:37 0:00 oracleDB1 (LOCAL=NO)
oracle 18615 0.1 0.2 2331228 18136 ? Ss 09:38 0:00 oracleDB1 (LOCAL=NO)
oracle 18617 0.1 0.3 2332184 21508 ? Ss 09:38 0:00 oracleDB1 (LOCAL=NO)
oracle 18619 0.0 0.0 65556 940 pts/1 R+ 09:38 0:00 ps -aux
oracle 18620 0.0 0.0 61160 736 pts/1 S+ 09:38 0:00 grep oracle
Shared memory is still allocated for instance:
df -h /dev/shm
System plików rozm. użyte dost. %uż. zamont. na
tmpfs 5,0G 2,0G 3,1G 39% /dev/shm
Please for help.
Regards
Karol

It is lool like the new standby database is started from old home:
alert log:
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile /u01/app/oracle/product/11.2.0/db_1/dbs/spfileDB1.ora
System parameters with non-default values:
My old home (11.2.0.1) u01/app/oracle/product/11.2.0/db_1
My new home (11.2.0.2) u01/app/oracle/product/11.2.0/db_2
previous start this database:
alert log:
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile /u01/app/oracle/product/11.2.0/db_2/dbs/spfileDB1.ora
System parameters with non-default values:
Why database is starting from old home?
I Changed directories in .bash_profile oracle OS user.

Reg:Primary Database

Hello
In my primary database i have a problem
I checked the switchover_status it resulted in "not allowed"
how to make it as "To Standby"

Can you run this query and post the results?
http://www.visi.com/~mseberg/monitor_data_guard_transport.html
"not allowed" generally means you have a gap. The query should provide the first clues.
If you are using Standard Edition then this isn't really Data Guard, its a poor mans copy of the database and you should not expect it to have Data Guard features.
This is also the default for databases not using Data Guard.
Checking switchover status
SWITCHOVER_STATUS
NOT ALLOWED Best Regards
mseberg
Edited by: mseberg on Aug 6, 2012 12:24 PM

Error: is not a primary database file.

Hello
If I try to set a database online with:
ALTER DATABASE mydb SET online
this error occurs:
Msg 5171, Level 16, State 1, Line 1
E:\Data\mydb_log.ldf is not a primary database file.
Msg 5171, Level 16, State 2, Line 1
E:\Data\mydb.mdf is not a primary database file.
File activation failure. The physical file name "E:\Data\mydb.mdf" may be incorrect.
Msg 945, Level 14, State 2, Line 1
Database 'mydb' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.
The path of ldf and mdf file is correct.
And if I delete the database "DROP DATABASE mydb" and attach the files, then it works..
Thanks for your help

Cause
This problem generally occurs if the MDF file of your SQL Server has got damaged. the problem could be due to file header corruption or wrong information in file header.
All such situations lead to the inaccessibility of MDF file and need to repair and restore the database. It is very important to work around this problem, as it may put your business at risk of destruction.
The MDF repair is possible with the help of third party applications known as SQL recovery software. These software are helpful in each and every case of MDF corruption and thus allow you to have perfect MDF recovery.
To perform SQL repair using these software, it is not necessary for the user to have sound technical knowledge as MDF repair software come with interactive user interface. SQL recovery software do systematic scan of corrupted MDF files, repair and restore them in original format.
Stellar Phoenix SQL Database Recovery is the most advanced and the most influential SQL recovery software which allows you to have effective and successful MDF recovery in all cases of corruption. This SQL repair software comes equipped with an interactive, simple and cool looking user interface.
This MDF repair software is powerful enough to carry out systematic scan of entire MDF file and extract all of the data from it. This SQL repair software can restore all of the MDF objects including tables, reports, forms, macros, database constraints, stored procedures, triggers etc.
Cheers, Sridhar -------------- Please Mark it as Answer if it helps u so that it will be useful to other forum guys

Standby data Gurad 10g switchover problem with application

Hi!
I'm working on oracle 10g and try to make standby datagurad with same dbname eg. if my primary database name is orcl then my standby database should be orcl with same location because one of mine application is accepting only orcl not standbyorcl.
Because when I'm doing switchover to standby database application not able to read standbyorcl and application result through error and close.
Could any one help me to make init.ora parameter for primary and standinit.ora for standby with same database name.
Amit Kumar

You should use an Application Service instead of the standard Database Service in the first place to take care of Role Changes in your Data Guard configuration properly.
Look here for an example:
http://uhesse.wordpress.com/oracle-database-ha-architecture/2009/08/19/connect-time-failover-transparent-application-failover-for-data-guard/
Kind regards
Uwe Hesse
http://uhesse.wordpress.com

Use of standby redo log files in primary database

Hi All,
What is the exact use of setting up standby redo log files in the primary database on a data guard setup?
any good documents?

A standby redo log is required for the maximum protection and maximum availability modes and the LGWR ASYNC transport mode is recommended for all databases. Data Guard can recover and apply more redo data from a standby redo log than from archived redo log files alone.
You should plan the standby redo log configuration and create all required log groups and group members when you create the standby database. For increased availability, consider multiplexing the standby redo log files, similar to the way that online redo log files are multiplexed.
refer the link,and Perform the following steps to configure the standby redo log.:-
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/create_ps.htm#i1225703
If the real-time apply feature is enabled, log apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived. This results in faster switchover and failover times because the standby redo log files have been applied already to the standby database by the time the failover or switchover begins.
refer the link
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/log_apply.htm#i1023371

RAW primary database and ASM standby database

Hi,
I would like to know if it is possible to have a ASM standby database for a primary database which is on RAW files.Is there any changes in procedure for a switchover to DR site.

Sekar_BLUE4EVER wrote:
Hi,
I would like to know if it is possible to have a ASM standby database for a primary database which is on RAW files.Is there any changes in procedure for a switchover to DR site.Yes, you can. and there is no change in procedure for switchover.
for creation of standby DB, consider these parameters: db_create_file_dest,db_recovery_file_dest,control_files
see an example here: http://pythianpang.wordpress.com/2010/02/18/data-guard-non-asm-primary-to-asm-physical-standby/
HTH
Tobi
Edited by: teits on Nov 20, 2012 12:13 PM

The observer only reinstate the old primary database after startup it twice

I use Oracle 11g r2 configure a data guard and fast_start fail over (using data guard broker) environment on linux.
The data guard works fine, and the fail over too.
The problem is that after fail over, the observer can't reinstate the old primary database to new standby database after start up it to mount, and what strange is that if shutdown (immediate) it again, and start up it to mount again, the reinstating can be completed automatically and successfully.
I use 'shutdown abort' to simulate the database crash.
Any one have some advice? Thanks in advance!
Edited by: user1665703 on 2011-7-27 下午4:33

There are some strange log in drcorcl.log,
2011-07-27 16:30:57.702 RSM0: HEALTH CHECK ERROR: ORA-16808: primary database is not open
2011-07-27 16:30:57.844 RSM Warning: cannot find the destination setting in v$archive_dest for database 'orclSt
d'.
2011-07-27 16:30:57.844 RSM0: HEALTH CHECK WARNING: ORA-16728: consistency check for property LogXptMode found
ORA-16777 error
2011-07-27 16:30:57.845 RSM0: HEALTH CHECK WARNING: ORA-16777: unable to find the destination entry of a standb
y database in V$ARCHIVE_DEST
2011-07-27 16:30:57.845 RSM Warning: cannot find the destination setting in v$archive_dest for database 'orclSt
d'.
2011-07-27 16:30:57.845 RSM0: HEALTH CHECK WARNING: ORA-16728: consistency check for property DelayMins found O
RA-16777 error
2011-07-27 16:30:57.845 RSM0: HEALTH CHECK WARNING: ORA-16777: unable to find the destination entry of a standb
y database in V$ARCHIVE_DEST
2011-07-27 16:30:57.846 RSM Warning: cannot find the destination setting in v$archive_dest for database 'orclSt
d'.
2011-07-27 16:30:57.846 RSM0: HEALTH CHECK WARNING: ORA-16728: consistency check for property Binding found ORA
-16777 error
2011-07-27 16:30:57.846 RSM0: HEALTH CHECK WARNING: ORA-16777: unable to find the destination entry of a standb
y database in V$ARCHIVE_DEST
2011-07-27 16:30:57.847 RSM Warning: cannot find the destination setting in v$archive_dest for database 'orclSt
d'.
2011-07-27 16:30:57.847 RSM0: HEALTH CHECK WARNING: ORA-16728: consistency check for property MaxFailure found
ORA-16777 error
2011-07-27 16:30:57.847 RSM0: HEALTH CHECK WARNING: ORA-16777: unable to find the destination entry of a standb
y database in V$ARCHIVE_DEST
2011-07-27 16:30:57.848 RSM Warning: cannot find the destination setting in v$archive_dest for database 'orclSt
d'.
2011-07-27 16:30:57.848 RSM0: HEALTH CHECK WARNING: ORA-16728: consistency check for property MaxConnections fo
und ORA-16777 error
2011-07-27 16:30:57.848 RSM0: HEALTH CHECK WARNING: ORA-16777: unable to find the destination entry of a standb
y database in V$ARCHIVE_DEST
2011-07-27 16:30:57.849 RSM Warning: cannot find the destination setting in v$archive_dest for database 'orclSt
d'.
2011-07-27 16:30:57.849 RSM0: HEALTH CHECK WARNING: ORA-16728: consistency check for property ReopenSecs found
ORA-16777 error
2011-07-27 16:30:57.849 RSM0: HEALTH CHECK WARNING: ORA-16777: unable to find the destination entry of a standb
y database in V$ARCHIVE_DEST
2011-07-27 16:30:57.849 RSM Warning: cannot find the destination setting in v$archive_dest for database 'orclSt
d'.
2011-07-27 16:30:57.850 RSM0: HEALTH CHECK WARNING: ORA-16728: consistency check for property NetTimeout found
ORA-16777 error
2011-07-27 16:30:57.850 RSM0: HEALTH CHECK WARNING: ORA-16777: unable to find the destination entry of a standb
y database in V$ARCHIVE_DEST
2011-07-27 16:30:57.850 RSM Warning: cannot find the destination setting in v$archive_dest for database 'orclSt
d'.
2011-07-27 16:30:57.850 RSM0: HEALTH CHECK WARNING: ORA-16728: consistency check for property RedoCompression f
ound ORA-16777 error
2011-07-27 16:30:57.851 RSM0: HEALTH CHECK WARNING: ORA-16777: unable to find the destination entry of a standb

ORA-00235 Standby Database Controlfile problem

Dear fellow dbas,
I am just starting to become acquainted with high availability and have to solve following problem.
We have a RAC database with a standby database that is out of sync. In fact the standby database is running in async mode but archived redo logs are not applied.
They are successfully forwarded from the primary instance to the standby db though. Looking at the alert.log I discovered an ORA-00235 error - control file fixed table inconsistent due to concurrent update.
As a result of this I have a huge gap between the primary and standby database.
Can you please give me a step to step tutorial, how I can resolve this issue?
Any help is appreciated!
Many thanks,
Sebastian

Hello Anand,
I am using 11.1.0.7.0.
My standby database is a cluster database as well. I shut both instances down using srvctl and created a standby controlfile from my primary instance, which I copied to the respective locations referred to in the spfile of my dataguard database. Afterwards I started up and issued a ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
The database does not open and the alert.log states ORA-01124 "cannot recover datafile 1 - file is in use or recovery".
Next, the background media recovery process was shut down.
What should I do, to get my standby back running?
Should I place the primary database in backup mode and copy the datafiles to my standby db?
Afterwards I would create a standby controlfile again and overwrite the standby ones.
Maybe you assist in pointing at the next steps.
Many thanks,
Sebastian

Restart on primary database restarts the recovery process on standby

We have a dataguar broker configuration running in maximum perfromance mode.
Every time we start the primary database, the recovery process on standby gets restarted.
I can consistently reproduce teh problem. Looks like expected behaviour.
Even if standby is in read only mode and restart the primary database it bring the database back in recovery mode.
Any explanation why oracle needs to do it?

Neil_Arul wrote:
We have a dataguar broker configuration running in maximum perfromance mode.
Every time we start the primary database, the recovery process on standby gets restarted.
I can consistently reproduce teh problem. Looks like expected behaviour.
Even if standby is in read only mode and restart the primary database it bring the database back in recovery mode.
Any explanation why oracle needs to do it?Yes, When you enable broker it very common behaviour.
When ever you bounce the database also MRP process will be started automatically.
By disabling broker you can avoid automatic startup, BTW Standby should be in recovery mode, i think no need to worry on this.
If you want to disable as per time, you can disable it as below
ALTER SYSTEM SET DG_BROKER_START=FALSE ;
Total Questions: 3 (3 unresolved)
Close the threads when you feel its answered, Keep the forum clean.
Edited by: CKPT on Feb 15, 2012 12:57 PM

Logical dataguard SQL apply fails during import on primary database

I have created logical dataguard using GRID, initially every things works fine.
One time we had to do import of new data on primary database, that is where the problem started.
log apply is lagging big time, and i got this error
StatusRedo apply services stopped due to failed transaction (1,33,8478)
ReasonORA-16227: DDL skipped due to missing object
Failed SQLDROP TABLE "USA"."SYS_IMPORT_SCHEMA_01" PURGE
This table exists on logical dataguard...
How do we deal with import on logical dataguard, since import generates a lot of redlogs

Hello;
These Oracle notes might help :
Slow Performance In Logical Standby Database Due To Lots Of Activity On Sys.Aud$ [ID 862173.1]
Oracle10g Data Guard SQL Apply Troubleshooting [ID 312434.1]
Developer and DBA Tips to Optimize SQL Apply [ID 603361.1]
Best Regards
mseberg

Recover Primary Database from Standby Database

Hi all,
I'm trying to understand how to use physical standby database in order to have a backup from a primary database.
The first part is very clear. I supose I have a physical standby database ready and archiving from a primary database but the second part is the problem.
1. Now I supose that my primary database is gone... not just a logical corruption but a physical disaster such a fire o something worst.
How to recover the primary site from the physical standby database??????????
2. Just a logical corruption in primary database. How to syncronize with the standby database that it's the one who has the right data???
Thanks in advance.
Edited by: jsfelix on 18-nov-2009 4:48
Edited by: jsfelix on 18-nov-2009 4:51

How to recover the primary site from the physical standby database?1. Ensure that you DO have a Primary Site up and running. It might be the same building. It might be another building. Management might decide to switch to another city. (BTW, all of this should be defined in the D.R. / B.C.P. documentation).
The (possibly new) Primary Site has to have the required hardware , O.S etc.
2. Take a backup of the Standby and restore it to the (possibly new) Primary.
Actually, the Standby becomes the new Primary and the new site that is setup becomes the Standby. This continues until management decides to switch over.
Just a logical corruption in primary database.Take a backup of the Standby and restore it to the Primary. You have to suffer an outage. Note : If only one or few files on the Primary are physically corrupt (and offline), you could backup the selected files from the Standby and RESTORE and RECOVER on the Primary !
Hemant K Chitale
http://hemantoracledba.blogspot.com

Failover from standby database to primary database

Hi,
Can anyone suggest me, How to do " Standby DataGuard database to primary database (dataguard)".
Kindly Give me steps.
Thanks,
Shweta

Hi
Follow these steps
Oracle switchover operation:
1.     Check and verify the role parameter on the v$parameters both primary and standby
On Primary
Log_archive_dest_1=”this is the local archive destination”
+Log_archive_dest_2=”This is the Service [TNS ENTRY]”+
Log_archive_dest_state_1=Enable
Log_archive_dest_state_2=Enable
Fal_server=”this should have the tns entry for the standby
Fal_Client=”this should have the tns entry for the primary
Standby_archive_dest=”This should have the Location where the archive located”
Standby_File_Management=AUTO
On Standby
Log_archive_dest_1=”this is the local archive destination”
+Log_archive_dest_2=”This is the Service [TNS ENTRY]”+
Log_archive_dest_state_1=Enable
Log_archive_dest_state_2=DEfer
Fal_server=”this should have the tns entry for the primary
Fal_Client=”this should have the tns entry for the standby
Standby_archive_dest=”This should have the Location where the archive located”
Standby_File_Management=AUTO
2.     Down all the applications connects to the database
3.     Shutdown both primary and standby databases
4.     For RAC Keep Only one primary and One standby up and all other nodes should be down
5.     Check the Primary database on Open mode and the Standby database on mount stage
6.     On Primary
SQL>select switchover_status from v$database;Sessions Active or To standby will be appearing on the result
SQL> alter database commit to switchover to standby with session shutdown;
SQL> shutdown Immediate;
SQL>startup nomount;
SQL>alter database mount standby database;
SQL>Alter system set log_Archive_dest_state_2=defer;7.     On Standby
SQL>select switchover_status from v$database;it is acceptable to have Sessions Active or To Primary
SQL>alter database commit to switchover to primary with session shutdown;
SQL>shutdown immediate;
SQL>Startup;
SQL.>Alter system set log_archive_dest_state_2=enable;8.     On Primary
start the managed recovery
SQL>Alter database recover managed standby database disconnect from session;9.     Check the log shipment is working from New Primary to New Standby Using
SQL>Alter system switch logfile; ---- On New Primary.check the alert log on both Primary and Standby for the log shipment and Media recovery.
10.     If the switch over fail issue the following statement on standby (ORACLE 9i)
SQL> alter database recover managed standby database finish skip standby logfile ┘
SQL> alter database commit to switchover to primary┘
SQL> shutdown immediate;
SQL> Startup;11.     If this don’t work please issue the below statement
SQL> alter database activate standby database skip standby logfile;12.     If the switch over fail issue the following statement on standby (ORACLE 10g and above)
SQL> alter database recover managed standby database finish force;
SQL> alter database commit to switchover to primary;
SQL> alter database open;
SQL> shutdown Immediate;
SQL> startup;13. Added the temp file to your temp tablespace
If you follow the steps (10,11 & 12 ) you have to recreate the standby again. those steps are actually fail over steps. Hope this will be helpful
Cheers
Kanchana

ARCH: Possible network disconnect with primary database

Dear buddies,
My database has a primary database which has a few sub databases.
They are in different servers.
One of the sub database has this error in the alert log everyday during backup time.
But finally the backup is successful.
Is this a network problem?
Please guide me.
Thanks in advance.

user645399 wrote:
Dear SB:
THis is the error I come across once in a while in my alert log:
ARCH: Possible network disconnect with primary database
post
select FACILITY,SEVERITY,MESSAGE_NUM,ERROR_CODE,CALLOUT,to_char(timestamp,'DD-MON-YYYY HH24:MI:SS'),MESSAGE from v$dataguard_status where dest_id=2;
sample
SQL> select FACILITY,SEVERITY,MESSAGE_NUM,ERROR_CODE,CALLOUT,to_char(timestamp,'DD-MON-YYYY HH24:MI:SS'),MESSAGE from v$dataguard_status where dest_id=2;
FACILITY                 SEVERITY      MESSAGE_NUM ERROR_CODE CAL TO_CHAR(TIMESTAMP,'D MESSAGE
Log Transport Services   Error              312410       3135 YES 27-JUL-2011 05:01:51 NSA: Error 3135 archiving log 5 to 'stby'
Log Transport Services   Error              312539       3135 YES 27-JUL-2011 16:56:40 NSA: Error 3135 archiving log 7 to 'stby'
SQL>

Why do we need standby redo log on Primary database.

Hi Gurus,
I was going through the document in OBE,
http://www.oracle.com/technology/obe/11gr1_db/ha/dataguard/physstby/physstdby.htm
I have two queries:
1) I noticed the statement -
"Configure the primary database to receive redo data, by adding the standby logfiles to the primary. "
Why do we have to create standby redo log on a primary database?
2) There is another statement --
"It is highly recommended that you have one more standby redo log group than you have online redo log groups as the primary database. The files must be the same size or larger than the primary database’s online redo logs. "
Why do we need one additional standby redo log group than in Primary database.
Could anyone please explain to me in simple words.
Thanks
Cherrish Vaidiyan

Hi,
1. Standby redo logs are used only when the database_role is standby, it is recommended to be added in primary also so that they can be used on role reversal, however during normal working standby redo logs will not be used at all on primary.
2. In case of 3 online redo log groups, it is recommended to use 4 standby redo log group this is in case if log switching is happening frequently on primary and all 3 standby redo logs are still not completely archived on the standby and 4th can be used here as there will be some delay on standby due to network or slowness of arch on standby.
Use of the standby redo log groups depends on the redo generation rate, you can see only 2 standby redo logs are getting used while you have 4 standby redo log groups, when the redo generation rate is less.
So it is recommended to have one more standby redo log group when redo generation rate is high and all of the existing standby redo log group are getting used.
Regards
Anudeep

Primary database switchover problem

Similar Messages

Maybe you are looking for