How not to set up remote log shipping – Dataguard and Streams
Posted by John Hallas on April 11, 2008
I was trying to set up a Streams archived_log downstream capture between two 11.1.0.6 databases and I was having problems in getting the archive log files to transport over to the target database where they will be read and applied.
First steps was to change log_archive_dest to use log_archive_dest_1 and log_archive_dest_2
log_archive_dest_1 = ‘location=/u00/oradata/dbs1/archive’
log_archive_dest_2 = ’service=dbs2 noregister template=/export3/u01/oradata/dbs1/archive/%t_%s_%r.dbf’
I ensured that the passwd file is set up on both sides and the sys password is the same and that remote_login_passwordfile is set to EXCLUSIVE.
In V$archive_dest I see an error of ORA-16191
Cause
An attempt to ship redo to standby without logging on to standby or with invalid user credentials.
Action
Check that primary and standby are using password files and that both primary and standby have the same SYS password. Restart primary and/or standby after ensuring that password file is accessible and REMOTE_LOGIN_PASSWORDFILE initialization parameter is set to SHARED or EXCLUSIVE.
I don’t think I need to make any changes on the target database to actually get the files across as I am not trying to read them as yet.
The service name works and I can connect remotely and I have re-created the password file as well
April Sims offered the following advice
I have encountered this in a DATA GUARD environment as well, see fix below. This also fixed problems with Grid Control in 11g.
Data Collected
==============
ORA-16191: Primary log shipping client not logged on standby
Support Update
==============
The issue seems to be because of password mismatch between primary and standby.
The password file has to have identical authentication info for both primary and standby
If you change or create the password file using orapwd for SYS,it will not work in 11G.
Action Plan
===========
Turn off the case sensitivity option by changing init.ora parameter SEC_CASE_SENSITIVE_LOGON=FALSE.
Create password files on both servers using the same password and pass ignorecase=Y to orapwd utility.
Make sure you use identical options during password file creation for both primary and standby
However I was still struggling with a ORA-1031 permissions problem as well as the ORA-16191 error.
I finally resolved the issue by taking the following actions
I amended my source database spfile to have the following entries
LOG_ARCHIVE_DEST_2=’SERVICE=DBS2.NET ASYNC NOREGISTER VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
TEMPLATE=/usr/oracle/log_for_dbs1/dbs1_arch_%t_%s_%r.log
DB_UNIQUE_NAME=dbs2′ — this line was new
LOG_ARCHIVE_CONFIG=’DG_CONFIG=(dbs1,dbs2)’ — new entry, using the DB_UNIQUE_NAME of both databases
The target database had an spfile with the following lines
*.LOG_ARCHIVE_DEST_2= ‘LOCATION=/export3/u01/oradata/dbs1/archive MANDATORY VALID_FOR=(STANDBY_LOGFILE,PRIMARY_ROLE) ‘
LOG_ARCHIVE_CONFIG=’DG_CONFIG=(dbs1,dbs2)’ — new entry, using the DB_UNIQUE_NAME of both databases
I still got the ORA-1031 error so I rebuilt the remote password file again and bounced the databases and everything sprung into life.
I think the key thing to do is to ensure that you can connect as sysdba from both databases to each other. If not then create/recreate the password file, bounce the databases and then try again. Once that is working it is time to start changing the spfile options to enable the second archive log destination.
Note that REMOTE_ARCHIVE_ENABLE parameter in 10g has been deprecated in 11g and replaced by LOG_ARCHIVE_CONFIG
Oracle DBA - A lifelong learning experience 
Polarski Bernard said
Humm using DB_UNIQUE_NAME so that to differentiate source and target in this dataguard. Definely NOT a good news.
– Won’t be able to send to other site a copied datafile to perform recover tablespace, for the DBID and DBNAME are in the datafile header. Use this after a import nologg on producion (need to recover dataguard) or datafile lost/corrupted on production (sent object from dataguard rather that resort to a restore – providing you have a sufficient delay apply).
– what about streams multimaster replication if your DB name changes after you switch primary to dg db? I doubt any configured streams will still function.
Arup Nanda said
Excellent post, John. Question: did you set the SEC_CASE_SENSITIVE_LOGON=FALSE and regenerate the password file to make it work?
If so, this defeats the case sensitive password feature of 11g.
dbametrix said
Excellent and usefull.
Aaron W. said
I ran into this same issue and used the ignorecase option as you mentioned and it worked successfully.
I did speak with Oracle and the issue is that I was using orapwd to create a password file on both the primary and standby server. Even though I created them both with the same password, due to password security enhancements in 11g, this will not work unless you use the ignorecase option. The proper way to resolve the issue is the create the password on the primary database server and then copy it to the standby server. I followed this method and it works.