15 Configuring High Availability for Oracle Business Intelligence and EPM

Oracle Business Intelligence is an integrated business intelligence (BI) solution that provides a business user with a complete picture across the entire organization. Oracle Business Intelligence is designed to quickly and easily integrate diverse data sources, find information from the database, share the database information, and exploit the data to learn more about the business and its customers.

Oracle's Enterprise Performance Management (EPM) system integrates a modular suite of performance management applications with comprehensive business intelligence capabilities for reporting and analysis. It increases user productivity, lowers cost of ownership, and reduces business risk.

This chapter provides topics that describe high availability for the following:

This chapter assumes that you are familiar with Oracle Business Intelligence and EPM. If not, please refer to the Oracle Business Intelligence and EPM documentation.

15.1 High Availability for Oracle Business Intelligence Enterprise Edition and Enterprise Performance Management

This section provides an introduction to Oracle Business Intelligence Enterprise Edition (Oracle BI EE) and Enterprise Performance Management (EPM). This section also describes how to design and deploy a high availability environment for Oracle BI EE and EPM.

Oracle BI EE is part of Oracle Business Intelligence, a comprehensive collection of enterprise BI functionality that provides the full range of BI capabilities including interactive dashboards, full ad hoc, proactive intelligence and alerts, enterprise and financial reporting, real-time predictive intelligence, and more. The Oracle BI EE platform is based on a proven, modern web services-oriented architecture that delivers true next-generation BI capabilities. Oracle BI EE is a robust application that enables you to collect and organize disparate data and present the organized data to users who analyze, interpret, and act upon this content. For additional introductory information about Oracle BI EE, see Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition

Enterprise Performance Management applications integrate strategy, planning, and execution into a seamless process. Oracle's EPM applications are a modular suite of integrated applications that integrate with both Oracle and non-Oracle transactional systems. You can deploy each application independently to deliver a high degree of value but they work better together, integrating strategic, financial, and operational management processes while delivering a low cost of deployment and ownership.

15.1.1.1 Oracle BI EE Component Characteristics

The following sections provide more information about the characteristics of the Oracle BI EE components. This information can help you better understand Oracle BI EE high availability requirements.

The following list summarizes the functionality of the Oracle BI EE system components.

Oracle BI Presentation Services (Presentation Services): This is a C++ process that generates the user interface pages and renders result sets on behalf of the Oracle BI Scheduler. You can configure multiple Presentation Services processes, which share the load. No session replication takes place between the Presentation Services processes.

Presentation Services is almost stateless. The only significant state is the client authentication. If Oracle Business Intelligence is configured to use single sign on for authentication purposes, then users do not have to reauthenticate after a failover. For all other authentication schemes, when failover occurs, clients will have to reauthenticate. The client sees an interruption of service and is redirected to a login page.

Oracle Business Intelligence Server (BI Server): This is a C++ process that does the data manipulation and aggregates data from data sources. You can configure multiple BI Server processes, which share the load. No session replication takes place between the BI Server processes.

The BI Server does not maintain user session state. For high availability deployments, query results are cached in the global cache.

JavaHost: This is a Java process that includes resource-intensive graph and PDF rendering. You can configure multiple JavaHost processes, which share the load. No session replication takes place between the JavaHost processes.

The JavaHost is a stateless process.

Cluster Controller: This is a C++ process which manages the population of BI Servers and Oracle BI Schedulers.

Oracle Business Intelligence Scheduler (Oracle BI Scheduler): This is a C++ process that runs jobs according to a timed schedule. Jobs may be agents created in the Oracle BI Presentation Catalog, or jobs created by the job manager.

The following list summarizes the functionality of the Oracle BI EE Java components:

Oracle BI Presentation Services plug-in servlet: Presentation Services runs as a process, not as a Web server, and does not communicate using any Web server plug-in API. The Oracle BI Presentation Services Plug-in forwards HTTP requests to Presentation Services. The HTTP requests are requests from the browser-based user interface, or SOAP requests.

Web services:

Action execution service: Runs actions on behalf of Presentation Services and Oracle BI Scheduler. Actions may be invocations of third party web services, or invocations of user supplied Java code executed as EJBs.

Action registry web service: Provides a list of actions.

Action location service: Provides an indirection level so that actions can be developed in a customer test environment, and then deployed to a production environment without every action definition having to be changed to point to production sources.

Web services for SOA: Provides a web service interface to the contents of the Oracle BI Presentation Catalog. The tree of objects in the Oracle BI Presentation Catalog is exposed as a tree of web services, defined by a WSIL tree with WSDL leaves.

15.1.1.1.1 Process Lifecycle

Each Oracle BI EE Java component is hosted by a managed Oracle WebLogic Server and controlled using the Administration Console. Each of the managed Oracle WebLogic Servers is monitored and, if necessary, restarted by the local WebLogic Node Manager.

ADF Desktop Integration: ADF uses both Presentation Services web services and direct invocation of BI Server via the ODBC/JDBC port. This is the only case where the Oracle BI Server is invoked directly, without going through Presentation Services.

15.1.1.1.3 Configuration Artifacts

Oracle BI EE provides three different configuration methods:

Central configuration is provided by BI EE pages in Oracle Enterprise Manager Fusion Middleware Control. Using these pages, additional instances can be provisioned, providing high availability and scalability. Key configuration values can also be centrally administered, ensuring that all instances have consistent configuration values.

Configuration of local system components. Local configuration is only required when making advanced configuration changes.

Configuration of local Java components. As with configuration of system components, local configuration is only required for advanced options.

Listening port ranges. Ports used by each component are automatically assigned from this range.

Basic SSL configuration: SSL can be enabled for BI EE components using the System MBean browser.

Mail server configuration

Principal tuning options

Location of shared files.

Advanced configuration can be done locally by directly editing the local configuration files. When a central configuration is committed, only the configuration options that are set by central configuration are distributed to the local machines.

Configuration of Local System Components

Each running system component sees a combination of shared and component-specific configuration files. The shared configuration files, such as ClusterConfig.xml, will be under this directory:

Since each component sees local files, they are not dependent on access to files held centrally on the Administration Server. The centrally managed configuration values are distributed to these local configuration files when central configuration is committed. These centrally managed configuration values are marked in the local files by comments warning the user not to edit them locally. The remaining values are available for local editing.

The rpd file contains references to data sources. Typically development environments use a different database for the fact tables than production environments. When the rpd file moves from a development to production environment, you must use the BI Administration Tool to edit the rpd file and change the data source references.

Local Java Component Configuration

Java components are configured in the WebLogic directory tree at:

DOMAIN_HOME/config/fmwconfig/biinstances/coreapplication

15.1.1.1.4 Deployment Artifacts

In general, Oracle BI EE deploys Java applications in nostage mode. WebLogic Server explodes the .ear file, putting it into a private temp directory. An exception to this is MapViewer, which has configuration requirements which can only be performed in a pre-exploded deployment directory.

All the Managed Server applications (excluding administration applications such as the Enterprise Manager Fusion Middleware Control and central configuration application) deploy to the whole Oracle BI EE cluster, not to individually named systems.

15.1.2 Oracle BI EE High Availability Concepts

This section provides conceptual information about using Oracle BI EE in a high availability deployment.

Requirements for Making Oracle BI EE Highly Available

Oracle BI EE achieves high availability through a combination of process replication and highly available storage (database and shared file system).

To provide a highly available system, Oracle BI EE requires the following external services:

A fault tolerant HTTP load balancer

A highly available shared file system

A highly available database for Oracle BI Scheduler and fact tables

The following system components must be replicated (have at least two instances):

Presentation Services

Cluster Controller

Oracle BI Scheduler

BI Server

JavaHost

The Enterprise Manager Fusion Middleware Control configuration UI will warn the administrator if the system components do not have at least two instances to meet the high availability requirement.

The following persistent data sources must be placed on the highly available shared file system:

RPD publishing directory: The server metadata is contained in the repository file (.rpd file) that is local to each BI Server. One BI Server is designated as a Master. Online changes to the rpd file are made on the Master BI Server, and these changes are replicated to other members of the cluster.

Oracle BI Presentation Catalog

Global cache (optional, but advisable for higher performance). The global cache capability offers support for a common query cache that stores cache seeding and purging events. The global cache is visible to all BI Servers in the cluster.

Scheduler scripts

Also, a WebLogic cluster with at least two members is required to host the Oracle BI EE Java components such as the Oracle BI Presentation Services Plug-in and the authentication service.

In Figure 15-2, the hardware load balancer receives hardware requests and then routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts have Oracle HTTP Server installed.

Oracle WebLogic Server is installed on APPHOST1 and APPHOST2 in the application tier. The Administration Server can be made active on APPHOST2 if APPHOST1 becomes unavailable, as described in Chapter 3, "High Availability for WebLogic Server." The Oracle BI EE, Oracle EPM, and Oracle BI Publisher Java components are deployed on the BI_SERVER1 and BI_SERVER2 managed servers on these hosts (note that Financial Reporting, Provider Services, and Workspace are Oracle EPM components). These managed servers are configured in an Oracle WebLogic cluster that enables them to work in an active-active manner. Whole server migration is configured for the managed servers.

The BI domain uses virtual hostnames as the listen addresses for the BI managed servers. You must enable VIP mapping for each of these hostnames on the two BI Machines, VIP1 on APPHOST1 and VIP2 on APPHOST2, and must correctly resolve the virtual hostnames in the network system that the topology uses (by DNS Server or by hosts resolution). See Section 15.1.13.22, "Configuring Server Migration for the BI_SERVERn Servers" for more details on configuring server migration for the BI servers.

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 Scheduler on APPHOST2 are passive (they are started but do not service requests) and are made active only if APPHOST1 components fail.

In the data tier, shared external storage is set up to store Catalog, query cache, RPD, and Scheduler script data. An Oracle RAC database is used to store the BI EE schema metadata, BI Publisher repository data, and is also recommended for the enterprise database.

The following subsections provide high availability information for several of the Oracle BI EE components.

15.1.2.1.1 Web Server High Availability Considerations

The Oracle BI Presentation Services Plug-in is the initial point of contact for any HTTP client, such as the browser user interface. This may in turn be fronted by an Oracle HTTP Server or other supported Web server. You must replicate this HTTP stack to avoid a single point of failure. To avoid presenting multiple HTTP URLs to users, set up an external load balancer, which routes user requests to one of the replicated Oracle BI EE URLs.

If internal HTTP requests route directly to the local WebLogic Managed Server, there is a reduced degree of high availability. If the WebLogic instance fails, Node Manager will restart it. WebLogic restart may take several minutes. During this period, the local security service is unavailable, preventing login. Contrast this with the recommended configuration, where the internal HTTP requests are routed through the load balancer. The alternative security service is quickly available.

The Oracle BI Presentation Services Plug-in is deployed as the analytics .ear application. It routes session requests to Presentation Services instances using a native RPC protocol over TCP. It also performs load balancing between the multiple Presentation Services instances, with session affinity maintained in general through a session cookie or URL argument. Presentation Services and the Plug-in run as separate processes.

Each Oracle BI Presentation Services Plug-in instance is entirely independent - there is no communication between Oracle BI Presentation Services Plug-in instances. Each makes its own decision on load balancing based on its experience of response times and number of outstanding requests.

It is recommended to configure session affinity on the load balancer.

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.

15.1.2.1.3 Presentation Services High Availability Considerations

Presentation Services receives requests from the Oracle BI Presentation Services Plug-in on a port assigned from the port range 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 instance in the cluster, each user is then bound to a specific Presentation Services instance.

To process user requests, Presentation Services must communicate with the BI Servers. In a clustered environment, the first point of contact to the BI Servers is through the Cluster Controller. Presentation Services uses the Oracle BI ODBC data source that is configured for the clustered environment to identify the primary and secondary Cluster Controllers and the ports on which they listen. The centralized BI domain configuration file configures automatically connection parameters in the ODBC Data Source Name (DSN) when centralized configuration is changed. Do not modify the Oracle BI ODBC DSN connection parameters locally.

Cluster Controller assigns the Oracle BI Server instance that Presentation Services connects to. The connection to the Oracle BI Server establishes over ODBC, and subsequent requests in the same session go directly from Presentation Services to the assigned Oracle BI Server. The ODBC session between Presentation Services and the Oracle BI Server is stateful and must maintain affinity for the session lifetime.

To communicate with 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 Availability tab of the Capacity Management page in Fusion Middleware Control specifies the host and Oracle instance names for the Cluster Controllers and Oracle BI Scheduler.

15.1.2.1.4 BI Cluster Controller High Availability Considerations

The Cluster Controller is the first point of contact for a new BI Server or Oracle BI Scheduler session from Presentation Services and other clients. The Cluster Controller deploys in active-passive configuration:

Primary Cluster Controller: The active cluster controller.

Secondary Cluster Controller: Assumes the role of active Cluster Controller if the Primary Cluster Controller is unavailable.

By default, the first Cluster Controller that you configure in your Oracle Business Intelligence installation is the primary Cluster Controller.

The Cluster Controller determines which Oracle BI Server in the cluster should receive incoming requests based on Oracle BI Server availability and load. It also monitors the server operation in the cluster, including the Oracle BI Scheduler instances.

The Cluster Controller supports:

Detection of server and Oracle BI Scheduler failures.

Failover for ODBC clients if their servers fail.

The Cluster Controller also determines the active Oracle BI Scheduler instance at run time. Note that Cluster Controller does not control Presentation Services instances.

It is important to avoid a split brain configuration, where both Cluster Controllers consider themselves to be active. To avoid a split brain configuration, do not configure Cluster Controllers on separate LANs connected across a potentially unreliable WAN. Fault tolerance against site failures should use the disaster recovery mechanisms, not the clustering mechanisms.

15.1.2.1.5 BI Server High Availability Considerations

You can install and configure multiple BI Servers to create a BI Server cluster. The Cluster Controller dispatches requests from clients such as Presentation Services to an active member of this cluster. BI Servers listen 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.

Note:

You must synchronize the clock on each server participating in a cluster. Unsynchronized clocks can skew reporting.

The Master BI Server is the server that the Oracle BI Administration Tool connects to in order to perform online metadata changes in the RPD file. The metadata changes then propagate out to the other servers when they restart. You can view which Oracle BI Server is the master using the Cluster Manager in the Administration Tool.

The Oracle BI Scheduler stores data in the Oracle BI Scheduler schema. Since the Oracle BI Scheduler database connection configuration uses the same libraries as BI Server, the fault tolerance characteristics are the same. The only difference is that the Oracle BI Scheduler interaction is much more write intensive. BI Server data sources are primarily read-only.

The main points of BI Server interaction with the database are:

Source database: Source databases are used for Oracle BI EE reporting. They are primarily read-only. There are many supported options for source databases.

Event polling: Keeps track of cache removal or creation from the file system.

Usage tracking

Write back facility: A user-driven capability.

The implementation provides the following characteristics:

All database read/write operations are performed by C++ code.

For Oracle databases, OCI is used. For other databases or data sources, native database capabilities are used.

Oracle and non-Oracle database support is possible for not just the Source database, but also for Oracle BI Scheduler.

15.1.2.1.6 Administration Tool High Availability Considerations

The Administration Tool uses the same Oracle BI ODBC DSN that Presentation Services uses. It is directed to the Master BI Server by the Cluster Controller. If the Master BI Server is unavailable, the Administration Tool cannot perform RPD file writes.

15.1.2.1.7 Oracle BI Scheduler High Availability Considerations

The Oracle BI Scheduler instances operate on an active-passive model. Only one Oracle BI Scheduler is active and processing requests at any one time to ensure that it allocates unique job ids to new jobs. The inactive Oracle BI Scheduler instance remains idle and does not process jobs until called on to take over if an active Oracle BI Scheduler fails.

The Oracle BI Scheduler uses the same database technology as the BI Server.

If Oracle BI Scheduler is up and the database is down, Oracle BI Scheduler queues up failed transactions in its memory and retries them until they are successful. Therefore, if you shut down a back-end database source for maintenance you do not need to restart Oracle BI EE processes when you restart the database. The processes are retried on the same count as the periodic purge in the Oracle BI Scheduler, and therefore use the same configuration values. Oracle BI EE only retries statements that are required to be in Oracle BI EE metadata. Oracle BI EE does not retry queries, only inserts and deletes (except for deletes that would be reexecuted). Configuration values are in the instanceconfig.xml file for Oracle BI Scheduler (PurgeIntervalMinutes).

The 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.

15.1.2.1.8 BI JavaHost High Availability Considerations

The Oracle BI 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. As with all other components, the administrator can use Fusion Middleware Control to control how many instances are deployed and where. The default configuration of JavaHost clients is to use all available JavaHosts; this differs from the previous 10g default of only using the local JavaHost.

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.

15.1.2.2 Shared Files and Directories

In Oracle BI EE, process state is shared through shared file systems and databases rather than through distributed communication protocols. In particular, Oracle BI EE does not store state internal to processes or Java components. Therefore, Oracle BI EE does not need to serialize component state so it can be distributed within a Java cluster.

The fact tables and Oracle BI Scheduler tables are shared between BI Server and Oracle BI Scheduler instances, respectively. File system sharing is less standard, as the end of this section describes. You can use a shared storage device such as NAS or SAN.

