Mani's Blog

December 14, 2012

Error: ORA-16751: failed to switchover to physical standby database. Both Oracle DB says Physical Standby

I ran the switchover to dataguard box.  I ran into issue where both database became physical standby.

Problem:

DGMGRL for Linux: Version 11.1.0.7.0 – 64bit Production

Copyright (c) 2000, 2005, Oracle. All rights reserved.

Welcome to DGMGRL, type “help” for information.
DGMGRL> connect sys/oracle
Connected.
DGMGRL> swtichover to xnodb01c
Unrecognized command “swtichover”, try “help”
DGMGRL> switchover to xnodb01c
Performing switchover NOW, please wait…
Error: ORA-16751: failed to switchover to physical standby database

Failed.
Unable to switchover, primary database is still “xnodb01cdg”

Solution:

Now I have to choose one database and promote as primary.   Following steps worked well for me.

SQL> select database_role from v$database;

DATABASE_ROLE
—————-
PHYSICAL STANDBY

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 2.6724E+10 bytes
Fixed Size            2160272 bytes
Variable Size         8321501552 bytes
Database Buffers     1.8254E+10 bytes
Redo Buffers          146423808 bytes
Database mounted.
SQL> alter database recover managed standby database cancel;
alter database recover managed standby database cancel
*
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active

SQL> alter database recover managed standby database finish;

Database altered.

SQL> ALTER database commit to switchover to primary with session shutdown;

Database altered.

SQL> alter database open;

Database altered.

SQL>  select database_role from v$database;

DATABASE_ROLE
—————-
PRIMARY

SQL> alter system switch logfile;

System altered.

SQL>

Now other DB functioning as Physical Standby with no issues.

December 12, 2012

The installer has detected that you may have an Automatic Storage Management (ASM) instance improperly configured or one that was not properly cleaned up from a previous install.

Filed under: Database,Oracle — mani @ 4:58 pm

I ran in to this issue when I re-install Oracle Binaries during prerequisites checking.

Problem:

The installer has detected that you may have an Automatic Storage Management (ASM) instance improperly configured or one that was not properly cleaned up from a previous install.

Solution:

You may see the recommendation by Oracle:  You must completely remove the ASM instance by deleting the entry for it from the oratab file, or you must configure it properly by ensuring that the oratab file is updated to point to a valid Oracle Home where ASM is configured.

But sometimes you need to make sure environment variables are set and old home directory has been removed.

 

ORA-16055: FAL request rejected ARCH: FAL archive failed. Archiver continuing

Filed under: Database,Dataguard,Oracle — mani @ 5:35 am
Tags: , , ,

Problem:

We have environment with Primary and Active standby Dataguard.   For some reason storage on Dataguard is crashed and I had rebuild the Dataguard DB from backup.  Noticed Archive log is not being shipped and when I look at alert log  found following errors.

FAL[server, ARC3]: FAL archive failed, see trace file.
Errors in file /local/opt/oracle/diag/rdbms/xnodbcor/XNODBCOR1/trace/XNODBCOR1_arc3_2216.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance XNODBCOR1 – Archival Error. Archiver continuing.

Checked parameter values on archive_dest on primary DB and noticed “RESET” value assigned to ” log_archive_dest_state_1″

log_archive_dest_state_1         string     RESET

Solution:

Enabled the dest_1 as below, that fixed the problem.   Error disappeared and logs are being shipped and applied on Standby site.

SQL> alter system set log_archive_dest_state_1=enable;

System altered.

SQL> alter system switch logfile;

System altered.

SQL>

Blog at WordPress.com.