Error 1033 received logging on to the standby

Troubleshooting a dataguard environment is not very straightforward sometimes. If you come to know that physical standby database is out of sync with the primary database, first thing is to check the alert log files of primary and standby database to find out any error messages that might be appearing in the alert log files. For example, if error 1003 is reported in the alert log file, you may see entries similar to the following in the primary database’s alert log file.

Mon Feb 06 00:10:40 2017 Error 1033 received logging on to the standby PING[ARC1]: Heartbeat failed to connect to standby 'MY_STANDBY_DB'. Error is 1033.

PING[ARC1]: Heartbeat failed to connect to standby

If you see this message in the alert log of primary database, you need to perform a number of checks to find out the cause of the error.

• Check if your standby database in mount or open state. If not, start your database in mount state, or open it, and initiate managed recover process. 
• In case of RAC standby database. Check log_archive_dest_n parameter on primary database. If connect string in this parameter contains addresses of all RAC instances of standby, make sure that all instances are in mount or open state. 
• Check if password file on standby instance(s) is copied from primary database. This is one of the most common mistakes done by the DBAs. They change sys password on primary, and forget to copy it over to the standby database host. DBAs must copy password file if any change in sys password is done on primary database. Password file should be copied to all nodes in case of RAC.

Related Articles

• ORA-12514 During Switchover to Standby
• Heartbeat failed to connect to standby. Error is 16009
• ORA-00313 ORA-00312 ORA-17503 ORA-15173 in Standby Alert Log File
• Error 1017 received logging on to the standby - Along with ORA-16191
• Error 1031 received logging on to the standby
• Error 12154 received logging on to the standby