Error 1017 received logging on to the standby

I have got frequently the error «Error 1017 received logging on to the standby», while trying to enable the archivelog transfer between primary and standby.
The majority of tips on the net and the entry in the alert.log would tell You:
— check Your remote_login_passwordfile — should be SHARED or EXCLUSIVE
— check Your password file — it should exist and a password for SYS should be the same.
I have done as suggested, still no progress.

The solution was actually trivial — just copy the password file from the primary to the standby. Not sure why previously it did not work — I am sure the SYS password was the same and I checked connection in both directions (i.e. PRIMARY->STANDBY, STANDBY->PRIMARY) using the same entries in tnsnames.ora as specified in the archivelog transfer configuration.

It seems, there is a huge difference between versions 10g and 11g in this case — previously it was enough to create new password file with the same password. Now it must be the same file (ie. copy from the original on the primary).

And here is a very good article on the password files in Data Guard environment.

Hi Guys,

  Here is an Interesting case and  I was stuck with the problem since last 2 days and a half. In fact I was almost done with everything to resolve the mentioned problem but I could not able to solve almost.

Then I left it as I became exhausted, But I kept on thinking Where could be the problem, at last I got it.

Here was my case:
———————

  I have 2 node rac as primary and a standby was intended to create on single node.

   I changed parameter file, created passwords, tns entries accordingly. Then I did duplicate target and restored database as standby. After doing everything I saw, RAC node1 was able to send archive logs to dest_2 which is my standby but unfortunately node2 was unable to enter into standy database.

Here are

Problem Statement:
—————————-

Standby was receiving node1’s log files but node2 was unable to send logfiles due to the below error

Error 1017 received logging on to the standby
————————————————————
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.

Steps for diagnosing
—————————-
step-1
 when I checked  query on node 2

sql>select DEST_ID,DEST_NAME,STATUS,BINDING,ERROR from v$ARCHIVE_DEST where status<>’INACTIVE’;

all log file location were valid

Sql> SELECT DESTINATION, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID=2;

dest2 for archive log dest is valid

sql> select error_code,message from v$dataguard_status;

Error 1034 received logging on to the standby

PING[ARC2]: Heartbeat failed to connect to standby ‘STBYDB’. Error is 1034.

Then I have done the below steps to resolve the problem

1.) alter system set  log_archive_dest_state_2=defer scope=both sid=’*’;

  (on primary RAC any node )

   Sql>recover managed standby database cancel;    (on standby side)

2) alter database set SEC_CASE_SENSITIVE_LOGON=FALSE scope=both sid=’*’;

 (on RAC side)

3) shutdown the standby database infact if possible primary also
then remove password files for all primary rac nodes and standby nodes and then created the password file on their respective server

orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=system entries=5 force=y ignorecase=Y

 Then start the primary db (rac nodes by srvctl start database -d primaryDB )

4) alter system set LOG_ARCHIVE_DEST_2=’SERVICE=STBYKOL ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STBYDB’ scope=both sid=’*’;

 (on any primary rac node and standby db)

5) alter system set  log_archive_dest_state_2=enable scope=both sid=’*’; (on any primary RAC node)

 6) recover standby database using current logfile disconnect; (on standby database)

After doing this I observed the alert log  and it worked

To check the database  syncing

on both side check the command

sql>select current_scn from v$database;

The value of primary and standby would be almost same

Hope It will help you guys

If any query don’t forget to mail me at viewssharings.blogspot.in@gmail.com

If you are working in a standby environment this is a quite common error that you will see in the alert log. There are various situations when you will see this error.Although you have a latest copy of password file copied in both PRIMARY and STANDBY DB, there is a chance that you will see this error. This is a generic error that comes to oracles’s mind and warns you about it.

Fetching gap sequence in thread 1, gap sequence 44212-44255
Error 1017 received logging on to the standby

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

————————————————————

FAL[client, USER]: Error 16191 connecting to ORCL for fetching gap sequence
Archived Log entry 5 added for thread 1 sequence 44257 rlc 839361298 ID 0xa5d555eb dest 2:
Tue Jan 19 12:03:39 2013
Archived Log entry 6 added for thread 1 sequence 44260 rlc 839361298 ID 0xa5d555eb dest 2:
Tue Jan 19 12:03:41 2013
Archived Log entry 7 added for thread 1 sequence 44259 rlc 839361298 ID 0xa5d555eb dest 2:
Tue Jan 19 12:03:42 2013
RFS[5]: Opened log for thread 1 sequence 44261 dbid -1517523940 branch 839361298
Tue Jan 19 12:03:43 2013
Error 1017 received logging on to the standby

————————————————————

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

SOLUTION :

1. Copy the latest copy of PASSWORD file from PRIMARY instance to STANDBY instance and replace it with the old one. 

Usually password file is in format of  ORAPWDINSTANCENAME

example : ORAPWDORCL (where ORCL is my instance name).

2. Check if the PASSWORD FILE is set to either EXCLUSIVE mode or SHARED.

3. Test if you can connect to both PRIM and STANDBY as SYSDBA using password.

Note :

IF you don’t know the password for SYS, you can recreate password file using this link.

~ Troubleshoot ORA-16191: ORA-17629 with case studies in Active Dataguard ( Oracle 11g)
~ Troubleshoot : when standby server is out of synch
~ Troubleshoot : when archivelogs are not applying in standby side

Case:1:  ORA-16191

Error 1017 received logging on to the standby ( message fro alert log)
< ————————————————————
< 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
< ————————————————————
< PING[ARC2]: Heartbeat failed to connect to standby ‘STANDBY’. Error is 16191.
< Sat Jul 06 15:23:28 2013
< Error 1017 received logging on to the standby

If above error found from alert log in DR side, i.e., some body changed Primary sys password.

Solution: Recreate password file both Primary and DR side with same password and re-synch again.

Now do the following: e.g.,

SQL> alter database recover managed standby database cancel;
SQL> shut immediate;
SQL> startup nomount;
SQL> alter database mount standby database;
SQL> alter database recover managed standby database using  current logfile disconnect;

Case:2: : ORA-17627: ORA-01017

channel ORA_DISK_1: SID=33 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 06/27/2012 15:05:53
RMAN-03015: error occurred in stored script Memory Script
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 06/27/2012 15:05:53
ORA-17629: Cannot connect to the remote database server
ORA-17627: ORA-01017: invalid username/password; logon denied
ORA-17629: Cannot connect to the remote database server

Solution:

RMAN> duplicate target database for standby from active database nofilenamecheck;

This may not work. do the following

RMAN> run {
allocate channel ch1 type disk;
allocate auxiliary channel stby1 type disk;
duplicate target database for standby from active database nofilenamecheck;
}

Case-3 : ORA-16191

Thu Nov 14 10:52:35 2013
Error 1017 received logging on to the standby
————————————————————
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

Solution:

1) In primary side:

Ship missed archive logs:
pass the password file again to standby side and rename it with standy database name in standby side.

2) In standby side:
e.g.,
SQL> alter database recover managed standby database cancel;
SQL> alter database recover managed standby database disconnect from session;
RMAN> catalog start with ‘/oracle/PRIMARY/flash_recovery_area/archivelogs’;

Now check, sure archive logs will apply

Now you will find following type alerts in alert log file.

Thu Nov 14 12:17:07 2013
Media Recovery Log /oracle/PRIMARY/flash_recovery_area/archivelogs/1_7945_804801209.dbf
Thu Nov 14 12:17:34 2013
Media Recovery Waiting for thread 1 sequence 7946

Now do the following:


SQL> alter database recover managed standby database cancel;
SQL> shut immediate;
SQL> startup nomount;
SQL> alter database mount standby database;
SQL> alter database recover managed standby database using  current logfile disconnect;

Now sure it will start shipping

SQL> select max(sequence#) from v$archived_log where applied=’YES’;


MAX(SEQUENCE#)
—————
          7951

Hope this document will help you.
Post your comments.