15.1.2.2.1 Oracle BI Presentation Catalog Shared Files

The Presentation Services instances in a cluster share a common Oracle BI Presentation Catalog. The Oracle BI Presentation Catalog should be placed on a shared NAS or SAN device. All instances of Presentation Services must have read and write access to the shared device. Concurrent access is managed by the file system locking semantics.

Because the Oracle BI Presentation Catalog consists of a large number of heavily accessed small files, be aware that in some cases the number of files may exceed the file limits for shared file systems. Refer to the documentation for your shared file system for information on setting the file limits for your system.

15.1.2.2.2 Repository Publishing Directory Shared Files

All BI Servers participating in a cluster share the repository publishing directory, which holds the master copies of repositories edited in online mode. The Master BI Server must have read and write access to this directory; all other BI Servers must have read access.

The clustered BI Servers examine this directory on startup for any repository changes. On startup, a BI Server instance copies the repository in the publishing directory to its local repository directory, for example:

Because this copy occurs only at restart, a cluster with a writable rpd file may show inconsistent behavior (for example, metadata does not match requests from analyses) until all the BI Server instances restart. Metadata changes are normally made offline in a development environment with a read only rpd file in the production environment.

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

15.1.2.2.3 Global Cache Shared Files

The global cache is shared by all BI Servers participating in a cluster. It resides on a shared file system storage device and stores purging events, seeding events (often generated by agents), and result sets associated with seeding events. Each Oracle BI Server maintains its own local query cache for regular queries.

Shared files requirements for the global cache are:

All BI Servers must have read and write access to the global cache directory.

The global cache parameters are configured in the NQSConfig.INI file for each BI Server node participating in the cluster. The global cache is controlled centrally via Fusion Middleware Control.

15.1.2.2.4 Oracle BI Scheduler Scripts Shared Files

You must create a network share for the Oracle BI Scheduler scripts. To create a network share, update the SchedulerScriptPath and DefaultScriptPath elements of the Oracle BI Scheduler instanceconfig.xml file (located in ORACLE_INSTANCE/config/OracleBISchedulerComponent/coreapplication_obischn). The Oracle BI Scheduler servers must have read and write access to this share.

15.1.2.3 Starting and Stopping the Cluster

Because there are dependencies between the processes, you must start a cluster in a particular order. The startup sequence is:

Start all of the WebLogic Managed Servers. The system components look to their local Managed Server for the authentication service.

Start other processes using the Start All button in Fusion Middleware Control. Using the Start All button ensures that the Java applications and the system components start in the correct startup order.

15.1.2.4 Cluster-Wide Configuration Changes

Configuration changes, especially changes to the population of the cluster, are critical for high availability. Without the ability to add new members to a cluster, a failure cannot be repaired, leaving the cluster vulnerable to a subsequent failure (this is why mean time to repair is just as important in a high availability system as mean time between individual failures).

The two technology stacks, Java and system, are managed separately.

WebLogic configuration changes are made in the WebLogic Administration Console. Standard WebLogic mechanisms are used to lock configuration while it is being changed, and to propagate the changes to all Managed Servers.

System component configuration changes are made centrally using Fusion Middleware Control. After you enter configuration changes and click Save, the configuration changes propagate to all local configuration files. This propagation is important; if the configuration is corrupt or propagation fails, the next propagation corrects the local files. An Oracle JMX extension performs file distribution similar to the WebLogic config file distribution. Delivery at the remote site is announced by a JMX MBean call. Since MBeans must be hosted in an MBean server, this means that every machine which hosts Oracle BI EE system components must also have a WebLogic Managed Server even if that machine does not host any Java Oracle BI EE components.

All components access configuration changes at their next restart only; there is no online configuration reload mechanism.

Configuration changes are triggered by:

An administrator committing changes made in the Fusion Middleware Control.

An administrator committing changes made by the MBeans API (which directly mirrors the Fusion Middleware Control user interface).

An enterprise installation that registers a new installation does not trigger a configuration push. This changes the population of machines which the administrator may pick from in the Fusion Middleware Control - new component instances are not automatically added to the configuration.

15.1.2.5 Protection From Failures and Expected Behaviors

This section describes different types of failures that can occur and the expected behavior when each type of failure occurs.

15.1.2.5.1 Machine Failure

If a machine suffers a transient failure, the cluster detects the restarted components and starts using them again. If a machine fails permanently, you must replace it. Install Oracle BI EE on the new machine using an enterprise install to extend the existing cluster.

While the WebLogic Administration Server is down, you cannot reconfigure Oracle BI EE or use Fusion Middleware Control to look at log files.

15.1.2.5.3 WebLogic Managed Server Failure

The WebLogic Node Manager detects failure of Managed Servers. Because all Java components are stateless, Oracle BI EE does not take Java cluster state maintenance into consideration.

All communications from system components to Managed Servers, for example, from Presentation Services to action services, use HTTP to the local Managed Server. If the local Managed Server fails, the Node Manager should restart it.

The following lists the effect on system components running on the same machine if the Managed Server cannot restart but the machine does not fail:

BI Server: Taken out of service until the local Managed Server works to ensure that login (done through the BI Server) is not affected. When the BI Server detects that the local Managed Server is not running, it directs the Cluster Controller to send login requests to other BI Servers.

New Scheduler connections (for example, from Job Manager) will fail. The Oracle BI Scheduler on a host where the local Managed Server is not running is unable to authenticate new users.

If you must take a Managed Server offline, first stop all system components running on the machine. If the Managed Server on a particular machine becomes unavailable, stop all system components running on that machine.

15.1.2.5.4 Oracle BI Scheduler Failure

The Cluster Controller monitors and manages the Oracle BI Scheduler. If the Oracle BI Scheduler is unavailable, the Cluster Controller determines the next Oracle BI Scheduler instance to activate. If the previous primary Oracle BI Scheduler becomes available again, the primary role doesn't revert to it.

When the active Oracle BI Scheduler fails, any open client connections do not receive an error because 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 job instances that were in progress, and runs them. A scheduled agent only delivers 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 only supported for agents that are scheduled. For example, if you click Run Agent Now on the toolbar in Answers and the primary Oracle BI Scheduler fails, that Agent does not continue to run on the Secondary Scheduler; an error message appears in the Run Now results dialog box.

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 rerun from the Job Manager. For an agent, this only delivers to those users that did not have successful deliveries. For example, if the mail server goes down halfway through an agent's execution, the rerun of the instance delivers only to those recipients who did not receive e-mail due to the mail server failure.

15.1.2.5.5 Cluster Controller Failure

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

The Cluster Controller works 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 BI Servers based on load and availability, and to the active Oracle BI Scheduler instance. If the primary later becomes available, then all requests go to the primary again.

The secondary Cluster Controller monitors the session count on each BI Server (just like the primary), but the secondary Cluster Controller does not determine which Oracle BI Scheduler is the active Scheduler unless the primary Cluster Controller is down.

The primary and secondary Cluster Controllers monitor each other's life cycle. A Split-Brain failure can occur if communication is down between the Cluster Controller instances but each is up and can communicate with other clients. In these cases, BI Servers are not affected but the Oracle BI Scheduler may have two active instances at once. In rare cases, this situation can lead to double execution of jobs. When the line of communication comes back up, the primary Cluster Controller dictates to the cluster that only one Oracle BI Scheduler should be active. The Cluster component must reside on the same LAN, minimizing the possibility of a Split-Brain failure.

If both Cluster Controllers are unavailable, Presentation Services returns an error to any new user attempting to login. Existing sessions are not affected.

Cluster Controllers track the number of active sessions on each BI Server instance. When new ODBC connections are made, the Cluster Controller allocates the new session to keep the sessions for each BI Server in balance. If a BI Server instance goes down temporarily and comes back up, then all new ODBC sessions route to this node until its session count matches that of the others in the cluster.

When a Cluster Controller fails, the first person who tries to create a new session sees a delay of about six seconds as the secondary Cluster Controller picks up sessions. All other connections are then routed to the secondary Cluster Controller.

15.1.2.5.6 Presentation Services Failure

A Presentation Services failure affects:

Web clients: 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 Presentation Services 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 instance. If user login is taking place using a Single Sign-On system such as Oracle Single Sign-On, then this relogin occurs automatically. The new Presentation Services session will create a new 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. If a single sign-on solution is being used, then there is no need for users to reauthenticate. If single sign-on is not being used, then users must reauthenticate.

Agents: 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.

15.1.2.5.7 BI Server Failure

When a BI Server failure occurs, an ODBC error goes to the appropriate client:

Presentation Services: Each Web user has requests that one BI Server serves. If the BI Server is unavailable, the user might see an error. However, a browser refresh makes a new session establish with an available BI Server. Note that the Presentation Services component performs this arbitration on behalf of its users.

Administration Tool: The Administration Tool relays the ODBC error when the BI Server that it connects to becomes unavailable, and then closes the connection. The administrator must use the Administration Tool to reconnect.

Agents: When BI Server failure occurs, the error relays to the Oracle BI Scheduler, which logs the failure and retries the job. A connection then establishes with an available BI Server.

Third-party clients: Third-party clients use ODBC to connect the BI Server. When BI Server failure occurs, ODBC relays the failure and the session closes and reopens according to the ODBC standard.

Master BI Server failure: If the Master BI Server is unavailable, online metadata changes cannot be performed. This is an administration operation; it does not affect run-time availability.

If the Master BI Server is permanently unavailable, you must appoint one of the other servers as the new master:

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

15.1.2.5.8 Troubleshooting Oracle BI EE

Check Fusion Middleware Control to see which processes are running. This reflects the state reported by OPMN.

Check the OPMN log files. They can be accessed from Fusion Middleware Control. They can also be accessed in the locations specified in Table 15-1.

When a failed process is identified, check its log file, which can be accessed from Fusion Middleware Control or in the locations specified in Table 15-1.

Certain processes shut down if they cannot communicate with their peers. To diagnose this problem:

Identify the failed process. Find the low-level socket error in the log file, which identifies the port and server address. Check in the local configuration files to see which process is configured to listen on that port. Simple deployments use the default port allocations, as the component descriptions in the subsections of Section 15.1.2.1, "Oracle BI EE and EPM High Availability Architecture" describe. You can see the ports that are currently configured in the Availability tab of the Capacity Management page in Fusion Middleware Control.

Check to see if the peer is running. If the peer is running, check its log file for an entry rejecting the communication. This can happen if SSL configuration is inconsistent or if there is a protocol failure.

Cluster Controller managed processes will fail if their configuration fails to match the Cluster Controller. While some failover events are not logged, the Cluster Controller log file records fails of any Oracle BI Scheduler or BI Server instances.

Review the log files after initial start up. If a BI Server or Oracle BI Scheduler instance has not been configured correctly and as expected by the Cluster Controller, then the instance, though it may not shut down, will not be added to the cluster. The log files will record such failures.

OPMN communicates with Essbase Agent using Oracle Net Services. Essbase Agent acts as a coordinator between clients and Essbase application servers. Essbase Agent has a pipe communication channel with the servers. It also communicates using TCP/IP.

Storage: The Hyperion Registry is a repository that stores configuration information in a relational database. Essbase Agent and Essbase application servers communicate with the back-end database using JDBC or ODBC.

15.1.3.1.1 State Information

The Oracle Essbase session state is in memory, and there is no session failover. If a client session is lost, the client must log on again.

You can use a command-line interface to OPMN to start, stop, restart, and monitor Essbase Agent; see Section 15.1.1.1.1, "Process Lifecycle." It does not start or stop the Essbase Application Server process directly. OPMN communicates with Essbase Agent using Oracle Net Services.

15.1.3.1.3 Process Lifecycle

Use the OPMN command opmnctl to start, stop, and monitor Essbase Agent.

Start

To start OPMN and all its managed components, use $ORACLE_INSTANCE/bin/opmnctl startall.

To start Essbase Agent only, with OPMN already running, use $ORACLE_INSTANCE/bin/opmnctl startproc ias-component=essbaseserver1, where essbaseserver1 is the name of the managed Essbase instance specified in opmn.xml.

Stop

To stop OPMN and all its managed components, use $ORACLE_INSTANCE/bin/opmnctl stopall.

To stop Essbase Agent only if Essbase is configured in failover cluster mode and OPMN is already running, use $ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=essbaseserver1process-type=Essbase, where essbaseserver1 is the name of the managed Oracle Essbase instance specified in opmn.xml.

Monitor

To get status information about the managed process, use $ORACLE_INSTANCE/bin/opmnctl status.

15.1.3.1.4 Request Flow

Communication with Essbase can be through a cluster name (resolved by Provider Services), a URL (resolved by the application), or a physical host and port.

15.1.3.1.5 External Dependencies

You can configure Essbase to work with an external directory service such as the Oracle Internet Directory (OID). Essbase communicates with OID using LDAP protocol.

15.1.3.1.6 Configuration Artifacts

The following table describes Essbase configuration artifacts.

Table 15-2 Essbase Configuration Artifacts

File

Location

Description

Essbase configuration file, essbase.cfg

$ARBORPATH/bin

Contains configurable parameter values for Essbase.

The Essbase security file, essbase.sec

$ARBORPATH/bin

Contains information on security and applications

OPMN configuration file, opmn.xml

$ORACLE_INSTANCE/config/OPMN/opmn

Lists all the managed components and the environment variables to be passed to each managed component.

15.1.3.1.7 Deployment Artifacts

Deployment artifacts required for correct setup of Essbase include JDBC and ODBC, reg.properties, security artifacts, and so forth. Deployment artifacts must be passed to OPMN, which can then provision Essbase.

15.1.4.1 Oracle Essbase High Availability Architecture

15.1.4.1.1 Shared Files and Directories

ARBORPATH, which includes configuration files, security files, and all applications and corresponding databases, is on a shared disk. Instance-specific files, binaries, and log files are on a local disk by default but can be shared. For example, you could put log files on a shared disk by changing a configuration setting in opmn.xml.

15.1.4.1.2 Cluster-Wide Configuration Changes

Shared configuration information is in essbase.cfg, which is on a shared disk. For example, changes in timeout settings for lease acquisition or renewal are made in essbase.cfg on the shared disk.

15.1.4.2 Protection from Failures and Expected Behaviors

For failover, you can configure Essbase in a two-node cluster.

Included in a failover cluster setup:

Two nodes

One node is active at all times and one node is passive.

A shared disk between the nodes

The shared disk stores applications, databases, product configuration, and everything that is placed under $ARBORPATH.

Product binaries and others in $ESSBASEPATH

Each node can have the binaries on a direct attached storage disk.

Registry and lease databases

These databases, which are critical, must be on redundant storage devices.

A leasing mechanism ensures that one and only one Essbase Agent and its set of application servers are active. One and only one lease must be active on a resource at any time; the owner of the active lease has ownership rights to the resource. This leasing scheme is implemented using the lease tables in the database. The lease tables are seeded by Repository Configuration Utility (RCU).

To exploit failover functionality, Java API clients must log on using APS Servlet endpoint URL. The URL would specify the cluster name of the failover cluster; for example, http://WEBHOST1:7777/aps/Essbase?clusterName=cludemo

Provider Services resolves the cluster name to the hostname and port of the active node in the cluster.

Session failover is not supported. If service failover occurs, the client receives an error message and must log on again.

15.1.4.3 Troubleshooting

To troubleshoot Essbase failover, check OPMN and Essbase logs to determine event sequence. For example, the logs might show that OPMN starts Essbase but Essbase does not acquire a lease because of database authentication failure.

15.1.5 Configuring Oracle Essbase Clustering

This section describes how to how to set up Essbase clustering high-availability environment.

15.1.5.1 Prerequisites

Copy the contents of the local ARBORPATH for the single Essbase Agent to the shared ARBORPATH.

The provisioning framework automatically creates a single Essbase Agent, essbaseserver1, and points the ARBORPATH to /u02/local/oracle/config/BIInstance/Essbase/essbaseserver1. There are three directories under the local ARBORPATH which you must copy to the shared ARBORPATH location:

15.1.5.2 Configuring a shared ARBORPATH

Click Lock and Edit Configuration to activate the Essbase Agents section of the Availability tab.

Specify the Shared Folder Path for the Essbase Agents.

If you have not done so, upload the configuration folder under local Oracle Instance Home to the shared location.

Note:

You must manually copy the contents of the ORACLE_INSTANCE/config/Essbase/essbaseserver1 directory to the shared folder path. In addition, copy the essfoconfig.properties file to EssbaseConfigInfo.properties, and adapt the values as appropriate for your deployment.

Click Apply then Activate Changes.

15.1.5.3 Configuring Secondary Instances of Essbase Agent

Configure a secondary instance of the Essbase Agent so that they are distributed for high availability:

Log in to Fusion Middleware Control.

Expand the Business Intelligence node in the Farm_BIDomain window.

Click coreapplication, Availability, then Failover.

Click Lock and Edit Configuration to activate the Essbase Agents section of the Availability tab.

Specify the Secondary Host/Instance for Essbase Agent. Click Apply.

Under Potential Single Points of Failure, it should report No problems for Essbase Agent.

