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 :
process pr0f are only Started Parallel Media Recovery processes
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
Does this mean I have several prXf processes started?
Only one is failing because all errors concern pr0f process
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/126.96.36.199/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
You show this error:
ORA-17627 ORA-01017 invalid username/password
Generally errors like this are fairly clear. I would check my SYS user:
USERNAME = 'SYS';
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.
Could you please check whether db_unique_name is specified in the log_archive_dest_2 parameter in primary.
I had the same sort of problem where primary couldn't connect to the standby but once after specifying db_unique_name, the problem solved.
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.
thank you. I found a corrupted block in the standby database with RMAN command validate backup check logical.
I disabled the apply and made a block recover.
When I restarted the apply the error did't come back.