Oracle^® Business Intelligence Server Administration Guide > Clustering Oracle BI Servers >

Chronology of a Cluster Operation

This section provides an overview of the Oracle BI Cluster Server startup process.

1. As each Oracle BI Server starts, it reads its NQSConfig.INI file. If a server detects a syntax error while reading the file, it logs the error to its NQServer.log file in its Log directory. All syntax errors have to be corrected for startup to continue.
2. Each Oracle BI Server reads its NQClusterConfig.INI file and Scheduler file when CLUSTER_PARTICIPANT is set to YES in the NQSConfig.INI file. Cluster Controllers also read this file.
   • If a Oracle BI Server detects a syntax error while reading the file, it logs the error to its NQServer.log file.
   • If a Cluster Controller detects an error while reading the file, it logs the error to its NQCluster.log.
   • If a Scheduler detects an error while reading the file, it logs to NQScheduler.log.
   • If a machine is hosting both an Oracle BI Server and a Cluster Controller, messages will be written to both logs.
   • All syntax errors have to be corrected for startup to continue.
3. When an instance of Oracle BI Server or Scheduler starts up, it waits for a connection from the primary and secondary cluster controllers.
   • Oracle BI Server can run without the presence of a Cluster Controller service instance. However, no clustered ODBC connection can be made to Oracle BI Server if there is no running Cluster Controller service.
   • The Scheduler service will start but will remain in an inactive state until a Cluster Controller service instance comes online and notifies the Scheduler of a state change.
4. The primary and secondary Cluster Controllers begin to exchange heartbeat messages. (This step is omitted when no secondary Cluster Controller is defined.)
5. The Oracle BI Server verifies whether the repository publishing directory is available. If the repository publishing directory is not available, the action each server takes depends on the setting for the REQUIRE_PUBLISHING_DIRECTORY parameter in its NQSConfig.INI file.
   • When set to YES, if the publishing directory is not available at startup or if an error is encountered while the server is reading any of the files in the directory, an error message is logged in the NQServer.log file and the server shuts down.
   • When set to NO, the server joins the cluster, and a warning message is logged in the NQServer.log file. However, any online repository updates are not reflected in the server's Repository directory.
6. The primary and secondary Cluster Controllers begin to exchange heartbeat messages with each participant in the cluster.
   • The connection status is logged in the log files of the appropriate clustered instance (Scheduler or Oracle BI Server). Messages are also logged in the NQCluster.log file of the Cluster Controller.
   • Any participants with connection problems are not allowed to join the cluster.
   • If the server defined as the MASTER_SERVER for an online repository is not available, you cannot edit the repository in online mode.
7. As each Oracle BI Server in the cluster starts, it examines the repository publishing directory for any updated repositories. This is done by comparing the date and timestamps.

   NOTE:  The Oracle BI Server administrator is responsible for making sure that the time-of-day clocks are synchronized across all Oracle BI Servers and Cluster Controllers.

   • If a server detects a newer version of an existing repository, it copies the repository to its own Repository directory.
   • A server will not detect the presence of any new repositories. A new repository must be manually propagated to all clustered servers when it is created. After that, online changes are detected at subsequent startups of each server.
8. When the Cluster Controller assigns a session to a particular Oracle BI Server, the server communicates with the back-end database using the connection defined in the Connection Pool dialog box for the database. Clustered servers do not share a common connection pool. An ODBC session maintains affinity to one Oracle BI Server session for the lifetime of that session.
9. If an Oracle BI Server determines it can satisfy all or a portion of a query from its cache file, it will do so. Clustered servers do not share a common cache. Clustered servers do not share common ad-hoc query cache. They can share cache for seeded queries, if each server instance is configured to do so.