Friday, January 30, 2009

Goodbye ORA-600, hello, Blue Gecko

Things are changing a little around here. I have been running ORA-600 Consulting for five years, and have made the big decision to join Blue Gecko, a remote administration and managed hosting provider here in Seattle. My new colleagues look familiar. They are the same people that I worked with in the first several years of building Amazon.com's IT infrastructure in the late 90s.

This was a big decision, but my direction increasingly has been toward teaching and emergency support. These happen to be two areas Blue Gecko is excited to build on. So I will continue my focus in these two areas with the support of a great company. Best of all, I will no longer have to be in charge of billing, accounting, sales and toilet cleaning duties for my own company. This should leave me more time to work on the Oracle topics I care about more.

I'm hoping my clients will all come over to Blue Gecko with me. They'll frankly get much better support from the 24x7 support staff and mature monitoring and administration infrastructure Blue Gecko provides. They can still ask for me if they want!

Friday, January 2, 2009

Log transport annoyance with ORA-01017 and ORA-16191

In 11g, setting up log transport for DataGuard, Streams, CDC, etc., you are likely to run into this annoyance. No matter how carefully you make the SYS passwords in the passwordfile the same byte-for-byte on both the source and destination hosts, the source archiver will fail trying to log in to the destination DB with these messages written to the alert log:

ORA-01017: invalid username/password; logon denied
ORA-16191: Primary log shipping client not logged on standby

The solution is to create the passwordfiles with orapwd using the argument 'ignorecase=y':

% orapwd file=orapwORCL password=crash_on_install ignorecase=y

This issue has been documented by several bloggers and forum participants, but there is still no note in Metalink as of today. I'm not sure what part of the codepath contains this bug or if perhaps this is one of those that would be addressed with the "not a bug" response from dev.

You will probably have found this article after following the instructions in the error documentation:

Check that primary and standby are using password files and that both primary and standby have the same SYS password. Restart primary and/or standby after ensuring that password file is accessible and REMOTE_LOGIN_PASSWORDFILE initialization parameter is set to SHARED or EXCLUSIVE.

Restart the primary. I love it :-) Jeez.

All I can say is I am sorry you went through this.