Provider Services contains three subcomponents: Essbase Java API, SmartView Provider, and an XMLA (XML for Analysis) provider. These subcomponents service Java API clients, SmartView clients, and XMLA clients, respectively. Provider Services is designed with three different servlets, one for each subcomponent.

Communication between clients and Provider Services is over the HTTP(S) protocol. The JAPI and XMLA clients are designed for Essbase communication. The Smart View client enables users to connect to data sources such as Essbase, Oracle Hyperion Planning, Fusion Edition and Oracle BI EE servers.

15.1.6.1 Oracle Hyperion Provider Services Component Characteristics

15.1.6.1.1 State Information

Provider Services session information is stored in memory until the user disconnects or the session times-out.

15.1.6.1.2 Runtime Processes

Provider Services is a Java-based enterprise application deployed on the WebLogic server application container. At runtime, there is a single Java process, which is the container. Provider Services runs no other external processes.

15.1.6.1.3 Process Lifecycle

The lifecycle of the Provider Services process is the same as the process lifecycle for any standard Java- based enterprise application deployed on a WebLogic server.

15.1.6.1.4 Request Flow

A dispatcher such as Oracle HTTP Web Server acts as a gateway, delivering requests to the Provider Services instances that are part of the cluster. Provider Services supports sticky sessions, so that when a user session establishes with a Provider Services instance, the same instance handles all subsequent requests from the client until the user disconnects. If a Provider Services instance fails, the user must disconnect the existing invalid session and log on again, using the same URL (the dispatcher URL) as for the failed session.

15.1.6.1.5 External Dependencies

Provider Services is dependent on Hyperion Registry. The SmartView Provider component stores the Data Sources (datasources.xml) and Smart Slices in the registry database using Registry Java APIs. The Essbase Java API component also uses the Hyperion registry for maintaining domain-related (domain.db file) information. All of this information is stored under the Registry's LOGICAL_WEB_APP component of Provider Services.

15.1.6.1.6 Configuration Artifacts

Provider Services has a configuration file, essbase.properties, which resides in $ORACLE_HOME/products/Essbase/aps/bin. The Provider Services startup script requires the following JVM setting ESS_ES_HOME so that it can identify the configuration file at runtime. This setting specifies the PROVIDER_SERVICES_HOME folder, in which the bin/essbase.properties file resides.

15.1.6.1.7 Deployment Artifacts

Provider Services deployment artifacts include these files:

logging.xml: Configuration file for managing Provider Services logs

essbase.properties: Provider Services configuration file

aps.ear: Provider Services enterprise application archive

15.1.6.1.8 Log Files

Provider Services logging is based on ODL logger. The Provider Services startup script requires these JVM settings related to logging:

In a cluster including several Provider Services instances, a separate unique log location is defined for each instance. If the log location for an instance is under a Provider Services home, the administrator must grant read and write permissions to that folder for all Provider Services instances.

15.1.7 Oracle Hyperion Provider Services High Availability Concepts

Provider Services deploys and runs within an application server environment such as Oracle WebLogic Server. To support Provider Services high availability, you can deploy multiple instances of Provider Services, using the WebLogic Server clustering and load balancing capabilities. For details on clustering enterprise applications such as Provider Services, see the WebLogic Server documentation.

In the preceding figure, LOGICAL_WEB_APP represents a cluster consisting of Provider Services instances. Each PROVIDER_SERVICES_WEB_APP component stores the actual server and port of its Provider Services instance; for example:

LOGICAL_WEB_APPCluster_URL

|

----- PROVIDER_SERVICES_WEB_APP 1 server1:port

|

----- PROVIDER_SERVICES_WEB_APP 2

|

----- PROVIDER_SERVICES_WEB_APP 2 server2:port_y

The LOGICAL_WEB_APP component information specifies the Provider Services cluster URL, which is unique.

15.1.7.1.2 Cluster-Wide Configuration Changes

Provider Services reads the essbase.properties file only during startup. If the Provider Services administrator changes this file, the administrator must restart the Provider Services cluster so that all Provider Services instances in the cluster are synchronized with configuration settings.

15.1.7.1.3 OPMN Essbase Cluster Support

To support Essbase clusters, clients communicate with Provider Services to fetch the active Essbase node in the cluster. API clients (CAPI/JAPI) must specify an Provider Services URL (which contains the OPMN Essbase cluster name) to obtain the active Essbase host instance details. Provider Services then retrieves the active Essbase node details from the Hyperion Registry. The remainder of this section describes the behavior for Provider Services and C/JAPI client use cases.

15.1.7.1.4 Essbase Database Clustering by Provider Services

Provider Services supports high availability of Essbase databases with active-active clustering. Clustering Essbase cubes (databases) enables load balancing and failover support. Provider Services manages a series of active, duplicate databases that respond to user requests. Users connect to the database by specifying an Essbase cluster; the database that is accessed must be transparent to users. Provider Services facilitates the routing of connections between databases in a cluster, based on availability and precedence rules (using the round-robin technique). The Essbase cluster supports read-only operations on the Essbase database. Write-back operations such as data load and outline editing are not supported.

15.1.7.2 Protection from Failures and Expected Behaviors

Provider Services supports sticky sessions: After a user session is established with a Provider Services instance, the same Provider Services instance handles all subsequent requests from the client until the user disconnects. When a Provider Services instance fails (indicated by an invalid session error), the user must disconnect the existing (invalid) session and log on again. The failover to the new Provider Services instance is transparent, so that the user can connect to the same APS URL (the dispatcher's URL) that was used earlier. A dispatcher could be, for example, Oracle HTTP Server, which acts as a gateway, delivering requests to the Provider Services instances that are part of the cluster.

15.1.8.1 Workspace Component Characteristics

EPM Workspace consists of a single J2EE Web application, which is typically fronted by an HTTP proxy such as Oracle HTTP Server. The HTTP proxy serves static content and proxies other products integrated into EPM Workspace. Content aggregation typically occurs on the client-side. EPM Workspace does not aggregate content within its own process; that is, EPM Workspace does not function as a portal.

15.1.8.1.1 State Information

EPM Workspace sessions are regular J2EE sessions that are held in memory only. EPM Workspace is stateful in its session use and the sessions are not serializable to any DB.

15.1.8.1.2 Runtime Processes

EPM Workspace has a normal J2EE runtime. Users typically connect to EPM Workspace, log on to the system, and access another product, such as Oracle Hyperion Financial Reporting. There are no background threads or other forms of server-side services or jobs. All processing is handled in the context of the HTTP request.

EPM Workspace uses a set of servlets, implemented directly or as JSPs, and servlet filters. There are no EJBs or JMS usage. Database access is through a standard JNDI lookup of a JDBC data source.

15.1.8.1.3 Process Lifecycle

EPM Workspace is managed as a standard J2EE Web application deployed to the WebLogic application server. It is managed, started, and terminated by its application server.

15.1.8.1.4 Request Flow

Requests are made to EPM Workspace by means of the HTTP proxy, which is the only means for end-users to access EPM Workspace. EPM Workspace does not make requests against other Web applications or databases other than its repository database and the EPM Registry database.

15.1.8.1.5 External Dependencies

EPM Workspace relies upon its repository database and the Hyperion Registry; both are in the same schema.

Most EPM products rely on EPM Workspace to provide initial authentication and a containing user interface.

15.1.8.1.6 Configuration Artifacts

The entire EPM Workspace configuration is stored in the Hyperion Registry. Individual user preferences are stored in the EPM Workspace repository.

15.1.8.1.7 Deployment Artifacts

EPM Workspace has no deployment artifacts other than the JDBC data source.

15.1.8.1.8 Log Files

Go to the logs/workspace subdirectory in the managed server domain home to view workspace.log and Framework.log.

15.1.9 Oracle EPM Workspace High Availability Concepts

This section provides conceptual information about using EPM Workspace in a high availability environment.

15.1.9.1 Workspace High Availability Architecture

You can cluster both the HTTP proxy and the J2EE deployment of EPM Workspace with standard WebLogic Server clustering mechanisms and standard use of the application server deployment and data sources. EPM Workspace high availability requires sticky sessions; session replication and failover are not supported.

All clustered versions must be identical. All updates to cluster members must be made at the same time.

The load-balancer hardware or HTTP proxy allocates requests in a round-robin rotation.Requests fail if the repository database or Hyperion Registry is lost. When a request fails, subsequent requests attempt to initialize EPM Workspace and restore its database connectivity.

Database use increases markedly when an EPM Workspace instance is started and initialized. If there are many deployments, the cluster startup may be faster if you stagger startup of the instances.

15.1.9.1.1 Shared Files and Directories

EPM Workspace has no shared files or directories except for Oracle JRF and EPM common files.

15.1.9.1.2 Cluster-Wide Configuration Changes

Product binaries and deployment information generated by WebLogic Server are stored in the file system. The configuration is stored in the Hyperion Registry. All Workspace instances share the same configuration via the Hyperion Registry. You can change the configuration through the EPM Workspace administrative user interface or with explicit updates to the registry outside EPM Workspace.

Normally, the file system artifact changes only for a patch or for reconfiguration of the deployment or clustering that requires Oracle WebLogic Server file changes. Configuration changes do not require files system updates. Cluster members see the updated configuration at the next reinitialization. Each cluster member must be directed to reinitialize itself; the Hyperion Registry is not polled.

15.1.9.2 Protection from Failures and Expected Behaviors

Unfinished requests and sessions that are on the failed node are lost. Subsequent requests from the browser that are routed to a different node are intercepted and require re-authentication to Workspace. There is no provision to migrate any sessions for a single node failure; there is a feature for administrators to send a message to Workspace users at logon that could inform them of downtime, etc.

Note:

Database outages affect BI Workspace sessions. With RAC database backends, if a database instance has an outage, BI workspace sessions connected to the database generate an error and may need to restart.

15.1.9.3 Troubleshooting

Go to the logs/workspace subdirectory in the managed server domain home to view Workspace.log and Framework.log.

15.1.10 Oracle Hyperion Financial Reporting Component Architecture

Oracle Hyperion Financial Reporting (Financial Reporting) is a powerful tool for designing and presenting analytic data graphically. You can design traditional financial report formats such as cash management reports, profit and loss statements, and balance sheets. You can also design nontraditional formats for financial or analytic data that include text and graphics.

Use Financial Reporting to create and deliver financial reports to the General Ledger system. Reporting administrators use EPM Workspace with financial reports to create and modify reports, books, and batch definitions and to schedule batch jobs via the reporting scheduler user interface within EPM Workspace. Reporting users run and view reports using the General Ledger user interface; they can launch reports in an IFrame within the General Ledger browser window.

Financial Reporting contains servlets and also contains JSPs for UI and XML generation. It also provides a web service API (JRF based) for use from ESS scheduler implementation for FR (FREssClient.ear). FRWebApp also contains RMI objects which are discovered and distributed via HTTP calls that replace the typical RMI registry, enabling multiple instances per machine with lookup via proxy request to distribute the load across instances.

PrintServer is a stand-alone RMI server (default port 8297) which is registered with the Web application, enabling a Web request for a PDF to locate a print server and generate PDF results.

15.1.10.1.1 State Information

EPM Workspace browser is either stateless or per session. Connections to Oracle BI Presentation Service cache and restore if they time out. WebLogic pooling handles RDBMS and tries to reconnect in case of failure when making SQL calls. By default, Essbase connections cache for 5 minutes (configurable).

Essbase/Provider Services – Financial Reporting connects directly to Essbase by way of sockets. Lookup is direct or by way of Provider Services HTTP calls.

15.1.10.1.2 Runtime Processes

This section describes Financial Reporting processes at runtime.

Users launch report or book from the list of available reports. Users can select formats that include HTML, PDF, or Microsoft Office document).

Financial Reporting loads a tracking frame, which identifies what report instances are used and catches unloading events for the IFrame to clean up server instances. This frame loads another frame for running and viewing the report or book.

Financial Reporting Web Application loads the report or book design and runs it against Essbase to generate output in the requested format.

Financial Reporting loads the design from the catalog by means of Oracle BI Presentation Services calls.

Financial Reporting connects to Essbase either directly or by way of a Provider Services URL.

Financial Reporting queries Essbase based on the report or book design and generates output in the requested format.

For HTML and Microsoft Office formats, Financial Reporting generates HTML and delivers the associated mime type to the client to enable launching in Microsoft Office when requested.

For PDF format, the Financial Reporting application server makes an RMI call to an available print server to generate PDF content, then returns the PDF file to the browser client.

Connection and user authentication: Report Designer enters credentials and URL of the Financial Reporting server (normally address of the Oracle HTTP Server proxy). Financial Reporting Studio makes an HTTP call to the Web application to get an RMI stub object; afterward, all communication is by way of RMI.

All access to repository and data sources is through remote RMI calls to Financial Reporting Web Application RMI objects, which make calls to repository and data sources. No direct connection is made from Financial Reporting Studio to the repository or Essbase.

All access to RDBMS is through remote calls to Financial Reporting Web Application RMI objects, which make the JDBC calls. No direct connection is made from FRStudio to the JDBC datasources.

Users open a wizard to select a batch to schedule and job attributes such as point of view, execution time/frequency of execution, and output format.

The Financial Reporting Web Application uses ESS EJB APIs to create and schedule the job according to the user's instructions. ESS RDBMS tables store the job and request.

Batch Execution (ESS and Financial Reporting backend code)

Initiated by ESS

Invokes Webservice calls to Financial Reporting

Failover supported (Webservice failure during call causes batch result state of error)

ESS picks up the Financial Reporting scheduled job and calls the Financial Reporting EssClient, which deploys with ESS-dedicated servers in the FSCM domain.

FREssClient extracts the URL of the target Financial Reporting application server and makes a Webservice call to the Financial Reporting application server to execute the job, passing the XML defined as the job definition.

Financial Reporting Web Application runs the job according to the parameters defined when the user scheduled the job and returns a status code to FREssClient.

FREssClient returns the success or failure status to the ESS caller.

Note:

Financial Reporting keeps job results in RDBMS tables. However, ESS determines when a job runs and the FREssClient connects to only one Financial Reporting Web Application. This prevents multiple Financial Reporting servers from processing issues of the same job; ESS manages how it prevents multiple ESS servers from processing the same job.

15.1.10.1.4 Configuration Artifacts

Hyperion Registry stores configuration information that is not part of the overall system configuration; all Web application instances share Hyperion Registry. MBeans, which you can open and modify with Fusion Middleware Control, exposes configuration information. See the following in Fusion Middleware Control: com.hyperion.FinancialReporting and com.hyperion.Annotations.

15.1.11.1.1 Shared Files and Directories

There are no shared files or directories. All common properties and documents are either in the relational database or stored in the Oracle BI Presentation Services repository.

15.1.11.1.2 Cluster-Wide Configuration Changes

Except for PrintServer, configuration is cached. Modifications affect only the server where they are made until the next restart of the other server. Print servers are not cached and can be added or removed at any time.

15.1.11.2 Protection from Failures and Expected Behaviors

Financial Reporting supports failover and session serialization if you also deploy the following components:

The catalog application server, Presentation Services, and file storage are clustered or replicated.

The catalog location configured during applications provisioning references the proxy server and not a direct catalog Web application server.

Essbase – Financial Reporting reports must target Essbase using the Provider Services URL, and Provider Services must be configured with active and passive Essbase servers. When Essbase fails, Financial Reporting connects through the Oracle Hyperion Provider Services URL to the backup server, and Essbase queries are reissued without interruption to the user request.

RDBMS – The database must support failover. Connections are handled through the WebLogic JDBC configuration and connection pooling.

Oracle Internet Directory/OAM

Oracle HTTP Server is expected to provide failover and provide integration point for all components. Financial Reporting configuration should target Oracle BI Presentation Services through Oracle HTTP Server or a load-balanced URL and not directly target the catalog server.

Oracle Hyperion Financial Reporting, Fusion Edition PrintServer – At least two PrintServer hosts should be deployed on Windows machines and configured with the system.

Allocation Manager is a Java Web application, deployed on WebLogic with multiple instances running in active-active mode. All instances of Allocation Manager are equal and can service any request. Allocation Manager is a stateful application that requires sticky routing. Session failover is not supported. Edits are made only within a single instance and are not saved if the instance fails.

Allocation Manager administration and discovery of external components is done through Hyperion Registry.

15.1.13 Oracle BI EE High Availability Configuration Steps

This section describes how to set up a two node highly available configuration for Oracle BI EE and BI Publisher. The architecture targeted for the configuration steps is Figure 15-2.

Note:

Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process.

15.1.13.1 Prerequisite Steps Before Setting Up a High Availability Configuration for Oracle BI Enterprise Edition and BI Publisher

The following section describes prerequisite steps before setting up a high availability configuration for Oracle BI EE and Oracle BI Publisher.

15.1.13.1.1 Database Prerequisites

Oracle BI EE supports the following database versions:

Oracle Database 10g (10.2.0.4 or later for non-XE database)

Oracle Database 11g (11.1.0.7 or later for non-XE database)

To determine the database version, execute this query:

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.1.13.1.2 VIP and IP Prerequisites

You configure the BI managed servers to listen on different virtual IPs, shown in Table 15-7. This requires the provisioning of the corresponding VIP in the node and related host names in the DNS system in your network. Ensure that the different VIPs are available and are reachable before running the installation.

