While installing Golden Gate for mysql replication I ran into two issues which, while documented, were buried in the books so I didn't see them. Maybe this will help someone.
1. be sure your socket file is in /tmp or you have a sym link from tmp. Golden gate only looks here so if no socket, no connection. Now that's just plain wrong.
2. Golden gate needs row based replication not function based. That means you're stuck with some post 5.1.x release which maybe won't be an issue but forced us to do an in-place upgrade. Don't ask.
Sunday, August 25, 2013
Thursday, May 16, 2013
oracle dataguard reports ORA-01017: invalid username/password; logon denied
Wow, there are a ton of these on the web, so why post one more. Because we hit an issue which I did not find and which hopefully will help someone in the future.
In setting up dataguard on our 11g system we got the following errors after
connect /
show configuration
Configuration Status:
ORA-01017: invalid username/password; logon deniedORA-16625: cannot reach database "" DGM-17017: unable to determine configuration status
OK, this seems simple enough. Our password file must be the problem. After searching, regenerating the password file, and pulling out our hair we found this in our oracle parameters:
redo_transport_user string SYSTEM
which means, that dataguard will use SYSTEM as the connection to the database and not SYS. Now, that's interesting but it gets more interesting.
If you generate the password file using orapwd it is likely you won't find SYSTEM in the file and that is required for dataguard to work. In other words, merely creating the password file using orapwd and copying it to your standby site does not guarantee that it will work.
Why? This is because with 11g a system grant such as
grant sysoper to SYSTEM;
gets written to the password file but if you come along and generate the file using orapwd you will lose this entry.
So, make certain your password file contains the correct user with sysoper privileges for dataguard to work. You can use this query together with the redo_transport_user parameter to verify all is well.
select * from v$pwfile_users;
If the user in the redo_transport_user is not in this list and does not have sysoper you won't be able to connect and you will get the ORA-01017 error.
Good luck.
In setting up dataguard on our 11g system we got the following errors after
connect /
show configuration
Configuration Status:
ORA-01017: invalid username/password; logon deniedORA-16625: cannot reach database "
OK, this seems simple enough. Our password file must be the problem. After searching, regenerating the password file, and pulling out our hair we found this in our oracle parameters:
redo_transport_user string SYSTEM
which means, that dataguard will use SYSTEM as the connection to the database and not SYS. Now, that's interesting but it gets more interesting.
If you generate the password file using orapwd it is likely you won't find SYSTEM in the file and that is required for dataguard to work. In other words, merely creating the password file using orapwd and copying it to your standby site does not guarantee that it will work.
Why? This is because with 11g a system grant such as
grant sysoper to SYSTEM;
gets written to the password file but if you come along and generate the file using orapwd you will lose this entry.
So, make certain your password file contains the correct user with sysoper privileges for dataguard to work. You can use this query together with the redo_transport_user parameter to verify all is well.
select * from v$pwfile_users;
If the user in the redo_transport_user is not in this list and does not have sysoper you won't be able to connect and you will get the ORA-01017 error.
Good luck.
Subscribe to:
Posts (Atom)