Today was my first day back in the office after last week’s SAP Insider BI2012 conference in Las Vegas. The conference occurred in the middle of building my customer’s QA cluster for SAP BusinessObjects Business Intelligence 4.0. QA is our first clustered environment – all of the lesser environments are single-node virtual machines. The QA cluster is intended to be a mirror image of our future production cluster: two Tomcat servers with a load balancing switch, two CMS nodes, and four non-CMS nodes running various processing and job services. Before going to the conference, I installed and configured one Tomcat server and one CMS node. So the system was 100% functional, but not in its final size or configuration.
So today I started installing the second CMS node. Custom / Expand install type – check. Change the default drive letter – check. Clear the web tier, integrated database, and Subversion checkboxes – check. Everything was going according to plan until I entered the Oracle 11g credentials for the CMS database.
Cannot Verify Database login information. (INS00104)
Seriously? OK, maybe it’s a typing error?
If you’re able to connect and verify with SQL Plus or another test, remove special characters (specifically dollar signs) from the password on the Oracle DB. We’re not properly escaping them. This should be fixed in service release 3 for BI4.
The database password doesn’t include any special characters, but my fear during this project is that somewhere out there is a bug waiting to derail my project. A bug that won’t be fixed until Feature Pack 3. Could this be the one?
Our operating system is Windows 2008, not Linux. So what the heck. I re-booted the server and took a few minutes to re-boot my head. Then I re-read the installation run book from the first CMS node.
The first CMS node was built with a generic tnsnames.ora entry I had created called SAPBISYSTEM. It was identical to the one provided by the Oracle DBA that used the server name as the system name. Even though the details underlying the two entries were identical, the installation program didn’t know that. It apparently also didn’t know to say “Rough time in Vegas? Why don’t you try using the same Oracle system name as the first node?” Once I entered the same Oracle system name as the first node, the second node’s installation proceeded as normal.
I wrote this short post so you won’t make the same mistake as me. Today’s experience made me glad that I had taken time to document each installation step with both screen shots and written assumptions.
Make sure your multi-node installations are identical in every detail. But especially with CMS database parameters.
Don’t fluster the cluster.