Table 15-3 BI EE Virtual Hosts

Virtual IP

Virtual IP Maps To

Description

VIP1

APPHOST1VHN1

APPHOST1VHN1 is the virtual hostname that maps to the listen address for BI_SERVER1 and fails over with server migration of this managed server. It is enabled on the node where BI_SERVER1 process is running (APPHOST1 by default).

VIP2

APPHOST2VHN1

APPHOST2VHN1 is the virtual hostname that maps to the listen address for BI_SERVER2 and fails over with server migration of this managed server. It is enabled on the node where BI_SERVER2 process is running (APPHOST2 by default).

15.1.13.1.3 Shared Storage Prerequisites

For proper recovery in case of failure, store both JMS and transaction logs in a location that is accessible to all the nodes that can resume the operations after a failure in a managed server. This requires a shared storage location that can be referenced by multiple nodes. Table 15-4 lists the contents of shared storage.

Table 15-4 Contents of BI EE Shared Storage

Server

Type of Data

Volume in Shared Storage

Directory

Files

BI_SERVER1 and BI_SERVER2

Transaction logs

VOL2

ORACLE_BASE/admin/domain_name/cluster_name/tlogs

Common location (stores decided by WebLogic Server)

BI_SERVER1 and BI_SERVER2

JMS stores

VOL2

ORACLE_BASE/admin/domain_name/cluster_name/jms

Common location, but individual store per server. For example: BipJmsStore for BI_SERVER1 and BipJmsStore2 for BI_SERVER2)

BI_SERVER1 and BI_SERVER2

BI Server Repository

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/ClusterRPD

Common location

BI_SERVER1 and BI_SERVER2

BI Global Cache

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/GlobalCache

Common location

BI_SERVER1 and BI_SERVER2

BI Presentation Services Repository

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/catalog

Common location

BI_SERVER1 and BI_SERVER2

BI Publisher Configuration folder

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/config

Common location

BI_SERVER1 and BI_SERVER2

BI Publisher Catalog repository

VOL1

ORACLE_BASE/domain_name/config/bipublisher/catalog

This is only required if Oracle BI Publisher - File System is selected for the BI Publisher Catalog type.

Common location

BI_SERVER1 and BI_SERVER2

BI Publisher Scheduler Temp directory

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/temp

Common location

The shared storage can be a NAS or SAN device. The following is an example command based on a NAS over NFS device. Your options may be different from the ones specified in this section.

15.1.13.1.4 Clock Synchronization

You must synchronize all server clocks that participate in the cluster to within one second difference. To synchronize the clocks, use a single network time server and point each server to it. The procedure to point to the network time server is different from Windows to Linux. Refer to your operating system's manual.

15.1.13.1.5 Installing and Configuring the Database Repository

This section describes how to install and configure the database repository.

Host Name: Specify the name of the node on which the database resides. For the Oracle RAC database, specify the VIP name or one of the node names as the hostname, for example:

BIDBHOST1-VIP

Port: Specify the listen port number for the database: 1521

Service Name: Specify the service name of the database:

biha.mycompany.com

Username: Specify the name of the user with DBA or SYSDBA privilege: SYS

Password: Enter the password for the SYS user.

Role: Select the database user's role from the list: SYSDBA (required by the SYS user).

Click Next.

In the Select Components screen:

Select Create a new Prefix and enter a prefix to use for the database schemas, for example, BIHA. You can specify up to six characters as a prefix. Prefixes are used to create logical groupings of multiple repositories in a database. For more information, see Oracle Fusion Middleware Repository Creation Utility User's Guide.

Tip:

Note the name of this schema because the upcoming steps require this information.

This section describes the load balancer prerequisites for deploying an Oracle BI EE high availability environment.

Load Balancers

Oracle BI EE uses a hardware load balancer when deployed in a high availability configuration with two Oracle HTTP Servers as web tier components.

Virtual Server Names

bi.mycompany.com is a virtual server name that acts as the access point for all HTTP traffic to the runtime BI components, such as Oracle BI Publisher. Traffic to both SSL and non-SSL ports is configured, and typically non-SSL is redirected to SSL. Clients access this service using the address bi.mycompany.com:443. This virtual server is defined on the load balancer.

On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.

Note:

The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen does not appear for this installation, verify and see:

If the /etc/oraInst.loc file exists.

If the file exists, that the Inventory directory listed is valid.

Whether or not the user performing the installation has write permissions for the Inventory directory.

On the Welcome screen, click Next.

On the Select Installation Type screen, select Install and Configure, and click Next.

On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.

On the Specify Installation Location screen, specify:

Oracle Middleware Home: ORACLE_BASE/product/fmw (grayed out)

Oracle Home Directory: Oracle_WT1

Click Next.

On the Configure Components screen:

Select Oracle HTTP Server.

Do not select Associate Selected Components with Weblogic Domain.

Click Next.

On the Specify Component Details screen, enter the following values for WEBHOST1:

If you specify a custom port, select Specify Ports using Configuration File and then use the Browse function to select the file.

Enter the Oracle HTTP Server port, for example: 7777

Click Next.

In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.

On the Installation Summary screen, ensure that the selections are correct. If they are not, click Back and make the necessary fixes. After ensuring that the selections are correct, click Install.

On the Installation Progress screen on UNIX systems, a dialog appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

Click Next.

On the Configuration Progress screen, multiple configuration assistants are launched in succession; this process can be lengthy. Click Next.

On the Installation Complete screen, click Finish to exit.

Repeat the steps for WEBHOST2 and configure your load balancer with a pool containing both the WEBHOST1 and WEBHOST2 addresses.

15.1.13.1.9 Validating Oracle HTTP Server

To verify that Oracle HTTP Server is set up correctly, access the root URL context of the server by using the following URLs in the browser:

http://WEBHOST1:7777/
http://WEBHOST2:7777/

If Oracle HTTP Server is set up correctly, the Oracle FMW Welcome screen appears in the browser.

15.1.13.2 Installing Oracle Business Intelligence Enterprise Edition for High Availability

This section describes how to install Oracle Fusion Middleware on all application tier nodes that run Oracle WebLogic Server and Oracle BI EE. Repeat the procedure (described below for APPHOST1) for installing WebLogic Server and Oracle BI EE in APPHOST2. The directory paths you use for binary files and domains when installing new nodes must be identical to those for the first node.

Install the following Oracle Fusion Middleware components:

Oracle WebLogic Server

Oracle Business Intelligence

In this section, a software-only install is performed then the config.sh configuration script is used to create and scale out the Oracle BI system.

15.1.13.2.1 Installing Oracle WebLogic Server

Follow these steps to install Oracle WebLogic Server:

Start the installer for Oracle WebLogic Server from the installation media.

In the Welcome screen, click Next.

In the Choose Middleware Home Directory screen:

Select Create a new Middleware Home.

For the Middleware Home Directory, enter ORACLE_BASE/product/fmw

Note:

ORACLE_BASE is the base directory under which Oracle products are installed. The recommended value is /u01/app/oracle.

Click Next.

In the Register for Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.

In the Choose Install Type screen, select Typical and click Next.

In the Choose Product Installation Directories screen, accept the directory ORACLE_BASE/product/fmw/wlserver_10.3 for WebLogic Server and ORACLE_BASE/product/fmw/coherence_3.6 for Oracle Coherence and click Next.

In the Installation Summary screen, click Next.

The Oracle WebLogic Server software is installed.

In the Installation Complete screen, clear the Run Quickstart check box and click Done.

On the Linux platform, if the /etc/oraInst.loc file exists, check that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory. If the /etc/oraInst.loc file does not exist, you can skip this step.

Start the installer for Oracle Fusion Middleware Business Intelligence 11g from the installation media:

On UNIX:

APPHOST1>./runInstaller

On Windows:

APPHOST1> setup.exe

In the Specify Inventory Directory screen:

Enter HOME/oraInventory, where HOME is the home directory of the user performing the installation (this is the recommended location).

Enter the OS group for the user performing the installation.

Click Next.

Follow the instructions on screen to execute /createCentralnventory.sh as root.

Click OK.

In the Welcome screen, click Next.

In the Select Installation Type screen, select Software Only Install and click Next.

In the Prerequisite Checks screen, verify that all checks complete successfully, and click Next.

In the Specify Installation Location screen, select the previously installed Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name (Oracle_BI1).

Click Next.

In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.

In the Summary screen, click Install.

The Oracle Fusion Middleware Business Intelligence 11g software is installed.

In the Installation Progress screen, click Next.

In the Complete screen, click Finish.

15.1.13.3 Enabling VIP1 in APPHOST1 and VIP2 in APPHOST2

The BI domain uses virtual hostnames as the listen addresses for the BI managed servers. You must enable the VIPs, mapping each of these hostnames on the two BI machines (VIP1 on APPHOST1 and VIP2 on APPHOST2), and they must correctly resolve to the virtual hostnames in the network system used by the topology (either by DNS Server or hosts resolution).

15.1.13.4 Creating a Domain with the Administration Server and the First BI_SERVER1 Managed Server

This section describes how to create a domain and the first WebLogic Server BI managed server using the Oracle Business Intelligence Configuration Assistant, Administration Console, and Oracle Enterprise Manager. Ensure that the database where you installed the repository is running. For Oracle RAC databases, all the instances must be running.

Note:

Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.

Run the Configuration Assistant from the Oracle home directory to create a domain containing the Administration Server and the managed server with BI Publisher:

Change the directory to the location of the Configuration Assistant:

APPHOST1> cd ORACLE_HOME/bin

Start the Configuration Assistant:

On UNIX:

APPHOST1> ./config.sh

On Windows:

APPHOST1> config.cmd

In the Welcome screen, click Next.

In the Prerequisite Checks screen, verify that all checks complete successfully, and click Next.

In the Create or Scale Out BI System screen, select Create New BI System and specify the following:

15.1.13.8 Disabling Host Name Verification for the BI_SERVER1 Managed Server

You must disable hostname verification if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you do not configure the server certificates, you receive errors when managing the different WebLogic Servers. To avoid these errors, disable hostname verification while setting up and validating the topology, and enable it again after you complete the high availability topology configuration.

The changes do not take effect until the BI_SERVER1 managed server restarts.

In the Summary of Servers screen, select the Control tab.

Select bi_server1 in the table and then click Shutdown.

Restart the BI System components, for example:

cd ORACLE_BASE/admin/instance1/bin
./opmnctl restartproc

15.1.13.9 Starting the System in APPHOST1

This section describes how to start Node Manager on APPHOST1 and how to start and validate the BI_SERVER1 managed server on APPHOST1.

15.1.13.9.1 Starting Node Manager on APPHOST1

Usually, Node Manager starts automatically when config.sh completes. If Node Manager is not running for some reason, start it on APPHOST1 using these commands:

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

15.1.13.9.2 Starting and Validating the BI_SERVER1 Managed Server

To start the BI_SERVER1 managed server and check that it has the correct configuration:

Start the bi_server1 managed server using Administration Console, as follows:

Expand the Environment node in the Domain Structure window.

Choose Servers.

Click the Control tab.

Select bi_server1 and then click Start.

Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming", wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors

When BI_SERVER1 starts, the following URLs become available:

Access http://APPHOST1VHN1:9704/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data appears.

Note:

The configuration is incorrect if no policies or assertion templates appear.

15.1.13.9.3 Starting and Validating the BI EE System Components on APPHOST1

You can control Oracle Business Intelligence system components using opmnctl commands.

To start the BI EE system components using the OPMNCTL command line:

Go to the directory that contains the OPMN command line tool.

Note:

The OPMN command line tool is in the ORACLE_INSTANCE/bin directory.

Run the opmnctl command to start the BI EE system components:

opmnctl startall

This command starts OPMN and all BI EE system components.

opmnctl start

This command starts OPMN only.

opmnctl startproc ias-component=componentName

This command starts a particular system component. For example, where coreapplication_obips1 is the BI Presentation Services:

opmnctl startproc ias-component=coreapplication_obips1

Check the status of the BI EE system components:

opmnctl status

15.1.13.10 Configuring Oracle BI EE

This section describes how to configure Oracle BI EE.

15.1.13.10.1 Setting the Location of the Shared Oracle BI Repository

Perform the following steps in Fusion Middleware Control:

Log into Fusion Middleware Control.

Expand the Business Intelligence node in the Farm_domain_name window.

Click coreapplication.

Click Deployment, then click Repository.

Click Lock and Edit Configuration.

Select Share Repository and specify the Shared Location for the Oracle BI Repository. In a Windows environment, the Enterprise Manager Fusion Middleware Control requires that a UNC path be used to define the shared location of the Repository.

Click Apply.

Click Activate Changes.

15.1.13.10.2 Setting the Shared Global Cache for BI Server

Perform the following steps in Fusion Middleware Control:

Log into Fusion Middleware Control.

Expand the Business Intelligence node in the Farm_domain_name window.

Click coreapplication.

Click Capacity Management, then click Performance.

Click Lock and Edit Configuration.

In the Global Cache section, specify the shared location for the Oracle BI Server Global Cache and specify 250 MB for the global cache size. In a Windows environment, the Enterprise Manager Fusion Middleware Control requires that a UNC path be used to define the shared location of the Oracle BI Server Global Cache.

if you use server-side scripts with Oracle BI Scheduler, it is recommended that you configure a shared directory for the scripts so that they can be shared by all Oracle BI Scheduler components in a cluster.

In a Windows environment, you must specify shared storage using the Universal Naming Convention (UNC). UNC is a PC format for specifying resource locations on a local area network. UNC uses the format \\server-name\shared-resource-path-name.

Click Apply.

Click Activate Changes.

15.1.13.11 Setting Server Configuration Options

Follow these steps to set server configuration options for Oracle BI Publisher:

Copy over the contents of DOMAIN_HOME/config/bipublisher/repository to the shared configuration folder location.

Log into BI Publisher with Administrator credentials and select the Administration tab.

Under System Maintenance, select Server Configuration.

In the Path field, enter the path of the shared location for the Configuration Folder.

15.1.13.16 Disabling Host Name Verification for the BI_SERVER2 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you have not configured the server certificates, you receive errors when managing the different WebLogic Servers. To avoid these errors, disable hostname verification while setting up and validating the topology, and enable it again once the high availability topology configuration is complete.

To disable hostname verification:

Log into the Administration Console.

In the Change Center, click Lock & Edit.

Expand the Environment node in the Domain Structure window.

Click Servers.

Select bi_server2 in the Names column of the table.

Open the SSL tab.

Expand the Advanced section of the page.

Set Hostname Verification to None.

Click Save.

Click Activate Changes.

The changes don't take effect until the BI_SERVER2 managed server restarts.

If you are not sure how to locate the Oracle BI EE Office Server directory, check the LogDir parameter on the About Oracle BI EE Office Server page. The Oracle BI Enterprise Edition Office Server directory is the parent directory of the log directory.

On both APPHOST1 and APPHOST2, open bioffice.xml for editing and modify the BI Office properties shown in Table 15-5.

Important: If SSO is enabled, enter the URL for the protected analytics servlet that you deployed when configuring Oracle BI for Microsoft Office to integrate with the SSO-enabled Oracle BI Server. Web services requests between the Oracle BI for Microsoft Office Server and Presentation Services use the URL that you specify here.

SawUseSSO

0 = No (Default)

1 = Yes

Set this property to 1 if the Oracle Business Intelligence implementation is enabled for SSO.

SawWebURLforSSO

https://bi.mydomain.com:443/analytics/saw.dll

When SSO is enabled, use this property to enter the public URL that enables external users to access Oracle Business Intelligence using SSO from Oracle BI for Microsoft Office.

Restart the Oracle BI for Microsoft Office application, as follows:

Log in to the Administration Console.

Click Deployments in the Domain Structure window.

Select bioffice(11.1.1).

Click Stop.

After the application stops, click Start.

Validate that the SawBaseURL parameter has been updated on the About Oracle BI EE Office Server page.

15.1.13.17.1 Validating Oracle BI for Microsoft Office Configuration

Follow these steps to validate configuration for Oracle BI for Microsoft Office:

Log in to Oracle BI Presentation Services at:

https://bi.mydomain.com:443/analytics

In the lower left pane, under the Get Started heading, select Download BI Desktop Tools and then select Oracle BI for MS Office.

Application Name: Enter the Application Name that you defined for the Oracle BI for Microsoft Office Server when you deployed the Oracle BI for Microsoft Office Server application to WLS. The default name is bioffice.

If you do not want to use the system user for the connection, deselect Use System User and specify the BIImpersonateUser credentials for Username and Password. For more information about the BIImpersonateUser user in this context, see Credentials for Connecting to the Oracle BI EE Presentation Catalog in the Oracle Fusion Middleware Developer's Guide for Oracle Business Intelligence Enterprise Edition.

Click Test Connection. You should see Connection established successfully. Click Apply.

15.1.13.18.4 Configuring JMS for Oracle BI Publisher

You must configure the location for all persistence stores to a directory visible from both nodes. Change all persistent stores to use this shared base directory.

Log into the Administration Console.

In the Domain Structure window, expand the Services node and then click the Persistent Stores node.

