Wednesday, January 21, 2015

Error 1031 received logging on to the standby

In a Dataguard environment, if you see messages similar to the following in the alert log file of your Primary database, there could be multiple reasons for these errors.
#########################################
Error 1031 received logging on to the standby
PING[ARC1]: Heartbeat failed to connect to standby 'mydb_standby'. Error is 1031.
#########################################
OR
#########################################
Error 1031 received logging on to the standby
FAL[server, ARC2]: Error 1031 creating remote archivelog file 'mydb_standby'
FAL[server, ARC2]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance mydb - Archival Error. Archiver continuing.
#########################################
OR
#########################################
Wed Jan 21 13:22:49 2015
Error 1031 received logging on to the standby
Errors in file /u01/app/oracle/diag/rdbms/mydb_prim/mydb/trace/mydb_arc1_2334.trc:
ORA-01031: insufficient privileges
FAL[server, ARC3]: FAL archive failed, see trace file.
#########################################


In my experience, there are 2 major causes of these errors. I will be discussing both in the following
Difference in Password file
This is mandatory to have same password file on both primary and standby database server. You should make sure that once you build your standby database, you copy the password file from primary database to the standby database. There could also be a possibility that password file on standby server is accidentally deleted or you might have recreated the passwordfile using orapwd utility - in either of the case, you can right away copy the passwordfile from primary to the standby database server. Location of password file is %ORACLE_HOME%\database on Windows platform and $ORACLE_HOME/dbs on Unix based platforms.
If you find that this is the cause of the error messages, you will also observe an archive gap at the standby database because primary database authentication is failing on standby database and logs are not being shipped.
You will also need to make sure that REMOTE_LOGIN_PASSWORDFILE is set to SHARED or EXCLUSIVE on both primary and standby database.
In case or RAC, you can copy password file from any node and paste it to all standby nodes and rename the password file to match the name of the particular standby instance.
Difference in password file may also cause to cause Error 1017 to appear in the alert log file.

Insufficient Resources on the Primary Server
If your primary server is lacking in resources (CPU is choking or RAM is depleted), you may see this error message in your alert log file of primary database. In this case, you would need to make sure the availability of resources on the primary server because lacking in sufficient resources may also affect normal operations of your primary database server.
If errors are because of this reason, usually there are no archive gaps. These messages only show that primary database is having difficulty in logging in to the standby database

4 comments:

  1. Thanks.. password file hint worked..

    ReplyDelete
  2. hi qureshi,

    In standby database how we can check the remote_login_password, because standby database is in startup nomount state?

    ReplyDelete
  3. hi qureshi,

    Once we set the password file in standby database, can we recreate the password file if database in nomount state??

    ReplyDelete