We hit a very interesting problem in our Production environment recently. We’d made no changes for a long time to the configuration, but all of a sudden users were on the phone complaining. They could login to BI from EBS but after logging in the next link they clicked took them to the OBIEE “You are not logged in” screen. Our users login to EBS R12 and then using EBS authentication log in to OBIEE (10.

A very interesting new PDF from Sun on deploying OBIEE has been published, with discussions on architecture, performance and best practice. This Sun BluePrints article describes an enterprise deployment architecture for Oracle Business Intelligence Enterprise Edition using Sun servers running the Solaris Operating System and Sun Storage 7000 Unified Storage systems. Designed to empower employees in organizations in any industry—from customer service, shipping, and finance to manufacturing, human resources, and more—to become potential decision makers, the architecture brings fault tolerance, security, resiliency, and performance to enterprise deployments.

Production cluster is 2x BI Server and 2x Presentation Services, with a BIG-IP F5 load balancer on the front. Symptoms Users started reporting slow login times to BI. Our monitoring tool (Openview) reported that “BIServer01 may be down. Failed to contact it using ping.”. BIServer01 cannot be reached by ping or ssh from Windows network. Diagnostics nqsserver and nqsclustercontroller on BIServer01 was logging these repeated errors: [nQSError: 12002] Socket communication error at call=send: (Number=9) Bad file number

Here’s a set of scripts that I use on our servers as a quick way to check if the various BI components are up and running. Because we split the stack across servers, there are different scripts called in combination. On our dev boxes we have everything and so the script calls all three sub-scripts, whereas on Production each server will run one of: BI Server Presentation Server & OAS Informatica & DAC The scripts source another script called process_check.

Follow on from setting up Publisher in a clustered environment, I’ve found a nasty little bug in the scheduling element of Publisher, Quartz. Looking at the oc4j log file /opmn/logs/default_group~home~default_group~1.log I can see OC4J starting up, and then a whole load of repeated messages: 09/03/30 11:28:43 Oracle Containers for J2EE 10g (10.1.3.3.0) initialized - ClusterManager: detected 1 failed or restarted instances. - ClusterManager: Scanning for instance “myserver.fqdn.company.net1238408921404”’s failed in-progress jobs.

The Oracle BI Publisher Enterprise Cluster Deployment doc which I just found through Metalink highlighted a couple of points: - Report repository should be shared - The scheduler should be configured for a cluster Report Repository Through Admin>System Maintenance>Report Repository I changed the path from the default, /xmlp/XMLP to a NFS mount data/shared/xmlp and restarted the xmlpserver application in OAS. On coming back up Publisher complained because all its config files (in xmlp/Admin), had disappeared.

I’m setting up a clustered OBIEE 10.1.3.4 production environment. There are four servers; two BI Server + Cluster Controller + Scheduler and two OAS + Presentation Services + Publisher. Clustering of BI is configured, now I’m setting up the other bits. Today is Publisher. On publisher instance A connections to the BI Servers directly work fine: jdbc:oraclebi://serverA.fqdn.company.net:9703/ jdbc:oraclebi://serverB.fqdn.company.net:9703/ both work individually as Connection Strings (with database driver class of oracle.bi.jdbc.AnaJdbcDriver) - verified with “Test Connection” button.