Adding a standby database to a dataguard configuration fails with ORA-1017 (Doc ID 1072022.1)

To Bottom

In this Document

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.1.0.6 and later
Information in this document applies to any platform.

SYMPTOMS

Physical standby database works fine, archive logs are transferred and applied successfully.

Creating a new standby database and adding it to the existing broker configuration with
dgmgrl fails with ORA-1017:

           DGMGRL> CREATE CONFIGURATION 'MYXETEPDG' AS  
          
 > PRIMARY DATABASE IS 'MYXETEP'  
          
 > CONNECT IDENTIFIER IS 'MYXETEP.WORLD; 
          
 Configuration "MYXETEPDG" created with primary database "MYXETEP" 
          
 DGMGRL> ADD DATABASE 'MYXETEPS'  
          
 > AS CONNECT IDENTIEFIER IS MYXETEPS.WORLD;

The drc*.log show fallowing error:

           2010-03-04-19:45:27 0 2 975167469 DMON: Entered rfm_get_chief_lock() for ADD_DATABASE, reason 0 
          
 DG 2010-03-04-19:45:27 0 2 975167469 DMON: chief lock convert for write op ADD_DATABASE 
          
 DG 2010-03-04-19:45:27 0 2 0 Connection to database MYXETEPS returns ORA-01017. 
          
 DG 2010-03-04-19:45:27 0 2 0 Please check database MYXETEPS is using a remote password file, 
          
 DG 2010-03-04-19:45:27 0 2 0 its remote_login_passwordfile is set to SHARED or EXCLUSIVE, 
          
 DG 2010-03-04-19:45:27 0 2 0 and the SYS password is the same as this database. 
          
 DG 2010-03-04-19:45:27 0 2 0 DMON: Failed to connect to remote database MYXETEPS. Error is ORA-01017 
          
 DG 2010-03-04-19:45:27 0 2 0 DMON: Failed to get properties from remote database MYXETEPS. Error is ORA-01017. 
          
 DG 2010-03-04-19:45:27 0 2 975167469 Add site succeeded. 
          
 DG 2010-03-04-19:45:27 0 2 975167469 Adding internal resource MYXETEPS pid 2001000 parent_state ONLINE (1) vinst 0 
          
 DG 2010-03-04-19:45:27 0 2 975167469 -- default_state OFFLINE (0) 
          
 DG 2010-03-04-19:45:27 0 2 975167469 Adding internal resource MYXETEPS pid 2001000 parent_state PRIMARY (3) vinst 1 
          
 DG 2010-03-04-19:45:27 0 2 975167469 -- default_state READ-WRITE-XPTON (9) 
          
 DG 2010-03-04-19:45:27 0 2 975167469 Adding internal resource MYXETEPS pid 2001000 parent_state STANDBY (4) vinst 2 
          
 DG 2010-03-04-19:45:27 0 2 975167469 -- default_state PHYSICAL-APPLY-ON (4) 
          
 DG 2010-03-04-19:45:27 0 2 0 Connection to database MYXETEPS returns ORA-01017. 
          
 DG 2010-03-04-19:45:27 0 2 0 Please check database MYXETEPS is using a remote password file, 
          
 DG 2010-03-04-19:45:27 0 2 0 its remote_login_passwordfile is set to SHARED or EXCLUSIVE, 
          
 DG 2010-03-04-19:45:27 0 2 0 and the SYS password is the same as this database.

CHANGES

This is an enhancement in 11g R1 where we are using strong password authentication. With this feature
the passwords are case sensitive.

CAUSE

The problem is caused by internal changes to the password file for 11.1.
Because of this, we must use a copy of the primary password file for the
standby to allow the broker and redo transport to connect to the
standby.

SOLUTION

1.) Copy the password file from primary to standby database, and call it orapw<standby instance_name> for UNIX platform or PWD<standby instance_name>.ora for MicroSoft Windows platform. Please verify the standby instance_name by logging into standby sqlplus as sysdba.

     SQL> show parameter instance_name

2.) a. Turn off the case sensitivity option by changing init.ora/spfile parameter
SEC_CASE_SENSITIVE_LOGON=FALSE on both the primary and the standby databases.
This is a Dynamic parameter and can be changed with

         SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE SCOPE=BOTH SID='*';    /* run on both primary and standby databases */
          SQL> ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON=FALSE SCOPE=BOTH SID='*';
          SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE SCOPE=BOTH SID='*';    /* run on both primary and standby databases */

b. Create a new password file on primary using ignorecase=Y option and copy the new password file to the standby database.

                      $ORAPWD FILE=filename [ENTRIES=numusers] [FORCE={Y|N}] IGNORECASE=Y [NOSYSDBA={Y|N} 
         