A call today from one of my friend regarding switchover issue, once the role swap has been performed the standby (current primary) is not able to ship the redo log files.
Verification:-
1) v$managed_standby in production(current standby) stucks at sequence “waiting for log”
2) Trace files shows
Redo shipping client performing standby login
OCISessionBegin failed -1
.. Detailed OCI error val is 1017 and errmsg is 'ORA-01017: invalid username/password; logon denied
'
OCISessionBegin failed. Error -1
.. Detailed OCI error val is 1031 and errmsg is 'ORA-01031: insufficient privileges
'
OCISessionBegin failed. Error -1
.. Detailed OCI error val is 1031 and errmsg is 'ORA-01031: insufficient privileges
3) ORA-16191
As usual, its a password file issue, we have done
1) Recreated the password file – no luck
2) Copied the password from standby (current primary) to production (current standby)
But no luck,
After a lot of scratching, got that the database is running 11gR2, apparently my doubt turns to password case sensitive,
1) deleted the password files
2) created the password file with ignorecase=y using orapwd
orapwd file=orapwdgstby entries=100 password=***** ignorecase=y
Viola, this time its worked…….. standby sync resumed. So you will have to use ignorecase=y option for 11g password files as they turned to case sensitive now.
Just for all your information , if you are also may sail in same boat.
-Thanks
Geek DBA
Hi Geek DBA,
It’s awesome. I know many people would face the same issue. I was really scratching my head, tried all the possibilities like copying the password files across DR and PRIMARY, creating separate files with same password, used FORCE=y in password files, googled etc.Only one option left with me is disturbing you over weekend. With this solution everything went smooth.
Guys this helped me a lot.
Thanks a lot Geek DBA
Hi Kranthi,
You are welcome ! Thanks been commenting here around and sharing this issue too.
-Thanks
Geek DBA
Thanks a lot
After recreating the password with ignore case, it worked for me as well
The strange thing is from primary Node 1 log shipping was working.
From primary Node 2 it was failing with insufficient privileges.
Regards
Vijeesh