Home » Server Options » Data Guard » DATAGUARD SWITCHOVER_STATUS -------------------- NOT ALLOWED (Oracle 11g Database Dataguard)
DATAGUARD SWITCHOVER_STATUS -------------------- NOT ALLOWED [message #674348] Tue, 22 January 2019 06:25 Go to next message
akbardba
Messages: 3
Registered: January 2019
Junior Member
hi guys i need some professional help from you guy's my standby database switchover status showing me SWITCHOVER_STATUS
--------------------
NOT ALLOWED
BUT FROM PRIMARY DATABASE IS SHOWING ME FINE Select switchover_status
from v$Database; 2

SWITCHOVER_STATUS
--------------------
TO STANDBY
GIVE ME SOLUTION ACTUALLY I AM NEW TO DATAGUARD PLEASE HELP ME I AM STUCK IN THIS PROBLEM SINCE 1 MONTH.
EVEN I WAS CONFIGURE DATAGUARD-BROKER DGMGRL EVERYTHING IS FINE BUT WHEN I WANT TO SWITCHOVER TO PRIMARY THEN IT SHOW AN ERROR
STANDBY DATABASE BE SWITCHOVER FAILED
PRIMARY DATABASE IS STILL SAME FOR PRIMARY 'SID' FAILED.
BELOW IS MY ALERT LOGFILE FROM PRIMARY AND STANDBY DATABASE
BELOW IS PRIMARY-DATABASE

CHANGE TRACKING is reinitializing the change tracking file.
Sun Jan 20 00:13:42 2019
Assigning activation ID 406308967 (0x1837c867)
LGWR: STARTING ARCH PROCESSES
Sun Jan 20 00:13:42 2019
ARC0 started with pid=25, OS id=13426
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thread 1 opened at log sequence 8
Current log# 1 seq# 8 mem# 0: /oraeng/app/oracle/oradata/dgdb1/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Starting background process CTWR
Sun Jan 20 00:13:43 2019
ARC1 started with pid=26, OS id=13428
Sun Jan 20 00:13:43 2019
CTWR started with pid=27, OS id=13430
Sun Jan 20 00:13:43 2019
ARC2 started with pid=28, OS id=13432
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Sun Jan 20 00:13:43 2019
ARC3 started with pid=29, OS id=13434
Block change tracking service is active.
Sun Jan 20 00:13:43 2019
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Sun Jan 20 00:13:43 2019
QMNC started with pid=30, OS id=13436
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Sun Jan 20 00:13:44 2019
db_recovery_file_dest_size of 3852 MB is 23.93% 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.
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Sun Jan 20 00:13:44 2019
ARC4 started with pid=31, OS id=13450
ALTER SYSTEM SET service_names='DG_PROD' SCOPE=MEMORY SID='dgdb1';
Sun Jan 20 00:13:44 2019
Starting background process CJQ0
Sun Jan 20 00:13:44 2019
CJQ0 started with pid=32, OS id=13452
Completed: ALTER DATABASE OPEN
ARC4: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Using STANDBY_ARCHIVE_DEST parameter default value as /oraeng/app/oracle/oradata/archivelog
ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH;
ALTER SYSTEM SET log_archive_trace=0 SCOPE=BOTH SID='dgdb1';
ALTER SYSTEM SET log_archive_format='%t_%s_%r.dbf' SCOPE=SPFILE SID='dgdb1';
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH SID='*';
ALTER SYSTEM SET archive_lag_target=0 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_max_processes=4 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_min_succeed_dest=1 SCOPE=BOTH SID='*';
ALTER SYSTEM SET db_file_name_convert='/oradata/DGDB2','/oradata/DGDB1' SCOPE=SPFILE;
ALTER SYSTEM SET log_file_name_convert='/oradata/DGDB2','/oradata/DGDB1' SCOPE=SPFILE;
Sun Jan 20 00:13:46 2019
NSA2 started with pid=33, OS id=13454
******************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
******************************************************************
Thread 1 advanced to log sequence 9 (LGWR switch)
Current log# 2 seq# 9 mem# 0: /oraeng/app/oracle/oradata/dgdb1/redo02.log
Setting Resource Manager plan SCHEDULER[0x3008]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Sun Jan 20 00:13:49 2019
Starting background process VKRM
LNS: Standby redo logfile selected for thread 1 sequence 8 for destination LOG_ARCHIVE_DEST_2
Sun Jan 20 00:13:50 2019
VKRM started with pid=35, OS id=13458
Archived Log entry 805 added for thread 1 sequence 8 ID 0x1837c867 dest 1:
LNS: Standby redo logfile selected for thread 1 sequence 9 for destination LOG_ARCHIVE_DEST_2
Sun Jan 20 00:14:16 2019
Using STANDBY_ARCHIVE_DEST parameter default value as /oraeng/app/oracle/oradata/archivelog
ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH;
Sun Jan 20 00:14:43 2019
Shutting down archive processes
Sun Jan 20 00:14:43 2019
ARCH shutting down
ARC4: Archival stopped
Sun Jan 20 00:23:44 2019
Starting background process SMCO
Sun Jan 20 00:23:44 2019
SMCO started with pid=31, OS id=13547
Sun Jan 20 02:00:00 2019
Clearing Resource Manager plan via parameter

BELOW IS MY STANDBY-DATABASE ALERT LOGFILE.

DMON started with pid=19, OS id=11579
ORACLE_BASE not set in environment. It is recommended
that ORACLE_BASE be set in the environment
Reusing ORACLE_BASE from an earlier startup = /oraeng/app/oracle
Sun Jan 20 00:06:41 2019
alter database mount standby database
ARCH: STARTING ARCH PROCESSES
Sun Jan 20 00:06:45 2019
ARC0 started with pid=21, OS id=11586
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Sun Jan 20 00:06:46 2019
Successful mount of redo thread 1, with mount id 406275025
Allocated 3981204 bytes in shared pool for flashback generation buffer
Starting background process RVWR
Sun Jan 20 00:06:46 2019
ARC1 started with pid=22, OS id=11588
Sun Jan 20 00:06:46 2019
RVWR started with pid=23, OS id=11590
ARC1: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
Sun Jan 20 00:06:46 2019
ARC3 started with pid=25, OS id=11594
Sun Jan 20 00:06:46 2019
ARC2 started with pid=24, OS id=11592
Physical Standby Database mounted.
Lost write protection disabled
Completed: alter database mount standby database
Sun Jan 20 00:06:47 2019
Starting Data Guard Broker (DMON)
ARC2: Archival started
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
ARC0: Becoming the heartbeat ARCH
Sun Jan 20 00:06:47 2019
NSV0 started with pid=26, OS id=11596
Sun Jan 20 00:06:50 2019
INSV started with pid=27, OS id=11598
Sun Jan 20 00:06:53 2019
RSM0 started with pid=28, OS id=11600
Using STANDBY_ARCHIVE_DEST parameter default value as /oraeng/app/oracle/oradata/archivelog
ALTER SYSTEM SET log_archive_trace=0 SCOPE=BOTH SID='dgdb2';
ALTER SYSTEM SET log_archive_format='%t_%s_%r.dbf' SCOPE=SPFILE SID='dgdb2';
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE THROUGH ALL SWITCHOVER DISCONNECT USING CURRENT LOGFILE
Attempt to start background Managed Standby Recovery process (dgdb2)
Sun Jan 20 00:06:57 2019
MRP0 started with pid=29, OS id=11602
MRP0: Background Managed Standby Recovery process started (dgdb2)
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Clearing online redo logfile 1 /oraeng/app/oracle/oradata/dgdb1/redo01.log
Clearing online log 1 of thread 1 sequence number 7
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 /oraeng/app/oracle/oradata/dgdb1/redo02.log
Clearing online log 2 of thread 1 sequence number 5
Sun Jan 20 00:07:03 2019
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE THROUGH ALL SWITCHOVER DISCONNECT USING CURRENT LOGFILE
Clearing online redo logfile 2 complete
Clearing online redo logfile 3 /oraeng/app/oracle/oradata/dgdb1/redo03.log
Clearing online log 3 of thread 1 sequence number 6
Clearing online redo logfile 3 complete
Media Recovery Waiting for thread 1 sequence 8
Sun Jan 20 00:13:46 2019
RFS[1]: Assigned to RFS process 11643
RFS[1]: Identified database type as 'physical standby': Client is ARCH pid 13432
Sun Jan 20 00:13:50 2019
RFS[2]: Assigned to RFS process 11645
RFS[2]: Identified database type as 'physical standby': Client is LGWR ASYNC pid 13454
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Selected log 4 for thread 1 sequence 8 dbid 404083827 branch 998006244
Sun Jan 20 00:13:50 2019
Recovery of Online Redo Log: Thread 1 Group 4 Seq 8 Reading mem 0
Mem# 0: /oraeng/app/oracle/oradata/dgdb1/redostn01.log
Sun Jan 20 00:13:50 2019
Archived Log entry 250 added for thread 1 sequence 8 ID 0x1837c867 dest 1:
RFS[2]: Selected log 4 for thread 1 sequence 9 dbid 404083827 branch 998006244
Media Recovery Waiting for thread 1 sequence 9 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 9 Reading mem 0
Mem# 0: /oraeng/app/oracle/oradata/dgdb1/redostn01.log
Sun Jan 20 00:14:44 2019
RFS[3]: Assigned to RFS process 11647
RFS[3]: Identified database type as 'physical standby': Client is ARCH pid 13432
Sun Jan 20 00:14:48 2019
ALTER DATABASE RECOVER managed standby database disconnect
Sun Jan 20 00:15:21 2019
ORA-1153 signalled during: ALTER DATABASE RECOVER managed standby database disconnect ...
Sun Jan 20 00:15:55 2019
alter database commit to switchover to physical standby with session shutdown
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 11580] (dgdb2)
Switchover Operation not allowed on a physical standby
Completed: alter database commit to switchover to physical standby with session shutdown
Sun Jan 20 00:21:22 2019
db_recovery_file_dest_size of 2048 MB is 23.45% 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.
Sun Jan 20 01:43:01 2019
alter database recover managed standby database cancel
Sun Jan 20 01:43:01 2019
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /oraeng/app/oracle/diag/rdbms/dgdb2/dgdb2/trace/dgdb2_mrp0_11602.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 3283793
Waiting for MRP0 pid 11602 to terminate
Errors in file /oraeng/app/oracle/diag/rdbms/dgdb2/dgdb2/trace/dgdb2_mrp0_11602.trc:
ORA-16037: user requested cancel of managed recovery operation
MRP0: Background Media Recovery process shutdown (dgdb2)
Managed Standby Recovery Canceled (dgdb2)
Completed: alter database recover managed standby database cancel
Sun Jan 20 01:43:25 2019
alter database recover managed standby database using current logfile disconnect from session
Attempt to start background Managed Standby Recovery process (dgdb2)
Sun Jan 20 01:43:25 2019
MRP0 started with pid=29, OS id=12050
MRP0: Background Managed Standby Recovery process started (dgdb2)
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Waiting for thread 1 sequence 9 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 9 Reading mem 0
Mem# 0: /oraeng/app/oracle/oradata/dgdb1/redostn01.log
Completed: alter database recover managed standby database using current logfile disconnect from session
Re: DATAGUARD SWITCHOVER_STATUS -------------------- NOT ALLOWED [message #674350 is a reply to message #674348] Tue, 22 January 2019 06:37 Go to previous message
John Watson
Messages: 8085
Registered: January 2010
Location: Global Village
Senior Member
Welcome to the forum. Please read the OraFAQ Forum Guide and How to use code tags and make your code easier to read and PLEASE DON'T USE UPPER CASE so much, it is unpleasant to look at.

What you are describing is normal. Your standby will always say switchover_status NOT ALLOWED until you initiate the switchover on the primary. You did not do that: you tried to run the command ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY on the standby, which is wrong.
Previous Topic: PING[ARCX]: Heartbeat failed to connect to standby 'XXX'. Error is 1034
Next Topic: Error 12154 received logging on to the standby (split from hijacked topic)
Goto Forum:
  


Current Time: Sat Dec 14 12:33:48 CST 2019