In the Change Center, click Lock & Edit.

Click on BipJmsStore and enter a directory that is located in the shared storage. This shared storage is accessible from both APPHOST1 and APPHOST2:

ORACLE_BASE/admin/domain_name/bi_cluster/jms

Click Save and Activate Changes.

In the Domain Structure window, expand the Services node and then click the Persistent Stores node.

In the Change Center, click Lock & Edit.

Click New, and then Create File Store.

Enter a name (for example, BipJmsStore2) and target BI_SERVER2. Enter a directory that is located in shared storage so that it is accessible from both APPHOST1 and APPHOST2:

ORACLE_BASE/admin/domain_name/bi_cluster/jms

Click OK and activate the changes.

In the Domain Structure window, expand the Services node and then click the Messaging > JMS Servers node.

In the Change Center, click Lock & Edit.

Click New.

Enter a name (for example, BipJmsServer2) and in the Persistence Store drop-down list, select BipJmsStore2 and click Next.

Select BI_SERVER2 as the target.

Click Finish and Activate Changes.

In the Domain Structure window, expand the Services node and then click the Messaging > JMS Modules node.

In the Change Center, click Lock & Edit.

Click BIPJmsResource and then click the Subdeployments tab.

Target the Subdeployment BipJmsSubDeployment to both BipJmsServer1 and BipJmsServer2.

Each server has a transaction log, which stores information about committed transactions coordinated by the server that may not have been completed. WebLogic Server uses the transaction log when recovering from system fails or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to the server.

Note:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

To set the location for the default persistence store for BI_SERVER1:

Log into the Administration Console.

In the Change Center, click Lock & Edit.

In the Domain Structure window, expand the Environment node and then click the Servers node.

Click BI_SERVER1 (represented as a hyperlink) in the Name column of the table.

The settings page for BI_SERVER1 opens with the Configuration tab active.

Click the Services tab.

In the Default Store section, enter the path to the folder where the default persistent stores will store its data files. The path directory structure is as follows:

ORACLE_BASE/admin/domain_name/bi_cluster/tlogs

Click Save and Activate Changes.

Repeat these steps for the BI_SERVER2 server.

Note:

To enable Transaction Recovery Service migration, specify a location on a persistent storage solution that is available to other servers in the cluster. Both APPHOST1 and APPHOST2 must be able to access this directory and the directory must exist before you restart the server.

15.1.13.19 Starting the System in APPHOST2

This section describes procedures for starting the system in APPHOST2.

15.1.13.19.2 Starting and Validating the BI_SERVER2 Managed Server

To start the BI_SERVER2 managed server and check that it is configured correctly:

Start the bi_server2 managed server using Administration Console, as follows:

Expand the Environment node in the Domain Structure window.

Choose Servers.

Click the Control tab.

Select bi_server2 and then click Start.

Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming", wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors

When BI_SERVER2 is started, the following URLs become available:

Access http://APPHOST2VHN1:9704/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data opens.

Note:

The configuration is incorrect if no policies or assertion templates appear.

Access http://APPHOST2VHN1:9704/xmlpserver to verify the status of the Oracle BI Publisher application.

15.1.13.19.3 Starting and Validating the Business Intelligence Enterprise Edition System Components

15.1.13.20.1 Validating Access Through Oracle HTTP Server

In the Administration Console, verify that the BI Server status is Running. If the status is Starting or Resuming, wait for the server status to change to Started. If the console shows another status (such as Admin), check the server output log files for errors.

Verify that you can access these URLs:

http://WEBHOST1:7777/wsm-pm

http://WEBHOST2:7777/wsm-pm

http://WEBHOST1:7777/analytics

http://WEBHOST2:7777/analytics

http://WEBHOST1:7777/xmlpserver

http://WEBHOST2:7777/xmlpserver

http://WEBHOST1:7777/bioffice/about.jsp

http://WEBHOST2:7777/bioffice/about.jsp

http://WEBHOST1:7777/mapviewer

http://WEBHOST2:7777/mapviewer

Verify that you can access these URLs using your load balancing router address:

http://bi.mycompany.com:80/analytics

http://bi.mycompany.com:80/xmlpserver

http://bi.mycompany.com:80/wsm-pm

http://bi.mycompany.com:80/bioffice/about.jsp

http://bi.mycompany.com:80/mapviewer

Follow these instructions to ensure that routing and failover from the HTTP Server to the bi_cluster is working correctly:

While BI_SERVER2 is running, stop BI_SERVER1 from the Administration Console.

Access the following URLs and verify the appropriate functionality:

WEBHOST1:7777/wsm-pm

WEBHOST1:7777/analytics

WEBHOST1:7777/xmlpserver

WEBHOST1:7777/bioffice/about.jsp

Start BI_SERVER1 from the Administration Console.

Stop BI_SERVER2.

Access the URLs in Step 2 above again and verify the appropriate functionality.

15.1.13.21 Setting the Frontend HTTP Host and Port

You must set the frontend HTTP host and port for the Oracle WebLogic Server cluster. To do this, follow these steps:

In the Change Center of the Administration Console, click Lock & Edit.

In the left pane, choose Environment in the Domain Structure window and then choose Clusters. The Summary of Clusters page appears.

Select the bi_cluster cluster.

Select HTTP.

Set the values for the following:

Frontend Host: bi.mycompany.com

Frontend HTTP Port: 80

Frontend HTTPS Port: Leave this field blank

Note:

Make sure this address is correct and available (the load balancer is up). An incorrect value, for example, http:// in the address or trailing / in the hostname, may prevent the BI system from being accessible even when using the virtual IPs to access it.

Click Save.

To activate the changes, click Activate Changes.

Restart the servers to make the Frontend Host directive in the cluster effective.

15.1.13.22 Configuring Server Migration for the BI_SERVERn Servers

In this high availability topology, you must configure server migration for the bi_server1 and bi_server2 Managed Servers:

Configure the bi_server1 Managed Server to restart on APPHOST2 should a failure occur.

Configure the bi_server2 Managed Server to restart on APPHOST1 should a failure occur.

For this configuration, the bi_server1 and bi_server2 servers listen on specific floating IPs that WLS Server Migration fails over.

For a generic overview of how to configure a GridLink data source, see Creating a GridLink Data Source in the Oracle Fusion Middleware Configuring and Managing JDBC Data Sources for Oracle WebLogic Server guide.

Creating a Multi Data Source

You create a data source to each of the Oracle RAC database instances during the process of setting up the multi data source, both for these data sources and the global leasing multi data source. Note the following when creating a data source:

Ensure that this is a non-XA data source.

The names of the multi data sources are in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.

Use Oracle's Driver (Thin) Version 9.0.1, 9.2.0, 10, 11.

Data sources do not require support for global transactions. Therefore, do not use any type of distributed transaction emulation/participation algorithm for the data source (do not choose the Supports Global Transactions option, or the Logging Last Resource, Emulate Two-Phase Commit, or One-Phase Commit options of the Supports Global Transactions option), and specify a service name for your database.

Make sure the initial connection pool capacity of the data sources is set to 0 (zero). To do this, select Services, then JDBC, and then Datasources. In the Datasources screen, click the Datasource Name, then click the Connection Pool tab, and enter 0 (zero) in the Initial Capacity field.

To create a multi data source:

From the Domain Structure window in the Administration Console, expand the Services node, then click Data Sources. The Summary of JDBC Data Sources page appears.

Enter leasing-rac0 as the name. Enter jdbc/leasing-rac0 as the JNDI name. Enter oracle as the database type. For the driver type, select Oracle Driver (Thin) for RAC server-Instance connection Version 10,11.

Note:

When creating the multi data sources for the leasing table, enter names in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.

Click Create a New Data Source for the second instance of your Oracle RAC database, target it to the bi_cluster, and then repeat the steps for the second instance of your Oracle RAC database.

Add the second data source to your multi data source.

Click Activate Changes.

15.1.13.22.3 Editing Node Manager's Properties File

This section describes how to edit the Node Manager properties file, nodemanager.properties. This needs to be done for the Node Managers in both nodes where server migration is being configured:

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

Interface: This property specifies the interface name for the floating IP (eth0, for example, on Linux).

Note:

Do not specify the sub interface, such as eth0:1 or eth0:2. This interface is to be used without the :0 or :1. The Node Manager's scripts traverse the different :X enabled IPs to determine which to add or remove. For example, the valid values in Linux environments are eth0, eth1, or, eth2, eth3, ethn, depending on the number of interfaces configured.

Note:

For Windows, the Interface should be set to the Network Interface Name. For example: Interface="Local Area Connection".

NetMask: This property specifies the net mask for the interface for the floating IP. The net mask should the same as the net mask on the interface; 255.255.255.0 is used as an example in this document.

UseMACBroadcast: This property specifies whether or not to use a node's MAC address when sending ARP packets, that is, whether or not to use the -b flag in the arping command.

Verify in Node Manager's output (shell where Node Manager is started) that these properties are being used, or problems may arise during migration. You should see something like this in Node Manager's output:

The steps below are not required if the server properties (start properties) have been properly set and Node Manager can start the servers remotely.

Set the following property in the nodemanager.properties file:

StartScriptEnabled: Set this property to true. This is required for Node Manager to start the managed servers using start scripts.

Start Node Manager on APPHOST1 and APPHOST2 by running the startNodeManager.sh script, which is located in the WL_HOME/server/bin directory.

Note:

When running Node Manager from a shared storage installation, multiple nodes are started using the same nodemanager.properties file. However, each node may require different NetMask or Interface properties. In this case, specify individual parameters on a per-node basis using environment variables. For example, to use a different interface (eth3) in APPHOSTn, use the Interface environment variable as follows: APPHOSTn> export JAVA_OPTIONS=-DInterface=eth3 and start Node Manager after the variable has been set in the shell.

15.1.13.22.4 Setting Environment and Superuser Privileges for the wlsifconfig.sh Script

This section describes how to set environment and superuser privileges for the wlsifconfig.sh script:

Note:

On Windows, the script is named wlsifconfig.cmd and users with the Administrator privilege can run it.

For security reasons, sudo should be restricted to the subset of commands required to run the wlsifconfig.sh script. For example, perform these steps to set the environment and superuser privileges for the wlsifconfig.sh script:

Grant sudo privilege to the WebLogic user (oracle) with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries.

Verify that the WebLogic user ('oracle') can run the script. The following is an example of an entry inside /etc/sudoers granting sudo execution privilege for oracle and also over ifconfig and arping:

Ask the system administrator for the sudo and system rights as appropriate to this step.

15.1.13.22.5 Configuring Server Migration Targets

This section describes how to configure server migration targets. You first assign all the available nodes for the cluster's members and then specify candidate machines (in order of preference) for each server that is configured with server migration. Follow these steps to configure cluster migration in a migration in a cluster:

Log in to the Administration Console (http://Host:Admin_Port/console). Typically, Admin_Port is 7001 by default.

In the Domain Structure window, expand Environment and select Clusters.

Click the cluster for which you want to configure migration (bi_cluster) in the Name column of the table.

Click the Migration tab.

In the Change Center, click Lock & Edit.

In the Available field, select the machine to which to enable migration and click the right arrow. In this case, select APPHOST1 and APPHOST2.

Select the data source to be used for automatic migration. In this case, select the leasing data source.

Click Save. Click Activate Changes.

Set the candidate machines for server migration. You must perform this task for all of the managed servers as follows:

In the Domain Structure window of the Administration Console, expand Environment and select Servers.

Tip:

Click Customize this table in the Summary of Servers page and move Current Machine from the Available window to the Chosen window to view the machine on which the server is running. This will be different from the configuration if the server gets migrated automatically.

Select the server you want to configure migration for.

Click the Migration tab.

In the Available field, located in the Migration Configuration section, select the machines to which to enable migration and click the right arrow. For bi_server1, select APPHOST2. For bi_server2, select APPHOST1.

Restart the administration server, node managers, and the servers for which server migration has been configured.

15.1.13.22.6 Testing the Server Migration

The final step is to test the server migration. To verify that server migration is working properly:

From APPHOST1:

Force stop the bi_server1 managed server. Run the command:

APPHOST1> kill -9 pid

where pid specifies the process ID of the managed server. You can identify the pid in the node by running this command:

APPHOST1> ps -ef | grep bi_server1

Note:

For Windows, the Managed Server can be terminated by using the taskkill command. For example:

taskkill /f /pid <pid>

Where <pid> is the process Id of the Managed Server.

To determine the process Id of the Managed Server run the following command and identify the pid of the bi_servern Managed Server.

MW_HOME\jrockit_160_<version>\bin\jps -l -v

Watch the Node Manager console. You should see a message indicating that bi_server1's floating IP has been disabled.

Wait for Node Manager to try a second restart of bi_server1. It waits for a fence period of 30 seconds before trying this restart.

Once Node Manager restarts the server, stop it again. Node Manager should now log a message indicating that the server will not be restarted again locally.

From APPHOST2:

Watch the local Node Manager console. After 30 seconds since the last try to restart bi_server1 on APPHOST1, Node Manager on APPHOST2 should prompt that the floating IP for bi_server1 is being brought up and that the server is being restarted in this node.

Access one of the applications (for example, BI Publisher) using the same IP.

Verification From the Administration Console

Migration can also be verified in the Administration Console:

Log in to the Administration Console.

Click Domain on the left console.

Click the Monitoring tab and then the Migration subtype.

The Migration Status table provides information on the status of the migration.

Note:

After a server is migrated, to fail it back to its original node/machine, stop the managed server from the Oracle WebLogic Administration Console and then start it again. The appropriate Node Manager will start the managed server on the machine to which it was originally assigned.

15.1.13.23 Scaling Up the Oracle BI EE Topology

When you scale up the Oracle BI EE topology, you add additional system components to one of the existing nodes in your Oracle BI EE high availability topology.

This section assumes that you already have a high availability topology that includes at least two nodes, with a managed server and a full set of system components on each node. To scale up the topology, you increase the number of system components running on one of your existing nodes.

Note that it is not necessary to run multiple managed servers on a given node.

To scale up the Oracle BI EE topology:

Log in to Fusion Middleware Control.

Expand the Business Intelligence node in the Farm_domain_name window.

Click coreapplication.

Click Capacity Management, then click Scalability.

Click Lock and Edit Configuration.

Use arrow keys to change the number of BI Servers, Presentation Services, or JavaHosts.

Click Apply then click Activate Changes.

Click Overview then click Restart.

15.1.13.24 Scaling Out the Oracle BI EE Topology to a New Node (APPHOST3)

When you scale out the Oracle BI EE topology, you add a new managed server and set of system components to a new node in your topology (APPHOST3). This section assumes that you already have a high availability topology that includes at least two nodes, with a managed server and a full set of system components on each node.

Before performing the steps in this section, check that you meet these requirements:

There must be existing nodes running Oracle Business Intelligence Managed Servers within the topology.

The new node (APPHOST3) can access the existing home directories for Oracle WebLogic Server and Oracle Business Intelligence.

When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, it is recommended that you keep the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. The directory paths you use for binary files and domains when installing new nodes must be identical to those for the first node. To update the Middleware home list to add or remove a WL_HOME, edit the MW_HOME/.home file. See the steps below.

The new server can use a new individual domain directory or, if the other Managed Servers domain directories reside on shared storage, reuse the domain directories on those servers.

To scale out Oracle Business Intelligence on APPHOST3:

On APPHOST3, mount the existing Middleware home, which should include the Oracle Business Intelligence installation and (optionally, if the domain directory for Managed Servers in other nodes resides on shared storage) the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.

To attach ORACLE_HOME in shared storage to the local Oracle Inventory, run the following command:

15.2 High Availability for Oracle Business Intelligence Publisher

Oracle Business Intelligence Publisher (Oracle BI Publisher) offers you the most efficient, scalable reporting solution available for complex, distributed environments. It provides a central architecture for generating and delivering information to employees, customers, and suppliers—both securely and in the right format. Oracle BI Publisher reduces the high costs associated with the development, customization and maintenance of business documents, while increasing the efficiency of reports management.

This section describes how to design and deploy a high availability environment for Oracle BI Publisher.

15.2.1.1.3 Process Lifecycle

15.2.1.1.4 Request Flow

JMS is used as a backbone to the Oracle BI Publisher batch report processing system. JMS is used as a messaging board in a transactional fashion. Every report is divided into these stages of execution:

Data retrieval

Data formatting

Report delivery

Each of these stages appears as a job request in the JMS queue. If a node goes down, the other nodes continue to service the queue. However, if a report job is in one of these stages of execution—data retrieval, data formatting, or report delivery—the job is marked as failed and you must resubmit it manually.

15.2.1.1.5 External Dependencies

Oracle BI Publisher depends on:

Database repository: for scheduled jobs information.

Storage of Oracle BI Publisher artifacts: These artifacts include reports, definitions, and layouts. The storage is done in two different ways:

In standalone mode: Oracle BI Publisher uses a shared file system (such as SAN or NAS).

DBMS for report data: Oracle BI Publisher queries the DBMS to retrieve the report data that needs to be processed.

Web services: for data retrieval.

15.2.1.1.6 Configuration Artifacts

Oracle BI Publisher is a standard Java EE application.

15.2.1.1.7 Deployment Artifacts

Oracle BI Publisher does not have any special deployment artifacts.

15.2.1.1.8 Log Files

Oracle BI Publisher is a Java EE application deployed on Oracle WebLogic Server. All log messages are logged in the server log file of the Oracle WebLogic Server that the application is deployed on. The default location of the server log is:

In Figure 15-11, incoming requests are received by the hardware load balancer, which routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts have Oracle HTTP Server installed.

The Oracle WebLogic Server on which Oracle BI Publisher runs is installed on APPHOST1 and APPHOST2 in the application tier. The Administration Server on APPHOST2 is passive. The Administration Server can be made active on APPHOST2 if APPHOST1 becomes unavailable, as described in Chapter 3, "High Availability for WebLogic Server." Oracle BI Publisher is deployed on the BI_SERVER1 and BI_SERVER2 managed servers on these hosts. These managed servers are configured in an Oracle WebLogic cluster that enables them to work in an active-active manner. Whole server migration is configured for the managed servers.

The BI domain uses virtual hostnames as the listen addresses for the BI managed servers. You must enable VIP mapping for each of these hostnames on the two BI Machines, (VIP1 on APPHOST1 and VIP2 on APPHOST2), and must correctly resolve the virtual hostnames in the network system used by the topology (either by DNS Server or by hosts resolution). Section 15.1.13.22, "Configuring Server Migration for the BI_SERVERn Servers" provides more details on configuring server migration for the BI servers.

In the data tier, shared external storage is set up to store Oracle BI Publisher Repository metadata such as record definitions, report layouts, and data models, as well as the Oracle BI Publisher JMS persistence store.

An Oracle RAC database is used for reports data, and is also recommended for the enterprise database.

Oracle BI Publisher supports an active-active high availability configuration. Each node acts as an independent server that shares a common repository and the scheduler database with the other Oracle BI Publisher nodes.

The Oracle BI Publisher repository (which contains all content, such as reports and data models) is stored in the Oracle BI Presentation Catalog when BI Publisher is configured with Oracle BI EE, and it is stored on a shared file system when Oracle BI Publisher is installed by itself.

The Oracle BI Publisher configuration folder must be on a shared file system.

The shared repository stores the following Oracle BI Publisher artifacts:

Report definitions

Report templates

Data models

Oracle BI Publisher configuration

The Scheduler database is a shared database that stores the following information:

Details about the reports (parameters)

Execution status

Execution history

Snapshots of previous report runs

A hardware or software load balancer can be used as a front end to the Oracle BI Publisher nodes in a high availability environment.

Artifacts and configurations are stored in the shared repository, and each instance reads the repository independently.

15.2.2.1.1 Shared Files and Directories

The Oracle BI Publisher shared files are the shared repository and Scheduler database described in the previous section.

15.2.2.1.2 Cluster-Wide Configuration Changes

The Configuration Folder contains all configuration, security, and data sources that you set up with BI Publisher. When the Configuration Folder is on shared storage, any changes made will be applied to all nodes in the cluster.

15.2.2.2 Protection from Failures and Expected Behaviors

Node Manager can be set up to restart a failed Oracle BI Publisher instance.

When an Oracle BI Publisher instance restarts, it does not affect the other running instances.

When a node fails, the behavior is:

In a deployment where single sign-on is not implemented, the user will be asked to log in again.

Any transaction that included editing is saved.

15.2.2.3 Troubleshooting

Oracle BI Publisher logging is included in the WebLogic Server logs in the default location:

DOMAIN_HOME/servers/serverName/logs/serverName-diagnostic.log

Also, the following file includes BI Publisher related messages:

DOMAIN_HOME/servers/serverName/logs/bipublisher/bipublisher.log

Configuration information is stored in the shared repository. The configuration files are stored under the Admin directory in the shared repository.

15.2.3 Oracle BI Publisher High Availability Configuration Steps

This section describes how to set up a two node highly available configuration for Oracle BI Publisher. The architecture targeted for the configuration steps is shown in Figure 15-11.

Note:

Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process.

15.2.3.1 Preparing the Environment: Prerequisite Steps Before Setting Up an Oracle BI Publisher High Availability Configuration

This section includes the prerequisites for setting up the BI Publisher high availability configuration.

15.2.3.1.1 Database Prerequisites

Oracle BI Publisher supports the following database versions:

Oracle Database 10g (10.2.0.4 or later for non-XE database)

Oracle Database 11g (11.1.0.7 or later for non-XE database)

To determine the database version, execute this query:

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.2.3.1.2 VIP and IP Prerequisites

You configure the BI managed servers to listen on different virtual IPs, shown in Table 15-7. This requires the provisioning of the corresponding VIP in the node and related host names in the DNS system in your network. Ensure that the different VIPs are available and are reachable before running the installation.

Table 15-7 BI Publisher Virtual Hosts

Virtual IP

Virtual IP Maps To

Description

VIP1

APPHOST1VHN1

APPHOST1VHN1 is the virtual hostname that maps to the listen address for BI_SERVER1 and fails over with server migration of this managed server. It is enabled on the node where BI_SERVER1 process is running (APPHOST1 by default).

VIP2

APPHOST2VHN1

APPHOST2VHN1 is the virtual hostname that maps to the listen address for BI_SERVER2 and fails over with server migration of this managed server. It is enabled on the node where BI_SERVER2 process is running (APPHOST2 by default).

15.2.3.1.3 Shared Storage Prerequisites

For proper recovery in case of failure, store both JMS and transaction logs in a location that is accessible to all the nodes that can resume the operations after a failure in a managed server. This requires a shared storage location that can be referenced by multiple nodes. Table 15-8 lists the contents of shared storage.

Table 15-8 Contents of BI Publisher Shared Storage

Server

Type of Data

Volume in Shared Storage

Directory

Files

BI_SERVER1 and BI_SERVER2

Transaction logs

VOL2

ORACLE_BASE/admin/domain_name/bi_cluster_name/tlogs

Common location (stores decided by WebLogic Server)

BI_SERVER1 and BI_SERVER2

JMS stores

VOL2

ORACLE_BASE/admin/domain_name/bi_cluster_name/jms

Common location, but individual store per server. For example: BipJmsStore for BI_SERVER1 and BipJmsStore2 for BI_SERVER2)

