6 Deploying Oracle Business Intelligence for High Availability

This chapter provides information about how to configure Oracle Business Intelligence components for high availability. It also describes the functionality available in Fusion Middleware Control to manage system availability, and provides information about using the Cluster Manager in the Administration Tool.

This chapter does not provide information about setting up additional high availability configuration for other components in the stack, including database tier, Web tier, Administration Server, and identity management availability. For more information about these topics and how they relate to Oracle Business Intelligence deployments, see the following documents:

This chapter contains the following sections:

6.1 About Oracle Business Intelligence Components in a Clustered Environment

Figure 6-1 shows the system components and Java components in a highly available Oracle Business Intelligence deployment. See Section 1.4, "About Oracle BI Java Components and System Components" for more information about system components and Java components.

Figure 6-1 A Highly Available Oracle Business Intelligence Deployment

Description of Figure 6-1 follows
Description of "Figure 6-1 A Highly Available Oracle Business Intelligence Deployment"

In Figure 6-1, the Oracle Business Intelligence Java components are deployed on the BI_SERVER1 and BI_SERVER2 Managed Servers on APPHOST1 and APPHOST2. These Managed Servers are configured in an Oracle WebLogic cluster.

Oracle BI Presentation Services, JavaHost, Oracle BI Cluster Controller, Oracle BI Scheduler, and Oracle BI Server are system components installed on APPHOST1 and APPHOST2 and configured as a cluster. The Cluster Controller and Oracle BI Scheduler on APPHOST2 are passive (they are started but do not service requests) and are only made active if APPHOST1 components fail.

In the data tier, shared external storage is configured to store the Oracle BI Presentation Catalog, Oracle BI Server global cache, Oracle BI repository, and Oracle BI Scheduler script data.

6.1.1 Recommendations for Availability

In a production system, it is recommended that you deploy two or more instances of every component on two or more computers, so that each component type has an instance running on more than one computer for fault tolerance. This configuration provides redundancy for Managed Servers and system components, an essential requirement for high availability and failover. You can see whether the system has any single points of failure by using the Availability tab of the Capacity Management page in Fusion Middleware Control. See Section 6.1.2, "Using Fusion Middleware Control to Identify Single Points of Failure" for more information.

You can also ensure high availability by configuring redundancy in the database tier (Oracle RAC recommended), Web tier, and for the Administration Server. See "Configuring Oracle Business Intelligence for High Availability" in Oracle Fusion Middleware High Availability Guide for more information.

Note also the following requirements:

  • All Oracle BI Servers participating in the cluster must be within the same domain and on the same LAN subnet. Geographically separated computers are not supported.

  • The clock on each server participating in a cluster must be kept in synchronization. Out-of-sync clocks can skew reporting.

6.1.2 Using Fusion Middleware Control to Identify Single Points of Failure

Before you begin this procedure, ensure that you are familiar with the information in Section 3.2, "Using Fusion Middleware Control to Update Oracle Business Intelligence Configuration Settings."

To identify single points of failure:

  1. Go to the Business Intelligence Overview page, as described in Section 2.2.2, "Using Fusion Middleware Control to Manage Oracle Business Intelligence System Components."

  2. Display the Availability tab of the Capacity Management page.

    On this page, you can view recommendations about whether to scale out system components or configure primary/secondary system components.

    Click the Help button on the page to access the page-level help for its elements.

  3. If you must scale out the Oracle BI Server, Oracle BI JavaHost, or Oracle BI Presentation Services, then you can click Scale Out Selected in the Single Points of Failure section to go to the Scalability tab to scale out a system component. See Section 5.5, "Using Fusion Middleware Control to Scale System Components" for more information.

  4. If you have a Cluster Controller or Oracle BI Scheduler that must be configured, the Single Points of Failure table displays the message "Configure Primary/Secondary." See Section 6.2.1, "Using Fusion Middleware Control to Configure Primary and Secondary Instances" for information about how to do this.

6.2 Configuring Oracle Business Intelligence Components for High Availability

To configure Oracle Business Intelligence for high availability, you must ensure that the system has no single points of failure by scaling out the Oracle BI Server, Presentation Services, and the JavaHost so that you have at least two of each component type, distributed across at least two computers.

You also must configure primary and secondary instances of the Cluster Controller and Oracle BI Scheduler, so that the primary and secondary instances for each component type are distributed across two different computers.

Table 6-1 lists the tasks you must perform to configure high availability for Oracle Business Intelligence.

Table 6-1 Task Summary for Configuring High Availability

Task Where to Go for More Information

Horizontally scale out the Oracle Business Intelligence deployment so that it includes two computers with a full set of Java and system components on each host. This task includes running the Oracle Business Intelligence installer, configuring shared files and directories, and scaling out system components using Fusion Middleware Control.

Section 5.3, "Horizontally Scaling Oracle Business Intelligence"

Configure primary and secondary instances of the Cluster Controller and Oracle BI Scheduler.

Section 6.2.1, "Using Fusion Middleware Control to Configure Primary and Secondary Instances"

Verify that the new components are available.

Section 5.6.1, "Using Fusion Middleware Control to View System Component Availability"

6.2.1 Using Fusion Middleware Control to Configure Primary and Secondary Instances

You can use Fusion Middleware Control to configure primary and secondary instances of the Cluster Controller and Oracle BI Scheduler.

Figure 6-2 shows the Availability tab of the Capacity Management page.

Figure 6-2 Availability Tab of Capacity Management Page in Fusion Middleware Control

Description of Figure 6-2 follows
Description of "Figure 6-2 Availability Tab of Capacity Management Page in Fusion Middleware Control"

Before you begin this procedure, ensure that you are familiar with the information in Section 3.2, "Using Fusion Middleware Control to Update Oracle Business Intelligence Configuration Settings."

To configure primary and secondary instances of the Cluster Controller and Oracle BI Scheduler:

  1. Go to the Business Intelligence Overview page, as described in Section 2.2.2, "Using Fusion Middleware Control to Manage Oracle Business Intelligence System Components."

  2. Display the Availability tab of the Capacity Management page.

    On this page, you can configure primary and secondary instances of the Cluster Controller and Oracle BI Scheduler.

    Click the Help button on the page to access the page-level help for its elements.

  3. Click Lock and Edit Configuration to allow changes to be made.

  4. In the Primary/Secondary Configuration section, select the host and Oracle instance on which you want to run the primary or secondary Cluster Controller or Oracle BI Scheduler.

  5. Click Apply, then click Activate Changes.

  6. Return to the Business Intelligence Overview page and click Restart.

For information on using methods in the Oracle BI Systems Management API to manage availability, see Chapter 30, "Introducing the Oracle BI Systems Management API."

6.3 How Do Oracle Business Intelligence Components Provide Availability?

This section provides information about how the Oracle Business Intelligence components interact with each other in a clustered environment, and explains how Oracle Business Intelligence ensures availability for each component type.

6.3.1 About the Cluster Controller

The Cluster Controller serves as the first point of contact for new requests from Oracle BI Presentation Services and other clients of the Oracle BI Server. The Cluster Controller determines which Oracle BI Server in the cluster should receive incoming requests, based on Oracle BI Server availability and load. It monitors the operation of servers in the cluster, including the Oracle BI Scheduler instances, and is the first point of contact for requests to Oracle BI Scheduler.

The Cluster Controller supports the detection of server and Oracle BI Scheduler failures, and failover for ODBC clients of failed servers. It also determines the active Oracle BI Scheduler instance at run time.

The Cluster Controller is deployed in an active/passive configuration. The Primary Cluster Controller is the active controller, while the Secondary Cluster Controller assumes the role of the Primary Cluster Controller if the primary controller is unavailable. By default, the first Cluster Controller that is configured in your Oracle Business Intelligence installation is the Primary Cluster Controller.

Note that Presentation Services instances are not controlled by the Cluster Controller.

6.3.1.1 What if the Cluster Controller Fails?

The Cluster Controller supports detection of Oracle BI Server or Oracle BI Scheduler failures and failover for clients of failed servers.

The Cluster Controllers work on an active-passive model. All clients first attempt to connect to the Primary Cluster Controller. If the Primary Cluster Controller is unavailable, clients then connect to the Secondary Cluster Controller. The Secondary Cluster Controller then directs requests to Oracle BI Server instances based on load and availability, and to the primary Oracle BI Scheduler instance. If the Primary Cluster Controller becomes available, then all requests go to the Primary again.

The Secondary Cluster Controller monitors the session count on each Oracle BI Server, but does not dictate the active Oracle BI Scheduler unless the Primary Cluster Controller is down.

The Primary and Secondary Cluster Controllers monitor each other's life cycle. This is susceptible to a "Split-Brain" failure if the communication is down between the Cluster Controller instances, but each is up and can communicate with the other clients. In these cases, Oracle BI Servers are not affected, but the Oracle BI Scheduler might have two active instances at once. In rare cases, this might lead to double execution of jobs. When the line of communication comes back up, the Primary Cluster Controller will dictate to the cluster that only one Oracle BI Scheduler should be active. The possibility of a Split-Brain failure to occur is minimized by the fact that the Cluster components must exist on the same Local Area Network (LAN).

If both Cluster Controllers are unavailable, then Presentation Services will return an error to any new user attempting to log in. Existing sessions are not affected.

6.3.2 About Clustered Oracle BI Servers and the Master BI Server

The Oracle BI Cluster Server feature enables multiple Oracle BI Servers to act as a single server. Oracle BI Servers in the cluster share requests from multiple Oracle Business Intelligence clients.

One of the clustered Oracle BI Servers is designated as the Master BI Server. The Administration Tool connects to the master Oracle BI Server for online repository changes, using an Oracle BI ODBC DSN connection that is configured for the clustered environment. These metadata changes are then propagated to the other servers. Each slave server consumes the modified repository file when it next restarts.

In the NQClusterConfig.INI file, the parameter MASTER_SERVER specifies the Oracle BI Server that functions as the master server. You can also view which Oracle BI Server is the master using the Cluster Manager in the Administration Tool.

The Cluster Controller dispatches requests from clients such as Presentation Services to an active member of the Oracle BI Server cluster. The Oracle BI Server listens for client requests on a port assigned from the port range that is defined in the Scalability tab of the Capacity Management page in Fusion Middleware Control.

All Oracle BI Servers participating in a cluster can optionally share a common repository publishing directory. It holds the master copies of repositories that are edited in online mode. The clustered Oracle BI Servers examine this directory upon startup for any repository changes. The directory typically resides on a shared file system visible to all servers in the cluster. You must configure the following access to this publishing directory:

  • The master server must have read and write access.

  • All slave servers must have read access.

In Fusion Middleware Control, the Shared Location parameter on the Repository tab of the Deployment page specifies the location of the repository publishing directory.

6.3.2.1 What if a Clustered Oracle BI Server Fails?

The following are expected responses from Oracle BI Server clients during a clustered Oracle BI Server failure:

  • Presentation Services

    Each Web user of Oracle Business Intelligence has requests served by one Oracle BI Server instance. If this Oracle BI Server becomes unavailable, then the user might see an error, but a browser refresh will cause a new session to be established with an available Oracle BI Server. Note that the Presentation Services component itself performs this arbitration on behalf of its users.

  • Administration Tool

    The Administration Tool relays the ODBC error when the Oracle BI Server to which it is connecting becomes unavailable, and then closes the connection. The administrator must then reconnect.

  • Agents

    When Oracle BI Server failure occurs, the error is relayed to the Oracle BI Scheduler, which logs the failure and retries the job. This causes a connection to be established with an available Oracle BI Server instance.

  • Third-Party Clients

    Third-party clients use ODBC to connect to the Oracle BI Server. When Oracle BI Server failure occurs, the error is relayed and the session closed and reopened according to the ODBC standard.

6.3.2.2 What if the Master BI Server Fails?

The following results occur if the Master BI Server fails:

  • If the Master BI Server is unavailable, then online metadata changes cannot be performed using the Administration Tool. This is an administration operation and does not impact run-time availability. Read-only access from other Oracle Business Intelligence components is unaffected, because the other components can use the slave servers.

  • If the Master BI Server is permanently unavailable, then one of the other servers must be appointed as the new master, as follows:

    • Scale in the Master BI Server using the Scalability tab of the Capacity Management page in Fusion Middleware Control.

    • Restart the Oracle Business Intelligence system components.

      A new Master BI Server is assigned by the system.

6.3.3 About Clustered Oracle BI Scheduler Instances

Oracle BI Scheduler instances participate in the Oracle BI Cluster Server feature in active/passive mode. The active Oracle BI Scheduler instance processes jobs and executes agent requests. The passive Oracle BI Scheduler remains idle and does not process jobs until called on to take over in the event of an active Oracle BI Scheduler failure.

Oracle BI Scheduler listens for Cluster Controller communication and for client requests on ports assigned from the port range defined in the Scalability tab of the Capacity Management page in Fusion Middleware Control.

Note the following about Oracle BI Scheduler communication with other components:

  • Oracle BI Scheduler communicates with Presentation Services for jobs such as agents that deliver alerts and reports to users. Connections for each unique user session of the agent are load balanced in round robin fashion.

  • Oracle BI Scheduler is configured to communicate with the JavaHost instances in the cluster. Round robin load balancing is done for Java jobs and JavaHost extensions to agents.

6.3.3.1 What if an Oracle BI Scheduler Instance Fails?

Oracle BI Scheduler instances are monitored and managed by the Cluster Controller. If the primary Oracle BI Scheduler instance is unavailable, then the Cluster Controller activates the secondary Oracle BI Scheduler instance. If the previous primary Oracle BI Scheduler becomes available again, then the primary role does not revert.

When the primary Oracle BI Scheduler fails, any open client connections do not receive an error as the Oracle BI Scheduler protocol is stateless and seamlessly fails over.

  • Agents

    Agent executions maintain state in the Oracle BI Scheduler tables. When the next instance of Oracle BI Scheduler becomes active, it reads the state of all scheduled job instances that were in progress, and executes them. A scheduled agent delivers only to those recipients that it did not deliver to before the failure of the active instance.

    Successful delivery is recorded in the Oracle BI Scheduler tables after completion of the delivery. If Oracle BI Scheduler fails over after delivery is complete, but before recording that fact, then the delivery is repeated. Because of this, a small number of repeat deliveries are possible.

    Note that agent failover is supported only for agents that are scheduled. For example, if you click Run Agent Now on the toolbar in Answers, and then the primary Oracle BI Scheduler fails, then that agent does not continue to run on the Secondary Scheduler.

  • Java, Command Line, or Script Job

    The jobs are re-executed from the beginning with a new job instance.

    Note:

    Any job instance can be manually re-run from the Job Manager. For an agent, this delivers only to those users that did not have successful deliveries. For example, if the mail server goes down halfway through an agent's execution, the re-run of the instance delivers only to those recipients who did not receive e-mail due to the mail server crash.

    See Chapter 26, "Using Oracle BI Scheduler Job Manager" for information about Job Manager.

6.3.4 About the Oracle BI Cluster Server

The Oracle BI Cluster Server is comprised of the Cluster Controller, Oracle BI Server, and Oracle BI Scheduler components. All components of the BI Cluster Server feature must reside on the same Local Area Network (LAN).

You can use the Cluster Manager to monitor and manage the operations and activities of the Oracle BI Cluster Server. You can also use it to enable or quiesce Oracle BI Server clustered instances, and to manually activate the secondary Oracle BI Scheduler instance. The Cluster Manager is available in the Administration Tool when a repository is open in online mode.

6.3.4.1 About the Startup Process for the Cluster Server

The following list provides an overview of the Oracle BI Cluster Server startup process:

  1. As each Oracle BI Server starts, it reads its NQSConfig.INI file and the centrally-managed parameters that are set in Fusion Middleware Control. If a server detects a syntax error while reading the NQSConfig.INI file, then it logs the error to its nqserver.log file. All syntax errors must be corrected for startup to continue.

  2. Because Oracle Business Intelligence is deployed in a clustered configuration by default, each Oracle BI Server and Oracle BI Scheduler instance reads the local NQClusterConfig.INI file upon startup, even if only one Oracle BI Server or Oracle BI Scheduler is deployed. Cluster Controllers also read this file.

    • If an Oracle BI Server detects a syntax error while reading the file, then it logs the error to its nqserver.log file.

    • If a Cluster Controller detects an error while reading the file, then it logs the error to its NQCluster.log.

    • If the Oracle BI Scheduler detects an error while reading the file, then it logs the error to nqscheduler.log.

    • If a computer is hosting both an Oracle BI Server and a Cluster Controller, then messages are written to both logs.

    • All syntax errors must be corrected for startup to continue.

  3. When an instance of the Oracle BI Server or Oracle BI Scheduler starts up, it waits for a connection from the Primary and Secondary Cluster Controllers.

    • The Oracle BI Server can run without the presence of a Cluster Controller instance. However, no clustered ODBC connection can be made to the Oracle BI Server if there is no running Cluster Controller service.

    • The Oracle BI Scheduler service starts, but remains in an inactive state until a Cluster Controller service instance comes online and notifies the Oracle BI 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, then the action each server takes depends on whether Share Repository has been selected in the Repository tab of the Deployment page in Fusion Middleware Control.

    • When Share Repository has been selected, 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, then an error message is logged in the nqserver.log file and the server shuts down.

    • When Share Repository has not been selected, the server joins the cluster and loads the repository from its default local directory. Any changes made to the repository using the Administration Tool only affect the Oracle BI Server component that is associated with the changed repository file.

  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 (Oracle BI 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, then 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 (when Share Repository has been selected in Fusion Middleware Control). This is done by comparing the date and timestamps.

    The administrator is responsible for ensuring 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, then it copies the repository to its own Repository directory.

    • A server does 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 data source using the connection that is defined in the Connection Pool dialog for the data source. 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 that it can satisfy all or a portion of a query from its cache file, then it does so. Clustered servers do not share a common cache. They can share cache for seeded queries, if each server instance is configured to do so.

6.3.4.2 Performance Considerations for the Cluster Server

The following list describes characteristics of the Cluster Server that might influence the performance of clustered Oracle BI Servers:

  • Sessions are assigned to an Oracle BI Server when the session is established. A session is assigned to the server with the fewest sessions.

  • Because each Oracle BI Server maintains its own local query results cache, data sources might receive the same query from multiple Oracle BI Servers, even though the result is cached. In addition, Oracle BI Servers that are brought online into an operational cluster might respond to queries more slowly while their local cache is being populated. If you use global caching, then queries that are explicitly seeded through a cache seeding agents are shared across nodes in the cluster.

  • Because each Oracle BI Server has an independent copy of each repository and therefore its own data source connection pools, data sources might experience as many as N*M connections, where N is the number of active servers in the cluster and M is the maximum sessions that are allowed in the connection pool of a single repository. Therefore, it might be appropriate to reduce the maximum number of sessions that are configured in session pools.

6.3.5 About Clustered Presentation Services Instances

Multiple Presentation Services instances can be configured to provide scalability and high availability.

Presentation Services receives requests from the Oracle BI Presentation Services Plug-in on a port that is assigned from the port range that is defined in the Scalability tab of the Capacity Management page in Fusion Middleware Control.

Although an initial user session request can go to any Presentation Services in the cluster, each user is then bound to a specific Presentation Services instance.

Clustered Presentation Services instances can either share a common Oracle BI Presentation Catalog on a shared file system, or the catalog can be replicated across the Presentation Services instances. See Chapter 18, "Configuring and Managing the Oracle BI Presentation Catalog" for detailed information on replicating the Oracle BI Presentation Catalog.

Presentation Services communicates with other components as follows:

  • Oracle BI Server: Presentation Services communicates with clustered Oracle BI Servers through the Cluster Controller to process user requests. Presentation Services uses the Oracle BI ODBC DSN that is configured for the clustered environment to identify the Primary and Secondary Cluster Controllers and the ports on which they listen. Presentation Services obtains the Oracle BI Server to which to connect from the Cluster Controller. The connection to the Oracle BI Server is established over ODBC, and subsequent requests in the same session go directly from Presentation Services to this assigned Oracle BI Server. The ODBC session between Presentation Services and the Oracle BI Server is stateful, and affinity must be maintained for the lifetime of the session.

  • Oracle BI Scheduler: Presentation Services first contacts the Cluster Controller, which relays the active Oracle BI Scheduler instance. Presentation Services then establishes a session with the appropriate Oracle BI Scheduler instance. The host and Oracle instance names for the Cluster Controllers and Oracle BI Scheduler instances are specified on the Availability tab of the Capacity Management page in Fusion Middleware Control.

  • JavaHost: Each Presentation Services instance is configured to communicate with multiple JavaHost instances in a cluster. The requests to the JavaHost instances are load balanced using native capability.

6.3.5.1 What if a Presentation Services Instance Fails?

Although an initial user session request can go to any Presentation Services instance, each user is then bound to a specific Presentation Services instance. Loss of that instance disconnects the session, and an error is relayed back to the browser. Any work in progress during the loss of the server that was not saved to disk is lost. The user must log in again to establish a new connection to an available Presentation Services. If user login is taking place using a Single Sign-On system such as Oracle Single Sign-On (SSO), then this re-login takes place automatically. The new Presentation Services session creates a new Oracle BI Server session.

Note:

When a Presentation Services instance fails, there is a small interval of time before the system recognizes that the instance has failed and before users are migrated to a new Presentation Services instance. Because of this, there might be some loss of session state.

An error is relayed to the Oracle BI Scheduler, which logs the failure and then retries the job. The retry establishes a new connection to an available Presentation Services instance.

6.3.6 About Clustered JavaHost Instances

The JavaHost component provides services that enable Oracle BI Presentation Services to support various components such as Java tasks for Oracle BI Scheduler, Oracle BI Publisher, and graph generation. By default, Presentation Services uses its local BI JavaHost instance.

The JavaHost service receives requests from Presentation Services and Oracle BI Scheduler on a port that is assigned from the port range that is defined in the Scalability tab of the Capacity Management page in Fusion Middleware Control.

6.3.7 About Web Tier Components

Load-balanced Web servers are the entry points for Web client requests. See Section 1.8, "System Requirements and Certification" for information about supported Web servers See also "Configuring High Availability for Oracle Business Intelligence" in Oracle Fusion Middleware High Availability Guide for information about configuring a highly available Web tier using using Oracle HTTP Server.

An additional Oracle Business Intelligence component called the Oracle BI Presentation Services Plug-in routes session requests to Presentation Services instances using a native protocol. The connections are load balanced using native capability. Presentation Services and the Plug-in run as separate processes.

The Oracle BI Presentation Services Plug-in is one of the Oracle Business Intelligence Java components and is scaled for high availability when you add additional Managed Servers to the deployment.

6.4 Optional Configuration for Oracle Business Intelligence High Availability

Follow the steps in this section to perform optional configuration for Oracle Business Intelligence high availability.

This section contains the following topics:

6.4.1 Setting Optional Cluster Controller Parameters

You can set optional parameters that are related to Cluster Controller heartbeat frequency in the NQClusterConfig.INI file.

A copy of the NQClusterConfig.INI file must reside on all computers that host a Cluster Controller, Oracle BI Server, or Oracle BI Scheduler component that participates in the cluster. You must set parameters in each copy of the file.

To set optional parameters in the NQClusterConfig.INI file:

  1. Open the NQClusterConfig.INI file for editing. You can find the file at:

    ORACLE_INSTANCE/config/OracleBIApplication/coreapplication_obisn

  2. The following cluster communication parameters are set to the default values shown. Optionally, modify the parameter values as required for the deployment.

    Table 6-2 NQClusterConfig.INI Parameters for Cluster Communication

    Parameter Description Default Value

    SERVER_POLL_SECONDS

    The frequency of heartbeat messages between the Cluster Controller and the Oracle BI Server and Oracle BI Scheduler nodes in the cluster.

    5 seconds

    CONTROLLER_POLL_SECONDS

    The frequency of heartbeat messages between the Cluster Controllers.

    5 seconds

  3. Save and close the file.

  4. Repeat these steps for every host in the deployment.

  5. Restart Oracle Business Intelligence.

Example 6-1 shows example parameters in the NQClusterConfig.INI file. Note that any additional options that are not shown in this example are centrally managed and cannot be set manually.

Example 6-1 Sample Parameters for Clustering in NQClusterConfig.INI

#  NQClusterConfig.INI
[Cluster]
SERVER_POLL_SECONDS = 5; 
CONTROLLER_POLL_SECONDS = 5;

6.4.2 Setting Optional Presentation Services Parameters

You can optionally configure certain parameters that control the communication between Presentation Services and the JavaHost component. To configure Presentation Services, set parameters in the instanceconfig.xml file on each computer that hosts Presentation Services.

To configure Presentation Services for clustering:

  1. Open the configuration file instanceconfig.xml for editing. You can find instanceconfig.xml at:

    ORACLE_INSTANCE/config/OracleBIPresentationServicesComponent/coreapplication_obipsn

  2. Under the ServerInstance tag, the JavaHostProxy element has some optional sub-elements. Table 6-3 describes these optional sub-elements.

    Table 6-3 Optional Sub-Elements for the JavaHostProxy Element

    Sub-Element Attribute Description

    LoadBalancer/Ping

    keepAliveMaxFailures

    Specifies the number of ping failures required before the host is declared non-functioning. The default value is 5.

    LoadBalancer/Ping

    keepAliveFrequencySecs

    Specifies the ping frequency in seconds. The default value is 20.

  3. Save and close the file.

  4. Repeat these steps for every Presentation Services instance in your deployment.

  5. Restart Oracle Business Intelligence.

6.4.3 Setting Optional Oracle BI Presentation Services Plug-in Parameters

You can optionally configure the Oracle BI Presentation Services Plug-in to control session redirection behavior. To do this, you must perform the steps in this section on each computer where the analytics Java component is installed.

To set optional parameters for the Oracle BI Presentation Services Plug-in:

  1. Open the bridgeconfig.properties file for editing. You can find this file at:

    MW_HOME/user_projects/domains/domain_name/config/fmwconfig/biinstances/coreapplication

  2. Optionally, you can include the parameter AlwaysKeepSessionAffiliation to control whether requests that belong to the same session can be redirected to another Presentation Services component if the current Presentation Services component score is too low.

    The instance score is an internal score that the load balancing algorithm associates with each Presentation Services instance in the cluster. It is based on various metrics that are collected by the load balancer.

    Set this parameter to true to disallow request redirection, or false to allow requests to be redirected. For example:

    oracle.bi.presentation.sawconnect.loadbalance.AlwaysKeepSessionAffiliation=true

  3. Save and close the file.

  4. Restart the analytics application from the Oracle WebLogic Server Administration Console. If Oracle BI Publisher is using the Oracle BI Presentation Catalog, then the xmlpserver application must also be restarted.

  5. Repeat these steps for each computer that hosts the analytics Java component.

6.5 Using the Cluster Manager

The Cluster Manager in the Administration Tool was used in previous releases to monitor and manage Oracle BI Server, Oracle BI Scheduler, and Cluster Controller instances. This tool is still supported in the current release.

Although you use Fusion Middleware Control for most administrative tasks that relate to clustered components, the Cluster Manager provides a useful way to view and change the state of clustered components. For example, you can view the currently active Oracle BI Scheduler instance and change the active instance to a different Oracle BI Scheduler if necessary. You can also see which Oracle BI Server is the Master BI Server. Fusion Middleware Control shows the current status of clustered components, but does not provide a way to view or change the current state.

The Cluster Manager lets you monitor, analyze, and manage the operations of Oracle BI Server, Oracle BI Scheduler, and Cluster Controller instances in a cluster. It provides status, cache, and session information. The Cluster Manager is available only when the Administration Tool is connected to a clustered DSN.

If all Cluster Controllers or Oracle BI Servers in the cluster are currently stopped or offline, then you cannot access the Cluster Manager to start them. You must manually start one Cluster Controller (generally, the primary) and one Oracle BI Server.

The Cluster Manager window has two panes: the Explorer pane on the left side and the Information pane on the right side. The Explorer pane displays hierarchical information about the servers, schedulers, and controllers that comprise a cluster. The Information pane shows detailed information about an item selected in the Explorer pane.

The Cluster Manager window refreshes every minute by default. You can change the interval.

To set the refresh interval for the display:

  1. In the Administration Tool, open a repository in online mode.

  2. Select Manage > Clusters.

  3. Select Refresh > Every and choose another value from the list.

  4. To refresh the display at any time, ensure that the Cluster Manager is the active window and press F5, or select Refresh > Now. This action retrieves the most current information for the cluster.

To activate an inactive Oracle BI Scheduler instance:

  1. In the Administration Tool, open a repository in online mode.

  2. Select Manage > Clusters.

  3. In the Cluster Manager dialog, right-click an Oracle BI Scheduler instance.

  4. If the Oracle BI Scheduler instance selected is inactive, then select Activate.

6.5.1 Viewing and Managing Cluster Information

The section describes how to view status, cache, and session information about a cluster and the meaning of the information provided.

6.5.1.1 Status Information

The Status view is automatically displayed when you first open the Cluster Manager window. You can also access the Status view by selecting View > Status in the Cluster Manager window.

The categories of information that are displayed in the Information pane might vary depending on the server to which the Administration Tool is connected. Table 6-4 describes categories that might appear.

Table 6-4 Status Columns

Column Description

Last Reported Time

The time that the Cluster Controller or Oracle BI Server communicated with the Controlling Cluster Controller. If the server or controller is offline, then this field might be blank.

Name

The name of the computer that is hosting the Oracle BI Server or Cluster Controller.

Role

The role of the object in the cluster:

  • Controlling. A Cluster Controller that is currently assigned the responsibility for control of the cluster.

  • Primary. The Primary Cluster Controller. This role is not displayed if the Primary Cluster Controller is currently the controlling Cluster Controller.

  • Secondary. The Secondary Cluster Controller. This role is not displayed if the Secondary Cluster Controller is currently the controlling Cluster Controller.

  • Clustered server. An Oracle BI Server that is a member of the cluster. This role is not displayed for the clustered server that is defined as the master server.

  • Master. The clustered server that the Administration Tool connects to for editing repositories in online mode.

  • Active. The Oracle BI Scheduler is active.

Sessions

This field is available when either Servers or an individual server is selected in the Explorer pane. It shows the number of sessions that are currently logged on to a clustered server.

Start Time

The timestamp showing when the Cluster Controller or Oracle BI Server was last started. This field is blank if the Cluster Controller or clustered server is offline.

Status

The status of the object in the cluster:

  • Online. The Cluster Controller or Oracle BI Server is online. For Cluster Controllers, this means that the controller can accept session requests and assign them to available servers within the cluster. For clustered servers, this means that the server might be assigned sessions by the Cluster Controller.

  • Quiesce. This status is applicable to clustered servers only. This means that any activity in progress on outstanding sessions is allowed to complete before the server transitions to Offline status.

  • Offline. The Cluster Controller or Oracle BI Server is offline. For Cluster Controllers, this means that the controller cannot accept session requests or assign sessions to available servers within the cluster. For clustered servers, this means that the server is not communicating with the controlling Cluster Controller and cannot accept sessions assigned by the controlling Cluster Controller. If the server subsequently becomes available, then it is allowed to participate in the cluster. To stop the Cluster Controller or clustered server after quiescing it, issue the Stop command.

  • Forced Offline. This status applies to clustered servers only. The Oracle BI Server has been stopped. This is identical to the offline status, except that if the Oracle BI Server comes back online, it is not assigned requests. The server remains in this state until the Start command is issued against this server from the Administration Tool Cluster Manager, or both Cluster Controllers are shut down and restarted.

  • Online: Active. The Oracle BI Scheduler instance is online, running, and the one to which Oracle BI Scheduler clients connect. This instance executes jobs.

  • Online: Inactive. The Oracle BI Scheduler is online but not running. This instance is ready to take over for the active instance if the active instance becomes unavailable.

  • Online: Inactive Pending. The Oracle BI Scheduler was active and is trying to go into an inactive state. This might take a few minutes (for example, if multiple jobs are running).

Type

When Clusters is selected in the Explorer pane, this field is available. There are three types:

  • Controller. The object is a Cluster Controller.

  • Server. The object is an Oracle BI Server.

  • Scheduler. The object is a Scheduler Server.

6.5.1.2 Cache Information

The Cache view is available in the Cluster Manager window if caching is enabled.

The categories of information and their display sequence are controlled by the Options settings. Table 6-5 describes categories that might appear.

Table 6-5 Cache View Columns

Column Description

Business Model

Name of the business model that is associated with the cache entry.

Column count

Number of columns in each row of this cache entry's result set.

Created

Time the result set of the cache entry was created.

Creation elapsed time

Time, in milliseconds, needed to create the result set for this cache entry.

Full size

Full size is the maximum size used, considering variable length columns, compression algorithm, and other factors. The actual size of the result set will be smaller than Full size.

Last used

Last time the result set of the cache entry satisfied a query. (After an unexpected shutdown of an Oracle BI Server, the Last used time might temporarily have a stale value, that is, older than the true value.)

Row count

Number of rows that are generated by the query.

Row size

Size of each row (in bytes) in this cache entry's result set.

SQL

Text of the SQL statement that generated the cache entry.

Use count

Number of times that this cache entry's result set has satisfied a query (since Oracle BI Server startup).

User

Name of the user who submitted the query that resulted in the cache entry.

To view cache information:

  • Click an individual server in the Explorer pane, and then select View > Cache.

6.5.1.3 Session Information

The Session view is available for Oracle BI Servers. The information is arranged in two windows, described in Table 6-6.

  • Session window: Appears on the top. Shows users currently logged on to the Oracle BI Server.

  • Request window: Appears on the bottom. Shows active query requests for the user selected in the Session window.

Table 6-6 describes the information that appears in the Session window.

Table 6-6 Session Window Columns (Top Window)

Column Description

Catalog

Name of the Oracle BI Presentation Catalog to which the session is connected.

Client Type

Type of client session. The client type of Administration is reserved for the user who is logged in with the Oracle BI Administrator user ID.

Last Active Time

Timestamp of the last activity on the session or the query.

Logon Time

Timestamp when the session logged on to the Oracle BI Server.

Repository

Logical name of the repository to which the session is connected.

Session ID

Unique internal identifier that the Oracle BI Server assigns each session when the session is initiated.

User

Name of the user connected.

Table 6-7 describes the information that appears in the Request window.

Table 6-7 Request Window Columns (Bottom Window)

Column Description

Last Active Time

Timestamp of the last activity on the session or the query.

Request ID

Unique internal identifier that the Oracle BI Server assigns each query when the query is initiated.

Session ID

Unique internal identifier that the Oracle BI Server assigns each session when the session is initiated.

Start Time

Time of the initial query request.

Status

These are the possible values. Due to the speed at which some processes complete, not all values for any given request or session might appear.

  • Idle. There is presently no activity on the request or session.

  • Fetching. The request is being retrieved.

  • Fetched. The request has been retrieved.

  • Preparing. The request is being prepared for processing.

  • Prepared. The request has been prepared for processing and is ready for execution.

  • Executing. The request is currently running. To terminate a request, select it and click Kill Request. The user receives an informational message that indicates that the Oracle BI Administrator canceled the request.

  • Executed. The request has finished running.

  • Succeeded. The request ran to completion successfully.

  • Canceled. The request has been canceled.

  • Failed. An error was encountered during the processing or running of the request.

To manage clustered servers:

  1. In the Explorer pane, expand the Server icon to display the servers in the cluster.

  2. In the Information pane, select a server.

  3. Select Action, and then select one of the available options.

    When the operation finishes, the status of the clustered server is refreshed automatically.

To view session information:

  1. Select a server in the Explorer pane, and then select View > Sessions.

    Session information for the server is displayed in the Information pane. It shows all users logged into the server and all current query requests for each user.

To disconnect a session:

  1. In the Session view, right-click the session in the Session window (top window) and click Disconnect.

    When you disconnect a session, the ODBC session is terminated. Client users who were connected over this session receives errors if they attempt to run queries. Users must log out, then log back in again to start a new session.

To terminate a query request:

  1. In the Session view, right-click the request in the Request window (bottom window) and click Kill Request.

    When you terminate a query request, the user who is initiating the query receives an error.

6.5.1.4 Server Information

Selecting Server info from the View menu provides information about the cluster server, such as server version number.

6.6 Troubleshooting an Oracle Business Intelligence Clustered Environment

Use Fusion Middleware Control and the Administration Console to check the status of system processes. See Section 5.6.1, "Using Fusion Middleware Control to View System Component Availability" and Section 5.6.2, "Using the Administration Console to View Managed Server Availability" for more information.

After enabling clustering, load balancing, and failover capabilities, you can troubleshoot issues that might occur in the deployment using the following:

  • Messages and errors that are reported in Fusion Middleware Control

  • Log files for Oracle Business Intelligence components, also available through Fusion Middleware Control

Review the log files for every Oracle Business Intelligence system component in the cluster. Log files record any client-side failures that might occur due to misconfiguration. While some failover events are not logged, the Cluster Controller log file records crashes of any Oracle BI Scheduler or Oracle BI Server component. You can also review the Event Viewer log on Windows and the syslog on Linux or UNIX.

See Chapter 8, "Diagnosing and Resolving Issues in Oracle Business Intelligence" for more information about log files.

6.6.1 Avoiding Errors with Network Appliance Devices when the Oracle BI Server is Running on Linux or UNIX

The following information applies to deployments with Oracle BI Server components on Linux or UNIX platforms that access Oracle Business Intelligence shared files and directories on a NAS device from Network Appliance. For environments with Oracle BI Server components on Linux or UNIX that use the NTFS security style, the recommended Network Appliance Data ONTAP storage operating system version is 6.3.1 or higher.

Linux or UNIX computers saving to an NTFS qtree in Data ONTAP versions 6.0.3 through 6.3 might see permission errors when trying to save designs. Use the following Data ONTAP setting to silently ignore attempts to set UNIX permissions on NTFS qtrees after the design file is saved:

options cifs.ntfs_ignore_unix_security_ops on