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:
Deploying High Availability for Other Components in High Availability Guide explains how to implement high availability across the stack, including how to configure a fault tolerant HTTP load balancer and a highly available database for the Oracle Business Intelligence schemas
Enterprise Deployment Guide for Oracle Business Intelligence explains how to deploy Oracle Business Intelligence based on an architectural blueprint that follows Oracle recommended best practices for security and high availability, including web tier, database tier, Administration Server, and identity management availability
This chapter includes the following sections:
The figure below shows the system components and Java components in a highly available Oracle Business Intelligence deployment.
See About the Administration Server, Managed Servers, and System Components for more information about system components and Java components.
In the figure above, 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 Presentation Services 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.
Customer metadata is stored in the shared SDD (as BAR files for import or export).
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 Failover tab of the Availability page in Fusion Middleware Control. See Using Fusion Middleware Control to Identify Single Points of Failure.
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 High Availability for Oracle Business Intelligence and EPM in High Availability Guide.
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.
If there is a single point of failure in a process, you can use Fusion Middleware Control to find it.
Before you begin this procedure, ensure that you are familiar with the information in Using Fusion Middleware Control.
Go to the Business Intelligence Overview page, as described in Displaying Oracle Business Intelligence Pages in Fusion Middleware Control.
Display the Failover tab of the Availability page.
On this page, you can view scaled out system components and whether to configure primary/secondary system components.
As an alternative to setting up the active-active configuration described in the previous sections, you can set up Oracle Business Intelligence in an active-passive configuration using Oracle Fusion Middleware Cold Failover Cluster (Cold Failover Cluster).
In a Cold Failover Cluster configuration, two or more application server instances are configured to serve the same application workload, but only one is active at any particular time.
A two-node Cold Failover Cluster can be used to achieve active-passive availability for Oracle Business Intelligence. In a Cold Failover Cluster, one node is active while the other is passive, on standby. In the event that the active node fails, the standby node is activated, and Oracle Business Intelligence continues servicing clients from that node. All Oracle Business Intelligence components are failed over to the new active node. No Oracle Business Intelligence components run on the failed node after the failover.
See Active-Passive High Availability Solutions in High Availability Guide for detailed information.
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.
The table below lists the tasks that you must perform to configure high availability for Oracle Business Intelligence.
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, and configuration assistant, and scaling out system components. |
Managing Availability in Oracle Business Intelligence (Horizontally Scaling) |
Verify that the new components are available. |
Using Fusion Middleware Control to View System Component Availability |
The steps in this section describe how to perform optional configuration for Oracle Business Intelligence high availability.
This section contains the following topics:
You can set optional parameters that are related to Cluster Controller heartbeat frequency in the bi-cluster-config.xml file.
This code shows example parameters in the bi-cluster-config.xml
file. Note that any additional elements that aren't shown in this example are centrally managed and can't be set manually.
<bi:ClusterProperties> <bi:ClusterEnabled>true</bi:ClusterEnabled> <bi:ServerPollSeconds>5</bi:ServerPollSeconds> <bi:ControllerPollSeconds>5</bi:ControllerPollSeconds> </bi:ClusterProperties>
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.
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.
The Cluster Manager 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 the state of clustered components. For example, you can view the currently active Oracle BI Scheduler instance and 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 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.
In the Administration Tool, open a repository in online mode.
Select Manage, then Clusters.
Select Refresh, then Every, and select another value from the list.
To refresh the display at any time, ensure that the Cluster Manager is the active window and press F5, or select Refresh, then Now. This action retrieves the most current information for the cluster.
Cluster information provides an insight into the application.
The section describes how to view status, cache, and session information about a cluster and the meaning of the information provided.
The Status view is automatically displayed when you first open the Cluster Manager window.
You can also access the Status view by selecting View, then 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. The following table describes categories that might appear.
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:
|
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:
|
Type |
When Clusters is selected in the Explorer pane, this field is available. There are three types:
|
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. The table below describes categories that might appear.
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 is 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, then Cache.
You can review Session information in two places.
The Session view is available for Oracle BI Servers. The information is arranged in two windows, described in the next table.
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.
The following table describes the information that is displayed in the Session window.
Column | Description |
---|---|
Catalog |
Name of the 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 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. |
The following table describes the information that is displayed in the Request 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.
|
To view session information:
Select a server in the Explorer pane, and select View, then 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:
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. Users who were connected during this session receive error messages 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:
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.
Use Fusion Middleware Control and the Administration Console to check the status of system processes.
See Using Fusion Middleware Control to View System Component Availability and Using the Administration Console to View Managed Server Availability.
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 Fusion Middleware Control components, also available through Fusion Middleware Control
Review the log files for every Fusion Middleware Control system component in the cluster. Log files record any client-side failures that might occur due to an incorrect configuration. Although 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 Diagnosing and Resolving Issues in Oracle Business Intelligence.
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 later.
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