BI_SERVER1 and BI_SERVER2

BI Publisher Configuration folder

VOL1

ORACLE_BASE/domain_name/config/bipublisher/repository

Common location

BI_SERVER1 and BI_SERVER2

BI Publisher Catalog repository

VOL1

ORACLE_BASE/domain_name/config/bipublisher/catalog

Common location

BI_SERVER1 and BI_SERVER2

BI Publisher Scheduler Temp directory

VOL1

ORACLE_BASE/domain_name/config/bipublisher/temp

Common location

The shared storage can be a NAS or SAN device. The following is an example command based on a NAS device. Your options may be different from the ones specified in this section.

15.2.3.1.4 Clock Synchronization

You must synchronize all server clocks that participate in the cluster to within one second difference. To synchronize the clocks, use a single network time server and point each server to it. The procedure to point to the network time server is different from Windows to Linux. Refer to your operating system's manual.

15.2.3.1.5 Installing and Configuring the Database Repository

This section describes how to install and configure the database repository.

Host Name: Specify the name of the node on which the database resides. For the Oracle RAC database, specify the VIP name or one of the node names as the hostname, for example:

BIDBHOST1-VIP

Port: Specify the listen port number for the database: 1521

Service Name: Specify the service name of the database:

biha.mycompany.com

Username: Specify the name of the user with DBA or SYSDBA privilege: SYS

Password: Enter the password for the SYS user.

Role: Select the database user's role from the list: SYSDBA (required by the SYS user).

Click Next.

In the Select Components screen:

Select Create a new Prefix, and enter a prefix to use for the database schemas, for example, BIHA. You can specify up to six characters as a prefix. Prefixes are used to create logical groupings of multiple repositories in a database. For more information, see Oracle Fusion Middleware Repository Creation Utility User's Guide.

Tip:

Note the name of this schema because the upcoming steps require this information.

This section describes the load balancer prerequisites for deploying an Oracle BI Publisher high availability environment.

Load Balancers

BI Publisher uses a hardware load balancer when deployed in a high availability configuration with two Oracle HTTP Servers as web tier components.

Virtual Server Names

bi.mycompany.com is a virtual server name that acts as the access point for all HTTP traffic to the runtime BI components, such as Oracle BI Publisher. Traffic to both SSL and non-SSL ports is configured, and typically non-SSL is redirected to SSL. Clients access this service using the address bi.mycompany.com:443. This virtual server is defined on the load balancer.

On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.

Note:

The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen does not appear for this installation, verify:

If the /etc/oraInst.loc file exists.

If the file exists, the Inventory directory listed is valid.

Whether or not the user performing the installation has write permissions for the Inventory directory.

On the Welcome screen, click Next.

On the Select Installation Type screen, select Install and Configure, and click Next.

On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.

On the Specify Installation Location screen, specify:

Oracle Middleware Home: ORACLE_BASE/product/fmw (grayed out)

Oracle Home Directory: Oracle_WT1

Click Next.

On the Configure Components screen:

Select Oracle HTTP Server.

Do not select Associate Selected Components with Weblogic Domain.

Click Next.

On the Specify Component Details screen, enter the following values for WEBHOST1:

If you specify a custom port, select Specify Ports using Configuration File and then use the Browse function to select the file.

Enter the Oracle HTTP Server port, for example: 7777

Click Next.

In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.

On the Installation Summary screen, ensure that the selections are correct. If they are not, click Back and make the necessary fixes. After ensuring that the selections are correct, click Install.

On the Installation Progress screen on UNIX systems, a dialog appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

Click Next.

On the Configuration Progress screen, multiple configuration assistants are launched in succession; this process can be lengthy. Click Next.

On the Installation Complete screen, click Finish to exit.

Repeat the steps for WEBHOST2 and configure your load balancer with a pool containing both the WEBHOST1 and WEBHOST2 addresses.

15.2.3.1.9 Validating Oracle HTTP Server

To verify that Oracle HTTP Server is set up correctly, access the root URL context of the server by using the following URLs in the browser:

http://WEBHOST1:7777/
http://WEBHOST2:7777/

If Oracle HTTP Server is set up correctly, the Oracle FMW Welcome screen appears in the browser.

15.2.3.2 Installing Oracle Fusion Middleware Home

This section describes the procedure for installing Oracle Fusion Middleware on all nodes in the application tier that run Oracle WebLogic Server and Oracle Fusion Middleware BI EE. Repeat the procedure (described below for APPHOST1) for installing WebLogic Server and BI Publisher in APPHOST2. The directory paths for binary files and domains used when installing new nodes must be exactly the same as those used for first node.

Install the following Oracle Fusion Middleware components:

Oracle WebLogic Server

Oracle Fusion Middleware BI EE

15.2.3.2.1 Installing Oracle WebLogic Server

Follow these steps to install Oracle WebLogic Server:

Start the installer for Oracle WebLogic Server from the installation media.

In the Welcome screen, click Next.

In the Choose Middleware Home Directory screen:

Select Create a new Middleware Home.

For the Middleware Home Directory, enter ORACLE_BASE/product/fmw

Note:

ORACLE_BASE is the base directory under which Oracle products are installed. The recommended value is /u01/app/oracle.

Click Next.

In the Register for Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.

In the Choose Install Type screen, select Typical and click Next.

In the Choose Product Installation Directories screen, accept the directory ORACLE_BASE/product/fmw/wlserver_10.3 for WebLogic Server and ORACLE_BASE/product/fmw/coherence_3.6 for Oracle Coherence and click Next.

In the Installation Summary screen, click Next.

The Oracle WebLogic Server software is installed.

In the Installation Complete screen, clear the Run Quickstart check box and click Done.

15.2.3.2.2 Installing Oracle Fusion Middleware for BI Publisher

On the Linux platform, if the /etc/oraInst.loc file exists, check that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory. If the /etc/oraInst.loc file does not exist, you can skip this step.

Start the installer for Oracle Fusion Middleware Business Intelligence 11g from the installation media:

On UNIX:

APPHOST1>./runInstaller

On Windows:

APPHOST1> setup.exe

In the Specify Inventory Directory screen:

Enter HOME/oraInventory, where HOME is the home directory of the user performing the installation (this is the recommended location).

Enter the OS group for the user performing the installation.

Click Next.

Follow the instructions on screen to execute /createCentralnventory.sh as root.

Click OK.

In the Welcome screen, click Next.

In the Select Installation Type screen, select Software Only Install and click Next.

In the Prerequisite Checks screen, verify that all checks complete successfully, and click Next.

In the Specify Installation Location screen, select the previously installed Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name (Oracle_BI1).

Click Next.

In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.

In the Summary screen, click Install.

In the Installation Progress screen, click Next.

In the Complete screen, click Finish.

15.2.3.3 Enabling VIP1 in APPHOST1 and VIP2 in APPHOST2

The BI domain uses virtual hostnames as the listen addresses for the BI managed servers. You must enable the VIPs, mapping each of these hostnames on the two BI machines (VIP1 on APPHOST1 and VIP2 on APPHOST2), and they must correctly resolve to the virtual hostnames in the network system used by the topology (either by DNS Server or hosts resolution).

15.2.3.4 Creating a Domain with the Administration Server and the First BI_SERVER1 Managed Server

This section describes how to create a domain and the first WebLogic Server BI managed server using the Oracle Business Intelligence Configuration Assistant, Administration Console, and Oracle Enterprise Manager. Ensure that the database where you installed the repository is running. For Oracle RAC databases, all the instances must be running.

Note:

Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.

Run the Configuration Assistant from the Oracle home directory to create a domain containing the Administration Server and the managed server with BI Publisher:

Change the directory to the location of the Configuration Assistant:

APPHOST1> cd ORACLE_HOME/bin

Start the Configuration Assistant:

On UNIX:

APPHOST1> ./config.sh

On Windows:

APPHOST1> config.cmd

In the Welcome screen, click Next.

In the Prerequisite Checks screen, verify that all checks complete successfully and click Next.

The Create or Scale Out BI System screen opens. Select Create New BI System and specify the following:

In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.

In the Summary screen, click Configure.

In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.

In the Complete screen, click Finish.

15.2.3.5 Creating boot.properties for the Administration Server on APPHOST1

This is an optional step for enabling the Administration Server to start without prompting you for the administrator username and password. Create a boot.properties file for the Administration Server on APPHOST1.

Verify that you can access Enterprise Manager at http://APPHOST1:7001/em.

15.2.3.7 Setting the Listen Address for BI_SERVER1 Managed Server

To set the managed server listen address:

Log into the Administration Console.

In the Change Center, click Lock & Edit.

Expand the Environment node in the Domain Structure window.

Click Servers.

Select bi_server1 in the Names column of the table.

Set the Listen Address to APPHOST1VHN1.

Click Save.

Save and activate the changes.

The changes will not take effect until the BI_SERVER1 managed server is restarted.

15.2.3.8 Disabling Host Name Verification for the BI_SERVER1 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you have not configured the server certificates, you will receive errors when managing the different WebLogic Servers. To avoid these errors, disable hostname verification while setting up and validating the topology, and enable it again once the high availability topology configuration is complete.

To disable hostname verification:

Log into the Administration Console.

In the Change Center, click Lock & Edit.

Expand the Environment node in the Domain Structure window.

Click Servers.

Select bi_server1 in the Names column of the table. The settings page opens.

Open the SSL tab.

Expand the Advanced section of the page.

Set Hostname Verification to None.

Click Save.

Save and activate the changes.

The change will not take effect until the BI_SERVER1 managed server is restarted.

15.2.3.9 Starting the System in APPHOST1

This section describes how to start Node Manager on APPHOST1 and how to start and validate the BI_SERVER1 managed server on APPHOST1.

15.2.3.9.1 Starting Node Manager on APPHOST1

Usually, Node Manager is started automatically when config.sh completes. If Node Manager is not running for some reason, start it on APPHOST1 using these commands:

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

15.2.3.9.2 Starting and Validating the BI_SERVER1 Managed Server

To start the BI_SERVER1 managed server and check that it is configured correctly:

Start the bi_server1 managed server using Administration Console, as follows:

Expand the Environment node in the Domain Structure window.

Choose Servers.

Click the Control tab.

Select bi_server1 and then click Start.

Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming", wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors

Update the Shared Directory by entering a directory that is located in the shared storage. This shared storage is accessible from both APPHOST1 and APPHOST2.Continue with the rest of the steps.Click Apply.

Check the Scheduler status from the Scheduler Diagnostics tab.

15.2.3.11 Scaling Out the BI System on APPHOST2

To scale out the BI System.

Change the directory to the location of the Configuration Assistant:

APPHOST2> cd ORACLE_HOME/bin

Start the Configuration Assistant:

APPHOST2> ./config.sh

In the Welcome screen, click Next.

On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Verify that all the Configuration Tools completed successfully and click Next.

In the Complete screen, click Finish.

15.2.3.12 Setting the Listen Address for the BI_SERVER2 Managed Server

To set the BI_SERVER2 managed server listen address:

Log into the Administration Console.

In the Change Center, click Lock & Edit.

Expand the Environment node in the Domain Structure window.

Click Servers.

Select bi_server2 in the Names column of the table.

Set the Listen Address to APPHOST2VHN1. Click Save

Save and activate the changes.

Changes take effect when the BI_SERVER2 managed server restarts.

15.2.3.13 Disabling Host Name Verification for the BI_SERVER2 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you have not configured the server certificates, you receive errors when managing the different WebLogic Servers. To avoid these errors, disable hostname verification while setting up and validating the topology, and enable it again after the high availability topology configuration is complete.

Each server has a transaction log, which stores information about committed transactions coordinated by the server that may not have been completed. WebLogic Server uses the transaction log when recovering from system fails or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to the server.

Note:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

To set the location for the default persistence store for BI_SERVER1:

Log into the Administration Console.

In the Domain Structure window, expand the Environment node and then click the Servers node.

Click BI_SERVER1 in the Name column of the table.

Click the Services tab. In the Change Center, click Lock & Edit.

In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The path directory structure is as follows:

ORACLE_BASE/admin/domain_name/bi_cluster/tlogs

Click Save and Activate Changes.

Repeat these steps for the BI_SERVER2 server.

Note:

To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both APPHOST1 and APPHOST2 must be able to access this directory. This directory must also exist before you restart the server.

15.2.3.15 Starting the System in APPHOST2

This section describes procedures for starting the system in APPHOST2.

15.2.3.15.2 Starting and Validating the BI_SERVER2 Managed Server

To start the BI_SERVER2 managed server and check that it is configured correctly:

Start the bi_server2 managed server using Administration Console, as follows:

Expand the Environment node in the Domain Structure window.

Choose Servers. Click the Control tab.

Select bi_server2 and then click Start.

Verify that the server status is reported as Running. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another appears, such as Admin or Failed, check the server output log files for errors.

15.2.3.17 Validating Access Through Oracle HTTP Server

Verify that the BI Servers status is reported as Running. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another appears, such as Admin or Failed, check the server output log files for errors

Verify that you can access these URLs:

http://WEBHOST1:7777/wsm-pm

http://WEBHOST2:7777/wsm-pm

http://WEBHOST1:7777/xmlpserver

http://WEBHOST2:7777/xmlpserver

Verify that you can access these URLs using your load balancing router address:

http://bi.mycompany.com:80/xmlpserver

http://bi.mycompany.com:80/wsm-pm

To ensure that routing and failover from the HTTP Server to the bi_cluster is working correctly:

While BI_SERVER2 is running, stop BI_SERVER1 from Administration Console.

Access the following URLs and verify the appropriate functionality:

WEBHOST1:7777/wsm-pm

WEBHOST1:7777/xmlpserver

Start BI_SERVER1 from Administration Console.

Stop BI_SERVER2.

Access the URLs in Step 2 above again and verify the appropriate functionality.

15.2.3.19 Scaling Out the Oracle BI Publisher Topology to a New Node (APPHOST3)

When you scale out the Oracle BI Publisher topology, you add a new managed server and set of system components to a new node in your topology (APPHOST3). This section assumes that you already have a high availability topology that includes at least two nodes, with a managed server and a full set of system components on each node.

Before performing the steps in this section, check that you meet these requirements:

There must be existing nodes running Oracle BI Publisher managed servers within the topology.

The new node (APPHOST3) can access the existing home directories for Oracle WebLogic Server and Oracle Business Intelligence.

When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, it is recommended that you keep the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh. To update the Middleware home list to add or remove a WL_HOME, edit the MW_HOME/.home file. See the steps below.

The new server can use a new individual domain directory or, if the other Managed Servers domain directories reside on shared storage, reuse the domain directories on those servers.

To scale out Oracle BI Publisher on APPHOST3:

On APPHOST3, mount the existing Middleware home, which should include the Oracle Business Intelligence installation and (optionally, if the domain directory for Managed Servers in other nodes resides on shared storage) the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.

To attach ORACLE_HOME in shared storage to the local Oracle Inventory, execute the following command:

15.3 High Availability for Oracle Real-Time Decisions

Oracle Real-Time Decisions (Oracle RTD) is used to provide a ranked list of choices or offers for a request, given a sufficient context for making a decision on the best choices to select from. Oracle RTD always uses a front-end application that is responsible for defining process flow, capturing user interaction, and translating this interaction as input for Oracle RTD decision making. Therefore, Oracle RTD can be seen as more of a decision service rather than a traditional web application.

This section describes how to design and deploy a high availability environment for Oracle RTD.

Decision Server provides the necessary run-time services to execute Oracle RTD applications called Inline Services. Inline Services are developed using the Decision Studio development environment, and are deployed to and run in Oracle RTD Decision Server. For more information about Decision Studio, see the "Decision Studio, RTD Clients and Tools" subsection.

An Inline Service can gather data and analyze characteristics of enterprise business processes on a real-time and continuous basis. It also leverages that data and analysis to provide decision-making capability and feedback to key business processes.

Decision Server stores all its metadata in the Oracle RTD database.

The following elements of an Inline Service play a role in or are affected by a high availability topology (mostly by accessing resources outside of Oracle RTD):

Choices: Choices represent the offers that will be presented through the Inline Service or the targets of study to be tracked by the self-learning models of Oracle RTD. There are two forms of choices: static and dynamic. Static choices are hard coded using Decision Studio. Dynamic choices are defined in an external data source and loaded during the execution of an Inline Service.

Rules: Rules are used to target segments of population, decide whether a choice is eligible, or score a particular choice. Rules are constructed through a graphical rules editor. Rules are loaded by Decision Server during the execution of an Inline Service. Oracle RTD has a type of rules called external rules. These rules are stored in an data source external to Oracle RTD.

Entities: Entities are a logical representation of data used for Oracle RTD modeling and decisioning. The attributes of an entity can be populated via data sources, as incoming parameters from integration points, or derived in real time through custom logic.

Integration Points: Integration points serve as the touchpoints with outside systems interacting with Oracle RTD. There are two classes of integration points: informants and advisors. Informants receive data from outside systems, whereas advisors receive data and also send recommendations back to outside systems.

Predict the likelihood that certain events associated with Choices will occur.

Analyze data correlated with those events.

Statistics Collectors are special models that track statistics about entities.

Models are associated at design time with a Choice Group. This defines the list of Choices to which prediction and reports apply.

Decision Center

Workbench Services, which supports the deployment of Inline Services by Decision Server, also provides the Decision Center web interface. Decision Center displays the structure and decisioning history of Inline Services. Business users use Decision Center to view reports about the effectiveness of their analytical models and to tune their hosting Inline Services.

Decision Center interacts with the Learning Server to query the contents of the Learning Models.

Learning Services

Learning records are created when an Inline Service session closes. Learning records are batched in memory (configurable) and queued to be stored in the Oracle RTD database. This is done for performance reasons - to minimize the number of database transactions required to store learning records in the Oracle RTD database. By default, Oracle RTD buffers 100 records, with a queue for 50 buffers. A worker thread is responsible for writing learning records to the Oracle RTD database.

Learning Services awakens periodically and:

Reads learning records from the database

Generates new predictive models

Each predictive model is associated with a specific Inline Service. Therefore, an Inline Service is only affected when it has a new predictive model. All Inline Services are isolated from updates to another Inline Service's models.

Predictive models are propagated to the Decision Server. Each Decision Server frequently polls the Oracle RTD database for new predictive models. When a new predictive model is found, it is loaded into memory.

Decision Studio, RTD Clients and Tools

Decision Studio is an Eclipse based development environment for developing Oracle RTD Inline Services.

Decision Studio is also used to deploy and download an Inline Service from an Oracle RTD Server through the Oracle RTD Workbench Services web service.

Oracle RTD provides a number of client components that make it easier to integrate with Oracle RTD Decision Server. For example, Oracle RTD provides a Java client that provides a wrapper for Oracle RTD web service calls, caches default result sets on the client side, and provides default responses when the Oracle RTD server is not responding.

Oracle Enterprise Manager Fusion Middleware Control is used to configure Oracle RTD single instance and cluster-wide attributes.

15.3.1.1 Oracle RTD Component Characteristics

This section describes the Oracle RTD component characteristics.

The Oracle RTD Server and its components are Java or web based components. They run either within the Java or web container. Communication between Decision Studio and Oracle RTD clients with the Oracle RTD Server is through a number of web services.

Oracle RTD manages session information locally and does not rely on a web server for session management. This is because Oracle RTD requires long running sessions to complete a business process vs the typical session associated with a web application. A single Decision Server session might receive requests from several HTTP sessions from different client servers. An Oracle RTD session can be fast, or it can last several hours, days or weeks.

If a server fails, the request will be directed to another server and a new session will be created. For the most part, session information is read from an external data source or calculated. These values will be reread or recalculated on a new session. Oracle RTD uses session information to calculate likelihood and not for storing state of a business transaction (this is delegated to a transactional/operational system). Therefore, the loss of session information does not adversely impact a business process.

15.3.1.1.3 External Dependencies

Configuration information for Oracle RTD is self-contained and stored in its own database schema. However, an Inline Service can load its entities or external rules from external data sources.

15.3.1.1.4 Configuration Artifacts

Configuration information is stored in the Oracle RTD database, and it is updated using the Fusion Middleware Control.

Data source configuration information is set using the Administration Console.

15.3.1.1.5 Deployment Artifacts

Oracle RTD Inline Services are created in Decision Studio. Developers use the Decision Studio deployment facility to deploy an Inline Service. The Inline Service is packaged by Oracle RTD Studio and uploaded to an instance of Decision Server. The Decision Server stores all uploaded Inline Services to the Oracle RTD operational tables.

15.3.1.1.6 Log File Locations

You can view Oracle RTD log files using Oracle Enterprise Manager Fusion Middleware Control. To view the log files from the Oracle RTD home page, right-click the deployed Oracle RTD application in the navigator pane, and select Logs > View Log Files. This displays the Log Messages screen, on which you can view the log files. For more information on viewing Oracle RTD log files, see Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

15.3.2 Oracle RTD High Availability Concepts

This section provides conceptual information about using Oracle RTD in a high availability deployment.

In Figure 15-13, incoming requests are received by the hardware load balancer, which routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts have Oracle HTTP Server installed.

Oracle WebLogic Server is installed on APPHOST1 and APPHOST2 in the application tier. The Administration Server can be made active on APPHOST2 if APPHOST1 becomes unavailable, as described in Chapter 3, "High Availability for WebLogic Server." Oracle RTD is deployed on the BI_SERVER1 and BI_SERVER2 managed servers on these hosts. These managed servers are configured in an Oracle WebLogic cluster that enables them to work in an active-active manner.

In the data tier, an Oracle RAC database is used for the Oracle RTD repository, which stores learning models, learning records, prediction models, and Inline Services metadata, and is also recommended for the enterprise database.

Note:

A cluster of Oracle RTD instances front-ended directly by a load balancer (instead of a web tier) is also supported. In this type of deployment, the load balancer has to be configured to ensure sticky session routing using the HTTP headers. See your load balancer documentation for information on configuring it to ensure sticky routing using the HTTP header.

In a clustered installation, instances of RTD components must communicate with other RTD components that can be located in the same host or a remote host. When the components are not in the same host they use an internal Remote Procedure Call (RPC) mechanism to communicate between cluster hosts and convey the response.

In a cluster, Decision Center is typically deployed in the same Oracle RTD instances as Learning Services, because Decision Center needs to communicate with Learning Services. Decision Center is not a singleton, however, so any instances not co-located with the active Learning Services use RPC to communicate with the active Learning Services.

In a cluster, Decision Center is typically deployed in a different Oracle RTD instance than Decision Services, which minimizes the performance and memory impact of Decision Center on Decision Services.

In a cluster, an Inline Service is deployed by Decision Studio to any cluster member, using the same internal WorkBench web service used in a non-clustered installation. The instance to which Decision Studio is connected will load the Inline Service into memory and will save the Inline Service in the database. Other cluster members will notice the new Inline Service in the database, and will load the Inline Service into their own memory.

For performance reasons it is best to deploy Oracle RTD in a cluster with HTTP session affinity enabled. This is because having the context of the Oracle RTD Session is necessary in order to create accurate learning records and making predictions. There is dynamic state in a session that can contribute to learning (for example, the sequence of web pages accessed in this Decision Server session), and that does not come from the database. While this state contributes to learning, it is only in an aggregated manner; there is no personal state, or any state important enough to mirror across servers, even if the state was Serializable. Losing a few sessions because of a server failure will not noticeably impact the integrity of Oracle RTD learning models, which are based on aggregated information.

Each instance of Decision Server in a cluster polls the Oracle RTD operational tables for new or updated Inline Services. If a new or newer version of an Inline Service is found, it is loaded into memory by every member of a cluster.

Oracle RTD uses hardware or software load balancers.

You can inject a Session Key into a web service request. The Session Key is user defined and passed in as a parameter to the Oracle RTD Java client (a wrapper to the Oracle RTD web service). The load balancer must be configured to have session affinity enabled and to retrieve the Session Key from the HTTP header.

Intra-cluster member communication between Oracle RTD instances is performed through its internal intra-cluster RPC technology. The JMS publish/subscribe model is used with a single topic "RTDTopic" created on Oracle RTD deployment (defined in Oracle RTD's Weblogic template). Each Oracle RTD instance subscribes to this single Topic and reads messages that apply to it (through filtering).

An Oracle RTD server may receive a request for which it does not have the request's Session state. In this case, the receiving Decision Server performs a lookup and finds the Decision Server to which this request should be directed. The request will then be forwarded to the correct Decision Server. The forwarding Decision Server will wait on the request to be completed by the receiving Decision Server.

The forwarded request is sent via RPC. Each Oracle RTD server pulls all messages that apply to it from the Oracle RTD JMS Topic.

After the receiving Decision Server completes the request, the call is unwound and the originator of the request forwarding gets the response from the receiving Decision Server. The response is then sent back to the caller.

Singleton Services

In Figure 15-13, the Oracle RTD Learning Service and Batch Manager are singletons. The Learning Service is responsible for building analytical models from data records written by one or more of the Oracle RTD Decision Service instances. An analytical model provides the likelihood of a specific outcome given a set of input values. For example, an analytical model can determine how likely a customer is to purchase a specific product given a prior history of products purchased. Learning models are built in memory; if the active Learning Service fails while building a model, a new Learning Service is activated and it will build the model from scratch with no loss of data. Batch Manager is responsible for starting and managing batch jobs on behalf of the batch administration client. It communicates with Batch Agent instances on other Oracle RTD instances to distribute the work across the cluster. Both Learning Service and Batch Manager are considered Active-Spare singletons.

Cluster Coordinator

Oracle RTD has its own cluster coordinator, which performs these tasks:

It assures that precisely one singleton is active of each type, Learning Service singleton and Batch Manager singleton. Only the cluster coordinator starts or stops a cluster singleton

The cluster coordinator cleans up resources left open by a member that leaves the cluster (this cleanup logic is the same as the node would normally perform for itself when it shuts down in a controlled manner). The coordinator does this cleanup in case the leaving node died unexpectedly before it had a chance to close its own resources. e.g. All Decision Center sessions hosted by a cluster member will be closed by the coordinator when that cluster member leaves the cluster

On startup, each Oracle RTD cluster member vies to become the cluster coordinator by transactionally testing the database to see if another instance is already the coordinator, and inserts itself into the database as the coordinator if no other coordinator exists. A coordinator's right to be the coordinator expires unless periodically renewed by itself, so if a coordinator dies some other cluster member will successfully become coordinator.

15.3.2.1.1 Starting and Stopping the Cluster

You can use the Administration Console to start and stop single instances in an Oracle RTD cluster.

15.3.2.1.2 Cluster-Wide Configuration Changes

Configuration information for Oracle RTD is self-contained and stored in its own database schema. It can be updated using Oracle Enterprise Manager Fusion Middleware Control.

When you change the configuration of one instance in an Oracle RTD cluster, the other instances pick up the configuration changes after you click the Apply button in Oracle Enterprise Manager Fusion Middleware Control.

15.3.2.2 Protection from Failures and Expected Behaviors

The Oracle RTD topology management layer, running in each cluster member, will detect cluster members that stop updating their heartbeat records in the database. It does not check for failures of individual services within a managed server. So the failure scenarios described in this section are for managed server failures, not individual service failures.

15.3.2.2.1 Decision Server Failure

If a Decision Server fails:

The Oracle RTD sessions associated with the Decision Server are lost, along with their stateful information.

The load balancer will direct requests originally destined to the failed server to another server.

The server receiving these requests will create a new Oracle RTD session, hydrate session level entities from the appropriate data sources, and satisfy the request.

Learning records are written to the database frequently. They are used for statistical purposes. When a Decision Server fails:

All non-persisted learning records are lost.

Oracle RTD does not store any transactional data, such as a specific customer's information or account information, and so on. Therefore, when a large number of learning records have already been learned from and the prediction models have converged, the loss of some data is not material, and it will not significantly affect likelihood calculations and, therefore, the offers returned by an Oracle RTD Informant.

15.3.2.2.2 Cluster Coordinator Failure

If the failed server is the cluster coordinator:

It would stop updating the timestamp in the Oracle RTD database.

Other servers polling the database table would realize that the timestamp has become stale and that there may be a problem with the cluster coordinator.

All active Oracle RTD instances vie to become the new cluster coordinator.

15.3.2.2.3 Learning Service Failure

Learning models are built in memory.

If the active Learning Service fails while building a model, a new Learning Service will be activated, and it will build the model from scratch with no loss of data.

If the node with the active Learning Service fails, the cluster coordinator will activate the Learning Service on one of the remaining cluster nodes (to which a Learning Service has been deployed and enabled). The cluster coordinator does this by sending a command to the Oracle RTD instance via an intra-cluster RPC.

15.3.2.2.4 Decision Center Failure

If a Decision Center fails, a user loses any work in progress that was not saved, for example, rule updates or changes to performance goals that were not saved.

Since multiple Decision Centers run in a cluster, the user will be directed to an active Decision Center.

15.3.2.2.5 Batch Manager Failure

If the node with the active Batch Manager fails, the cluster coordinator will activate a Batch Manager on one of the other remaining nodes (to which a Batch Manager has been deployed and enabled).

If the cluster's Batch Manager singleton fails, the cluster coordinator will notice the death and start another Batch Manager in a different host. All Batch Agents will be notified of the presence of the new Batch Manager, and the Batch Agents will then register themselves with the new Batch Manager.

If the node running a batch job fails:

Only the batch jobs on the failed server will stop processing.

Any batch jobs that were running on the failed node will enter an Interrupted state, and can be manually resumed by issuing a Resume command to the Batch Manager using the Batch Console or other Batch Admin Client.

When an interrupted job is resumed, it will continue from the point where it last synchronized its state with the Batch Manager. When the Batch Manager is asked to resume a job, the job will resume on any available Batch Agent, selected by the Batch Manager.

15.3.3 Oracle RTD High Availability Configuration Steps

This section describes how to set up a two node highly available configuration for Oracle Real-Time Decisions. The architecture targeted for the configuration steps is shown in Figure 15-13.

Note:

Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process.

15.3.3.1 Prerequisite Steps Before Setting up an Oracle RTD High Availability Configuration

This section includes the prerequisites for setting up the Oracle RTD high availability configuration.

15.3.3.1.1 Database Prerequisites

Oracle RTD supports the following database versions:

Oracle Database 10g (10.2.0.4 or later for non-XE database)

Oracle Database 11g (11.1.0.7 or later for non-XE database)

To determine the database version, execute this query:

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.3.3.1.2 Installing and Configuring the Database Repository

This section describes how to install and configure the database repository.

Host Name: Specify the name of the node on which the database resides. For the Oracle RAC database, specify the VIP name or one of the node names as the hostname, for example:

BIDBHOST1-VIP

Port: Specify the listen port number for the database: 1521

Service Name: Specify the service name of the database:

biha.mycompany.com

Username: Specify the name of the user with DBA or SYSDBA privilege: SYS

Password: Enter the password for the SYS user.

Role: Select the database user's role from the list: SYSDBA (required by the SYS user).

Click Next.

In the Select Components screen:

Select Create a new Prefix, and enter a prefix to use for the database schemas, for example, BIHA. You can specify up to six characters as a prefix. Prefixes are used to create logical groupings of multiple repositories in a database. For more information, see Oracle Fusion Middleware Repository Creation Utility User's Guide.

Tip:

Note the name of this schema because the upcoming steps require this information.

This section describes the load balancer prerequisites for deploying an Oracle RTD high availability environment.

Load Balancers

Oracle RTD uses a hardware load balancer when deployed in a high availability configuration with two Oracle HTTP Servers as web tier components.

Virtual Server Names

bi.mycompany.com is a virtual server name that acts as the access point for all HTTP traffic to the runtime BI components, such as Oracle RTD. Traffic to both SSL and non-SSL ports is configured, and typically non-SSL is redirected to SSL. Clients access this service using the address bi.mycompany.com:443. This virtual server is defined on the load balancer.

On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.

Note:

The Oracle Inventory screen does not appear if an Oracle product is already installed on the host. If the Oracle Inventory screen does not open, check that:

The /etc/oraInst.loc file exists.

The file exists, the Inventory directory listed is valid.

The user performing the installation has write permissions for the Inventory directory.

On the Welcome screen, click Next.

On the Select Installation Type screen, select Install and Configure, and click Next.

On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.

On the Specify Installation Location screen, specify:

Oracle Middleware Home: ORACLE_BASE/product/fmw (grayed out)

Oracle Home Directory: Oracle_WT1

Click Next.

On the Configure Components screen:

Select Oracle HTTP Server.

Do not select Associate Selected Components with Weblogic Domain.

Click Next.

On the Specify Component Details screen, enter the following values for WEBHOST1:

If you specify a custom port, select Specify Ports using Configuration File and then use the Browse function to select the file.

Enter the Oracle HTTP Server port, for example: 7777

Click Next.

In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.

On the Installation Summary screen, ensure that the selections are correct. If they are not, click Back and make the necessary fixes. After ensuring that the selections are correct, click Install.

On the Installation Progress screen on UNIX systems, a dialog appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

Click Next.

On the Configuration Progress screen, multiple configuration assistants are launched in succession; this process can be lengthy. Click Next.

On the Installation Complete screen, click Finish to exit.

Repeat the steps for WEBHOST2 and configure your load balancer with a pool containing both the WEBHOST1 and WEBHOST2 addresses.

15.3.3.1.6 Validating Oracle HTTP Server

To verify that Oracle HTTP Server is set up correctly, access the root URL context of the server by using the following URLs in the browser:

http://WEBHOST1:7777/
http://WEBHOST2:7777/

If Oracle HTTP Server is set up correctly, the Oracle FMW Welcome screen appears in the browser.

15.3.3.2 Installing Oracle Fusion Middleware Home

This section describes how to install Oracle Fusion Middleware on all nodes in the application tier that run Oracle WebLogic Server and Oracle Fusion Middleware BI EE. Repeat the procedure (described below for APPHOST1) for installing WebLogic Server and Oracle RTD in APPHOST2. The directory paths for binary files and domains used when installing new nodes must be exactly the same as those used for first node.

Install the following Oracle Fusion Middleware components:

Oracle WebLogic Server

Oracle Fusion Middleware BI EE

15.3.3.2.1 Installing Oracle WebLogic Server

Follow these steps to install Oracle WebLogic Server:

Start the installer for Oracle WebLogic Server from the installation media.

In the Welcome screen, click Next.

In the Choose Middleware Home Directory screen:

Select Create a new Middleware Home.

For the Middleware Home Directory, enter ORACLE_BASE/product/fmw

Note:

ORACLE_BASE is the base directory under which Oracle products are installed. The recommended value is /u01/app/oracle.

Click Next.

In the Register for Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.

In the Choose Install Type screen, select Typical and click Next.

In the Choose Product Installation Directories screen, accept the directory ORACLE_BASE/product/fmw/wlserver_10.3 for WebLogic Server and ORACLE_BASE/product/fmw/coherence_3.6 for Oracle Coherence and click Next.

In the Installation Summary screen, click Next.

The Oracle WebLogic Server software is installed.

In the Installation Complete screen, clear the Run Quickstart check box and click Done.

15.3.3.2.2 Installing Oracle RTD

On the Linux platform, if the /etc/oraInst.loc file exists, check that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory. If the /etc/oraInst.loc file does not exist, you can skip this step.

Start the installer for Oracle Fusion Middleware Business Intelligence 11g from the installation media:

On UNIX:

APPHOST1>./runInstaller

On Windows:

APPHOST1> setup.exe

In the Specify Inventory Directory screen:

Enter HOME/oraInventory, where HOME is the home directory of the user performing the installation (this is the recommended location).

Enter the OS group for the user performing the installation.

Click Next.

Follow the instructions on screen to execute /createCentralnventory.sh as root.

Click OK.

In the Welcome screen, click Next.

In the Select Installation Type screen, select Software Only Install and click Next.

In the Prerequisite Checks screen, verify that all checks complete successfully, and click Next.

In the Specify Installation Location screen, select the previously installed Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name (Oracle_BI1).

Click Next.

In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address and click Next.

In the Summary screen, click Install.

The Oracle Fusion Middleware Business Intelligence 11g software is installed.

In the Installation Progress screen, click Next.

In the Complete screen, click Finish.

15.3.3.3 Enabling VIP1 in APPHOST1 and VIP2 in APPHOST2

The BI domain uses virtual hostnames as the listen addresses for the BI managed servers. You must enable the VIPs, mapping each of these hostnames on the two BI machines (VIP1 on APPHOST1 and VIP2 on APPHOST2), and they must correctly resolve to the virtual hostnames in the network system used by the topology (either by DNS Server or hosts resolution).

15.3.3.4 Creating a Domain with the Administration Server and the First BI_SERVER1 Managed Server

This section describes how to create a domain and the first WebLogic Server BI managed server using the Oracle Business Intelligence Configuration Assistant, Administration Console, and Oracle Enterprise Manager. Ensure that the database where you installed the repository is running. For Oracle RAC databases, all the instances must be running.

Note:

Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.

Run the Configuration Assistant from the Oracle home directory to create a domain containing the Administration Server and the managed server with Oracle RTD:

Change the directory to the location of the Configuration Assistant:

APPHOST1> cd ORACLE_HOME/bin

Start the Configuration Assistant:

On UNIX:

APPHOST1> ./config.sh

On Windows:

APPHOST1> config.bat

In the Welcome screen, click Next.

In the Prerequisite Checks screen, verify that all checks complete successfully, and click Next.

The Create or Scale Out BI System screen opens. Select Create New BI System and specify the following:

In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.

In the Summary screen, click Configure.

In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.

In the Complete screen, click Finish.

15.3.3.5 Creating boot.properties for the Administration Server on APPHOST1

This is an optional step for enabling the Administration Server to start without prompting you for the administrator username and password. Create a boot.properties file for the Administration Server on APPHOST1.

Verify that you can access Enterprise Manager at http://APPHOST1:7001/em.

15.3.3.7 Setting the Listen Address for BI_SERVER1 Managed Server

Perform these steps to set the managed server listen address:

Log into the Administration Console.

In the Change Center, click Lock & Edit.

Expand the Environment node in the Domain Structure window.

Click Servers.

Select bi_server1 in the Names column of the table.

Set the Listen Address to APPHOST1VHN1.

Click Save.

Save and activate the changes.

The changes will not take effect until the BI_SERVER1 managed server is restarted.

15.3.3.8 Disabling Host Name Verification for the BI_SERVER1 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you have not configured the server certificates, you will receive errors when managing the different WebLogic Servers. To avoid these errors, disable hostname verification while setting up and validating the topology, and enable it again once the high availability topology configuration is complete.

To disable hostname verification:

Log into the Administration Console.

In the Change Center, click Lock & Edit.

Expand the Environment node in the Domain Structure window.

Click Servers.

Select bi_server1 in the Names column of the table.

Open the SSL tab.

Expand the Advanced section of the page.

Set Hostname Verification to None.

Click Save.

Save and activate the changes.

The change will not take effect until the BI_SERVER1 managed server is restarted.

15.3.3.9 Starting the System in APPHOST1

This section describes how to start Node Manager on APPHOST1 and how to start and validate the BI_SERVER1 managed server on APPHOST1.

15.3.3.9.1 Starting Node Manager on APPHOST1

Usually, Node Manager is started automatically when config.sh completes. If Node Manager is not running for some reason, start it on APPHOST1 using these commands:

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

15.3.3.9.2 Starting and Validating the BI_SERVER1 Managed Server

To start the BI_SERVER1 managed server and check that it is configured correctly:

Start the bi_server1 managed server using Administration Console, as follows:

Expand the Environment node in the Domain Structure window.

Choose Servers.

Click the Control tab.

Select bi_server1 and then click Start.

Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming", wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors

When BI_SERVER1 starts:

Go to http://APPHOST1:9704/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager for a list of policies and assertion templates available in the data.

Note:

The configuration is incorrect if policies or assertion templates do not appear.

In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle Support and if you do, enter your email address. Click Next.

In the Summary screen, click Configure.

In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.

In the Complete screen, click Finish.

15.3.3.11 Setting the Listen Address for the BI_SERVER2 Managed Server

To set the BI_SERVER2 managed server listen address:

Log into the Administration Console.

In the Change Center, click Lock & Edit.

Expand the Environment node in the Domain Structure window.

Click Servers.

Select bi_server2 in the Names column of the table.

Set the Listen Address to APPHOST2VHN1.

Click Save.

Save and activate the changes.

The changes do not take effect until the BI_SERVER2 managed server restarts.

15.3.3.12 Disabling Host Name Verification for the BI_SERVER2 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. If you have not configured the server certificates, you will receive errors when managing the different WebLogic Servers. To avoid these errors, disable hostname verification while setting up and validating the topology, and enable it again once the high availability topology configuration is complete.

To disable hostname verification:

Log into the Administration Console.

In the Change Center, click Lock & Edit.

Expand the Environment node in the Domain Structure window.

Click Servers.

Select bi_server2 in the Names column of the table.

Open the SSL tab.

Expand the Advanced section of the page.

Set Hostname Verification to None.

Click Save.

Save and activate the changes.

The change will not take effect until the Administration Server is restarted (ensure that Node Manager is up and running):

In the Summary of Servers screen, select the Control tab.

Select AdminServer(admin) (represented as a hyperlink) in the table and then click Shutdown.

Start the Administration Server again from the command line:

APPHOST1> cd ORACLE_COMMON_HOME/bin
APPHOST1> ./wlst.sh

Once in the WLST shell, execute the following command (make sure Node Manager is up and running):

15.3.3.14 Starting the System in APPHOST2

Each server has a transaction log, which stores information about committed transactions coordinated by the server that may not have been completed. WebLogic Server uses the transaction log when recovering from system fails or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to the server.

Note:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

To set the location for the default persistence store for BI_SERVER1:

Log into the Administration Console.

In the Domain Structure window, expand the Environment node and then click the Servers node.

Click BI_SERVER1 (represented as a hyperlink) in the Name column of the table.

The settings page for the BI_SERVER1 server opens with the Configuration tab active.

Click the Services tab.

In the Change Center, click Lock & Edit.

In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:

ORACLE_BASE/admin/domain_name/bi_cluster/tlogs

Click Save and Activate Changes.

Repeat these steps for the BI_SERVER2 server.

Note:

To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both APPHOST1 and APPHOST2 must be able to access this directory. This directory must also exist before you restart the server.

15.3.3.14.3 Starting and Validating the BI_SERVER2 Managed Server

To start the BI_SERVER2 managed server and check that it is configured correctly:

Start the bi_server2 managed server using Administration Console, as follows:

Expand the Environment node in the Domain Structure window.

Choose Servers.

Click the Control tab.

Select bi_server2 and then click Start.

Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming", wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors

When BI_SERVER2 is started, the following URLs become available:

Access http://APPHOST2:9704/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager for a list of policies and assertion templates available in the data.

Note:

The configuration is incorrect if no policies or assertion templates appear.

Access http://APPHOST2:9704/ui to verify the status of the Oracle RTD Decision Center application.

15.3.3.16 Validating Access Through Oracle HTTP Server

Verify that the BI Servers status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming," wait for the server status to change to "Started". If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors.

Verify that you can access these URLs:

http://WEBHOST1:7777/wsm-pm

http://WEBHOST2:7777/wsm-pm

http://WEBHOST1:7777/ui

http://WEBHOST2:7777/ui

Verify that you can access these URLs using your load balancing router address:

http://bi.mycompany.com:80/ui

http://bi.mycompany.com:80/wsm-pm

Follow these instructions to ensure that routing and failover from the HTTP Server to the bi_cluster is working correctly:

While BI_SERVER2 is running, stop BI_SERVER1 from Administration Console.

Access the following URLs and verify the appropriate functionality:

WEBHOST1:7777/wsm-pm

WEBHOST1:7777/ui

Start BI_SERVER1 from the Administration Console.

Stop BI_SERVER2.

Access the URLs in Step 2 above again and verify the appropriate functionality.

15.3.3.18 Scaling Out the Oracle RTD Topology to a New Node (APPHOST3)

When you scale out the Oracle RTD topology, you add a new managed server and set of system components to a new node in your topology (APPHOST3). This section assumes that you already have a high availability topology that includes at least two nodes, with a managed server and a full set of system components on each node.

Before performing the steps in this section, check that you meet these requirements:

There must be existing nodes running Oracle RTD managed servers within the topology.

The new node (APPHOST3) can access the existing home directories for Oracle WebLogic Server and Oracle Business Intelligence.

When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, it is recommended that you keep the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh. To update the Middleware home list to add or remove a WL_HOME, edit the MW_HOME/.home file. See the steps below.

The new server can use a new individual domain directory or, if the other Managed Servers domain directories reside on shared storage, reuse the domain directories on those servers.

To scale out Oracle RTD on APPHOST3:

On APPHOST3, mount the existing Middleware home, which should include the Oracle Business Intelligence installation and (optionally, if the domain directory for Managed Servers in other nodes resides on shared storage) the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.

To attach ORACLE_HOME in shared storage to the local Oracle Inventory, run the following command: