When Archive Logs Are Not Copied To Standby

I debug this same issue at least once a month since January 2008, and I always debug it from scratch because I’m a DBA with bad memory and I never remember how I solved it the last 18 times.

So, if you added a second (or third) archive log destination and then you see errors in the alter log that look like:

Check that the primary and standby are using a password file
and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
and that the SYS password is same in the password files.
returning error ORA-16191


  1. That you are using password files
  2. That the name of the password file is $ORACLE_HOME/dbs/orapw${ORACLE_SID}
  3. That the password of sys is the same on all the servers involved in the archive copy
  4. If one of the databases is 11g, make sure you set sec_case_sensitive_logon to false
  5. Also check that you created the password file with ignore_case=y

I think this covers my usual debug process. Except it normally takes me an hour to remember that 11g has this thing with case sensitive passwords, and what the parameter is called, and that there is another thingy to do with the password files… Hopefully, not anymore.


One Comment on “When Archive Logs Are Not Copied To Standby”

  1. Fuad Arshad says:

    Thanks Chen,
    I have to deal with this every 3 months. for logical standby’s its easy for physical i’ve actually got a process to shutdown the physical , ftp the orapw file and then start the standby again. Thanks for 11 reminder i’ve not gotten there yet but soonwill have to deal with suttle behaviour of 11g standby’s .

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Connecting to %s