Oracle DBA – A lifelong learning experience

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 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

Primary log shipping client not logged on standby


An attempt to ship redo to standby without logging on to standby or with invalid user credentials.


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



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_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

4 Responses to “How not to set up remote log shipping – Dataguard and Streams”

  1. 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.

  2. 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.

  3. 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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: