I have a strange behavior with a Data Guard environment on Linux and Oracle 220.127.116.11. Since a couple of days, I have the following error in the alertlog of the standby database:
Errors in file /u00/app/oracle/diag/rdbms/SID_site2/SID/trace/SID_pr0f_22728.trc:
ORA-17627: ORA-01017: invalid username/password; logon denied
ORA-17629: Cannot connect to the remote database server
First I restarted the Apply on the standby without any changes. So I tried to connect to the primary database from the standby server with Oracle .Net with success. In the other way, it's also working.
I also tried to copy the password file from the primary server to the standby server and I restarted both the transport and the apply.
The error is still happening on the standby but the most surprising is that the Data Guard is still fully synchronized.
Why I get that error and what is the function of the process pr0f?
How can I resolve that issue?
Check this thread out:
When in doubt check the password file. Move a copy to the Standby, rename it and restart the database on the new password file.
Also make sure this parameter is set like this on both servers :
Thanks for your answer.
As mentioned, I've already copied the password file from the primary to the standby and then I restarted both transport and apply without success.
On both servers I have checked that remote_login_passwordfile is set to 'EXCLUSIVE'
I had a look on the other thread but it seems related to RMAN and RMAN is not involved in my case.
It's just when apply is started
The password file must be renamed and the database restarted on the new password file.
It's not clear if you have done if these pieces, just the apply.
Example on mine :
So this /u01/app/oracle/product/18.104.22.168/dbs/orapwPRIMARY
Move here and is renamed as follows :
Perform the Standby bounce and restart recovery.
I would also try a connect as sys from both sides.
The databases have the same name on both servers so there is no need to rename the password file.
The password file is located in $ORACLE_HOME/dbs as it should
I restarted again the database and restarted apply process but same error again, when the first redo is applied the error happens.
I already tried to connect as sys through the network with the password in both ways
sqlplus sys@SID_SITE1 as sysdba works well if I use the correct password and does not work with a wrong password.
sqlplus sys@SID_SITE1 does not work whatever password I use
sqlplus sys@SID_SITE2 as sysdba works normally (with the right password it's fine)
sqlplus sys@SID_SITE2 does not work because the database is in mount state
I agree that the error seems clear but i'm not very sure that I have password issue.
The SYS account is not locked on primary
SQL> select username, account_status from dba_users where username = 'SYS';
As already tested I can connect as sysdba on the primary from the standby and the other way is also working.
This is key:
"As already tested I can connect as sysdba on the primary from the standby and the other way is also working."
Because it probably won't bite you later. Generally this are errors seen with RMAN and RMAN duplicate. If they keep occurring I would consider chasing with Oracle support.
The connect test from both sides is important. Until you can do that something is not right.
Sorry, I did't had much time and as Data Guard is success it is not urgent.
I really tested connections in all possible ways.
I'm sure that it's not a password issue.
I checked the trace file and I have the following strange message:
Logged on to standby successfully
krsd_get_primary_connect_string: found pcs 'SID_SITE1' by FAL_SERVER lookup
The standby is trying to connect to the primary database
Check the below Bug in MOS, I found it with the function name "krsd_get_primary_connect_string"
Bug 11809377 : AUTO BLOCK MEDIA RECOVERY IS CAUSING PASSWORD ERRORS ON PHYSICAL STANDBY
It appears you have corrupted blocks in your standby database.