Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence
11g Release 1 (11.1.1)

Part Number E15722-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

9 Scaling Out the Oracle Business Intelligence System

This chapter describes how to scale out the Oracle Business Intelligence system using the Configuration Assistant. It is assumed that an Oracle Business Intelligence ORACLE_HOME (binaries) has already been installed and is available from APPHOST1 and APPHOST2, and that a domain with an Administration Server has been created. This is the domain that you extend in this chapter to support Oracle Business Intelligence components.

Important:

Oracle strongly recommends that you read the Oracle Fusion Middleware Release Notes for any additional installation and deployment considerations before starting the setup process.

This chapter contains the following topics:

9.1 Overview of Scaling Out the Oracle Business Intelligence System

Table 9-1 lists and describes the steps to scale out the Oracle Business Intelligence system and perform post-configuration tasks.

Table 9-1 Steps for Scaling Out the Oracle Business Intelligence System

Step Description More Information

Set Up Shared File Locations

Set up locations for shared files in Oracle BI EE and BI Publisher.

Section 9.2, "Setting Up Shared File Locations"

Scale Out the Oracle Business Intelligence System

Use the Oracle Business Intelligence Configuration Assistant to scale out the Oracle Business Intelligence system, then use Fusion Middleware Control to scale out system components and configure secondary instances for singleton system components.

Section 9.3, "Scaling Out the Oracle Business Intelligence System on APPHOST2"

Configure the bi_server2 Managed Server

Set the listen address and disable host name verification for the bi_server2 Managed Server.

Section 9.4, "Configuring the bi_server2 Managed Server"

Perform Additional Configuration for Oracle Business Intelligence Availability

Perform additional high availability configuration tasks for Oracle BI Scheduler, Oracle RTD, BI Publisher, and Oracle BI Composer.

Section 9.5, "Performing Additional Configuration for Oracle Business Intelligence Availability"

Perform Other Post-Configuration and Verification Tasks

Configure a default persistence store for transaction recovery, start and validate Oracle Business Intelligence on APPHOST2, and configure Node Manager and server migration for the Managed Servers.

Section 9.6, "Other Post-Configuration and Verification Tasks"

Back Up the Installation

Back up the installation to the local disk.

Section 9.7, "Backing Up the Installation"


9.2 Setting Up Shared File Locations

This section describes how to set up locations for shared files in Oracle BI EE and BI Publisher. It contains the following topics:

9.2.1 Setting Up Oracle BI EE Shared Files

This section contains the following topics:

9.2.1.1 Specifying the RPD Publishing Directory

Specify a repository publishing directory for the Oracle BI repository. This location is used for propagating online repository changes in a cluster.

Perform the following steps to specify the publishing directory:

  1. Log in to Fusion Middleware Control.

  2. Expand the Business Intelligence node in the Farm_domain_name window.

  3. Click coreapplication.

  4. Click Deployment, then Repository.

  5. Click Lock and Edit Configuration.

  6. Select Share Repository and specify the RPD Publishing Directory for the Oracle BI Repository.

    In a Windows environment, you must specify a UNC path name.

  7. Click Apply.

  8. Click Activate Changes.

9.2.1.2 Setting the Location of the Shared Oracle BI Presentation Catalog

Each Presentation Services instance loads the Oracle BI Presentation Catalog from the catalog location that is specified in Fusion Middleware Control.

Perform the following steps to set the location of the catalog:

  1. Copy the existing (locally published) catalog to the shared location. An example of a locally published catalog is:

    ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/
    coreapplication_obipsn/catalog/SampleAppLite
    

    You must perform this step before designating the Catalog Location from Fusion Middleware Control.

  2. Log in to Fusion Middleware Control.

  3. Expand the Business Intelligence node in the Farm_domain_name window.

  4. Click coreapplication.

  5. Click Deployment, then click Repository.

  6. Click Lock and Edit Configuration.

  7. Specify the Catalog Location for the shared Oracle BI Presentation Catalog.

    In a Windows environment, you must specify a UNC path name.

  8. Click Apply.

  9. Click Activate Changes.

9.2.1.3 Setting the Location of the Global Cache

The global cache resides on a shared file system (a mounted file system on UNIX or a network shared drive on Windows) and stores purging events, seeding events (often generated by agents), and result sets that are associated with seeding events. Note that each Oracle BI Server still maintains its own local query cache for regular queries.

Perform the following steps to set the location of the cache:

  1. Log in to Fusion Middleware Control.

  2. Expand the Business Intelligence node in the Farm_domain_name window.

  3. Click coreapplication.

  4. Click Capacity Management, then Performance.

  5. Click Lock and Edit Configuration.

  6. In the Global Cache section, specify the shared location for storing purging and seeding cache entries in the Global cache path field. In a Windows environment, you must specify a UNC path name.

  7. Enter a value for Global cache size to specify the maximum size of the global cache (for example, 250 MB).

  8. Click Apply.

  9. Click Activate Changes.

  10. Click Restart to apply recent changes.

  11. Click Restart under Manage System.

  12. Click Yes in the confirmation dialog.

9.2.2 Setting the Location of the Shared BI Publisher Configuration Folder

Perform the following steps to set server configuration options for BI Publisher:

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

  2. On APPHOST1, log in to BI Publisher with Administrator credentials and select the Administration tab.

  3. Under System Maintenance, select Server Configuration.

  4. In the Path field under Configuration Folder, enter the shared location for the Configuration Folder.

  5. In the BI Publisher Repository field under Catalog, enter the shared location for the BI Publisher Repository.

  6. Apply your changes and restart the BI Publisher application, using the following steps:

    1. Log in to the Administration Console.

    2. Click Deployments in the Domain Structure window.

    3. Select bipublisher(11.1.1).

    4. Click Stop and then select When work completes or Force Stop Now.

    5. After the application has stopped, click Start and then select Servicing all requests.

  7. Because BI Publisher reads its configuration from the Administration Server central location rather than from the Managed Server's configuration directory when the Managed Servers are restarted, you must copy the XML configuration file for BI Publisher from the Managed Server to the Administration Server location.

    To do this, on APPHOST1, copy the xmlp-server-config.xml file from:

    ORACLE_BASE/admin/domain_name/mserver/domain_name/config/bipublisher
    

    to:

    ORACLE_BASE/admin/domain_name/aserver/domain_name/config/bipublisher
    

9.3 Scaling Out the Oracle Business Intelligence System on APPHOST2

This section explains how to scale out Oracle Business Intelligence on APPHOST2. Perform the steps in the following sections:

9.3.1 Using the Configuration Assistant to Scale Out the Oracle BI System

Perform the following steps to run the Configuration Assistant from the Oracle home directory to scale out the Oracle BI system:

  1. Ensure that BI_Server1 is up and running.

  2. Change the directory to the location of the Configuration Assistant, as follows:

    APPHOST2> cd ORACLE_HOME/bin
    
  3. Start the Oracle Business Intelligence Configuration Assistant using the following command:

    APPHOST2> ./config.sh
    
  4. In the Welcome screen, click Next.

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

  6. In the Create, Scale Out, or Extend screen, select Scale Out BI System and enter the following:

    • Host Name: ADMINVHN

    • Port: 7001

    • User name: weblogic

    • User Password: your_password

    Click Next.

  7. In the Scale Out BI System Details screen, enter the following:

    • Middleware Home: ORACLE_BASE/product/fmw (dimmed)

    • Oracle Home: ORACLE_BASE/product/fmw/Oracle_BI1 (dimmed)

    • WebLogic Server Home: ORACLE_BASE/product/fmw/wlserver_10.3 (dimmed)

    • Domain Home: ORACLE_BASE/admin/domain_name/mserver/domain_name

    • Applications Home: ORACLE_BASE/admin/domain_name/mserver/applications

    • Instance Home: ORACLE_BASE/admin/instance2

    • Instance Name: instance2 (dimmed)

    Click Next.

  8. In the Configure Ports screen, select one of the following:

    • Auto Port Configuration

    • Specify Ports using Configuration File

    Click Next.

  9. In the Specify Security Updates screen, specify whether you want to receive security updates from Oracle Support and if you do, enter your e-mail address.

    Click Next.

  10. In the Summary screen, click Configure.

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

  12. In the Complete screen, click Finish.

Usually, Node Manager is started automatically when the config.sh process completes. If Node Manager is not running, then perform the following steps to start it on APPHOST2:

  1. Run the setNMProps.sh script, which is located in the ORACLE_COMMON_HOME/common/bin directory, to set the StartScriptEnabled property to "true" before starting Node Manager:

    APPHOST2> cd ORACLE_COMMON_HOME/common/bin
    APPHOST2> ./setNMProps.sh
    

    Note:

    You must use the StartScriptEnabled property to avoid class loading failures.

  2. Start Node Manager:

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

9.3.2 Scaling Out the System Components

Perform the following steps to scale out the system components:

  1. Log in to Fusion Middleware Control.

  2. Expand the Business Intelligence node in the Farm_domain_name window.

  3. Click coreapplication.

  4. Click Capacity Management, then click Scalability.

  5. Click Lock and Edit Configuration.

  6. For the APPHOST2 instance2 Oracle instance, increment the Oracle Business Intelligence components by 1:

    • BI Servers

    • Presentation Services

    • JavaHosts

  7. Click Apply.

  8. Click Activate Changes.

You do not need to restart anything at this point, because you perform a restart after completing the steps in Section 9.3.3.

9.3.3 Configuring Secondary Instances of Singleton System Components

The Oracle BI Cluster Controller, Oracle BI Scheduler, and Essbase Agent are singleton components that operate in active/passive mode. Configure a secondary instance of these components so that they are distributed for high availability.

Perform the following steps to configure secondary instances:

  1. Log in to Fusion Middleware Control at http://biinternal.mycompany.com/em.

  2. Expand the Business Intelligence node in the Farm_BI_domain_name window.

  3. Click coreapplication.

  4. Click Availability, then click Failover.

  5. Click Lock and Edit Configuration to activate the Primary/Secondary Configuration section of the Availability tab.

  6. Specify the Secondary Host/Instance for BI Scheduler, BI Cluster Controller, and Essbase Agent.

  7. In the Essbase Agents section, ensure that the Shared Folder Path is set to ORACLE_BASE/admin/domain_name/cluster_name/Essbase/essbaseserver1.

    Note: You must manually copy the contents of the ORACLE_INSTANCE/Essbase/essbaseserver1 directory to the shared folder path.

  8. Click Apply.

    Under Potential Single Points of Failure, it reports No problems - all components have a backup.

  9. Click Activate Changes.

  10. Click Restart to apply recent changes.

  11. Click Restart under Manage System.

  12. Click Yes in the confirmation dialog.

9.3.4 Using Oracle Essbase Studio Server in a Highly Availability Environment

Oracle Essbase Studio Server does not support high-availability, which can cause issues during failover. For example, suppose that Essbase Studio Server is configured on APPHOST1, which then crashes. The system fails over to APPHOST2, but Essbase Studio Server is not running there. You cannot simply start the server on APPHOST2, because the Essbase Studio catalog database should not be used by two or more Essbase Studio Server instances, either simultaneously or in succession. Oracle strongly recommends that each Essbase Studio Server point to its own unique catalog database.

If you start Essbase Studio Server on a computer that is different from the computer on which you ran the cube deployment, then drill-through reports do not work as expected. To work around this issue, perform the following steps to manually update the Essbase Studio Server information from the Essbase Studio Console:

  1. Go to Tools, then select Update Cube Linkage.

  2. Update the information in the Cube Linkage Essbase Studio Server column to reflect the correct Essbase Studio Server.

See the documentation for Essbase Studio Server at the following location for complete information on starting and using it with a catalog database:

http://docs.oracle.com/cd/E17236_01/nav/portal_3.htm

9.4 Configuring the bi_server2 Managed Server

This section explains how to configure the bi_server2 Managed Server, and contains the following topics:

9.4.1 Setting the Listen Address for the bi_server2 Managed Server

Ensure that you have performed the steps that are described in Section 3.4.2, "Enabling Virtual IPs for the Managed Servers" before setting the bi_server2 listen address.

Perform the following steps to set the listen address for the Managed Server:

  1. Log in to the Oracle WebLogic Server Administration Console.

  2. In the Change Center, click Lock & Edit.

  3. Expand the Environment node in the Domain Structure window.

  4. Click Servers. The Summary of Servers page is displayed.

  5. Select bi_server2 in the Names column of the table. The settings page for bi_server2 is displayed.

  6. Set the Listen Address to APPHOST2VHN1.

  7. Click Save.

  8. Click Activate Changes.

    The changes do not take effect until the bi_server2 Managed Server is restarted.

9.4.2 Disabling Host Name Verification for the bi_server2 Managed Server

This step is required if you have not configured the appropriate certificates to authenticate the different nodes with the Administration Server, as described in Chapter 10, "Setting Up Node Manager for an Enterprise Deployment." If you have not configured the server certificates, then you see errors when managing the different Oracle WebLogic Servers. To avoid these errors, disable host name verification while configuring and validating the topology and enable it again after the EDG topology configuration is complete as described in Chapter 10, "Setting Up Node Manager for an Enterprise Deployment."

Perform the following steps to disable host name verification:

  1. Log in to the Administration Console.

  2. In the Change Center, click Lock & Edit.

  3. Expand the Environment node in the Domain Structure window.

  4. Click Servers. The Summary of Servers page is displayed.

  5. Select bi_server2 in the Names column of the table. The settings page for the server is displayed.

  6. Open the SSL tab.

  7. Expand the Advanced section of the page.

  8. Set host name verification to "None".

  9. Click Save.

  10. Click Activate Changes.

  11. The change does not take effect until the bi_server2 Managed Server is restarted using the following steps (ensure that Node Manager is up and running):

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

    2. Select bi_server2 in the table and then click Shutdown.

    3. Select bi_server2 in the table and then click Start.

  12. Restart the BI System Components on APPHOST2, using the following steps:

    1. Log in to Fusion Middleware Control.

    2. Expand the Business Intelligence node in the Farm_domain_name window.

    3. Click coreapplication.

    4. On the Business Intelligence Overview page, click Restart.

9.5 Performing Additional Configuration for Oracle Business Intelligence Availability

This section describes additional high availability configuration tasks for Oracle BI Scheduler, Oracle RTD, BI Publisher, and Oracle BI Composer. It contains the following topics:

9.5.1 Additional Configuration Tasks for Oracle BI Scheduler

If you use server-side scripts with Oracle BI Scheduler, then 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.

Perform the following steps only if you are using server-side scripts.

Perform the following steps to share Oracle BI Scheduler scripts:

  1. Copy the default Oracle BI Scheduler scripts (for example, ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/common) and custom Oracle BI Scheduler scripts (for example, ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/scheduler) from APPHOST1 to the shared BI Scheduler scripts location.

  2. Update the SchedulerScriptPath and DefaultScriptPath elements of the Oracle BI Scheduler instanceconfig.xml file, as follows:

    • SchedulerScriptPath: Refers to the path where Oracle BI Scheduler-created job scripts are stored. Change this to the path of the shared BI Scheduler scripts location.

    • DefaultScriptPath: Specifies the path where user-created job scripts (not agents) are stored. Change this to the path of the shared BI Scheduler scripts location.

    In a Windows environment, you must specify a UNC path name.

  3. Restart the Oracle BI Scheduler component, as follows:

    opmnctl stopproc ias-component=coreapplication_obisch1
    opmnctl startproc ias-component=coreapplication_obisch1
    

The instanceconfig.xml file for Oracle BI Scheduler is located in ORACLE_INSTANCE/config/OracleBISchedulerComponent/coreapplication_obischn. You must update this file for each Oracle BI Scheduler component in the deployment.

9.5.2 Additional Configuration Tasks for Oracle RTD

This section contains the following topics:

9.5.2.1 Configuring Oracle RTD Clustering Properties

Perform the following steps in Fusion Middleware Control to specify cluster-specific configuration properties for Oracle RTD.

You must perform these steps only for the first node in the deployment. You do not need to set cluster-specific configuration properties for Oracle RTD for subsequent nodes.

  1. Log in to Fusion Middleware Control.

  2. Expand the Application Deployments node in the Farm_domain_name window.

  3. Click OracleRTD(11.1.1)(bi_cluster).

  4. Click any node under it. For example, OracleRTD(11.1.1)(bi_server1).

  5. In the right pane, click Application Deployment, and then select System MBean Browser.

  6. In the System MBean Browser pane, expand Application Defined MBeans.

  7. For any one of the servers under OracleRTD, navigate to the SDClusterPropertyManager -> Misc MBean and set the DecisionServiceAddress attribute to http://biinternal.mycompany.com. Other servers automatically get updated with the value that you set.

  8. Click Apply.

9.5.2.2 Adding System Properties to the Server Start Tab

After scaling out Oracle RTD, perform the following steps to add three system properties to the Server Start tab of each Managed Server:

  1. Log in to the Administration Console.

  2. In the Change Center, click Lock & Edit.

  3. Expand the Environment node in the Domain Structure window.

  4. Click Servers. The Summary of Servers page is displayed.

  5. Select bi_server<1,2> in the table. The settings page for the server is displayed.

  6. Click the Server Start tab.

  7. Add the following properties in the Arguments box:

    -Drtd.clusterRegistryJobIntervalMs=12000
    -Drtd.clusterDepartureThresholdMs=50000
    -Drtd.clusterDepartureThreshold2Ms=50000
    
  8. Click Save.

  9. Click Activate Changes.

  10. The change does not take effect until the bi_server<1,2> Managed Servers are restarted (ensure that Node Manager is up and running):

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

    2. Select bi_server<1,2> in the table and then click Shutdown.

    3. Restart bi_server<1,2>.

  11. Restart the BI System Components:

    cd /u02/local/oracle/config/BIInstancen/bin
    ./opmnctl stopall
    ./opmnctl startall
    

Performing this task enables an instance of Oracle RTD to be migrated successfully from one host to another in the event of a failure of a Managed Server.

Even after these changes, if the server migration finishes in less than 50 seconds, then the Oracle RTD batch framework remains in an inconsistent state.

If the enterprise has deployed any RTD Inline Services that host Batch Job implementations, and if after a server migration the batch console command, "batch-names", or its brief name, "bn", shows no registered batch jobs, then you must stop and restart the Oracle RTD Batch Manager service. Perform the following steps to stop and restart the service:

  1. In Fusion Middleware Control, expand the WebLogic Domain node in the left pane. Then, right-click bifoundation_domain and select System MBean Browser.

  2. Locate the SDPropertyManager > Misc MBean, under Application Defined MBeans > OracleRTD > Server:bi_servern.

    Ensure that you select the Misc MBean that corresponds to the local node where you are making the change. For example, if you are connecting to APPHOST1, then ensure that you update the attribute associated with bi_server1.

  3. Set the BatchManagerEnabled attribute to false and click Apply.

  4. Set the BatchManagerEnabled attribute back to true and click Apply. Performing this task causes the Batch Manager to stop and be restarted.

    When the Batch Manager restarts, it runs on either the same server as before, or on a different server.

  5. After restarting Batch Manager, note that the corresponding MBean does not always immediately get refreshed on the server where Batch Manager is restarted, so this is not a concern. Instead, verify that Batch Manager is now operational by using the Batch Console tool, as in the follow steps:

    1. Locate the zip file for the Oracle RTD client tools in the following location:

      ORACLE_HOME/clients/rtd/rtd_client_11.1.1.zip
      
    2. Because most Oracle RTD client tools do not run on UNIX, unzip this file in a location on a Windows computer (referred to here as RTD_HOME). Then, locate the batch console jar file in:

      RTD_HOME/client/Batch/batch-console.jar
      
    3. Change to this directory and execute the jar, passing to it the URL and port of either the Managed Server, or of the cluster proxy:

      java -jar batch-console.jar -url http://SERVER:PORT
      
    4. When prompted, enter the user name and password of a user who is a member of the Administrator role, BI_Adminstrator role, or some other role authorized to administer Oracle RTD batch jobs.

    5. When prompted for a command, enter bn:

      Checking server connection...
      command: bn
          CrossSellSelectOffers
      command:quit
      

      If Batch Manager has successfully restarted, then the "bn" command lists the names of all batch implementations hosted by all deployed RTD Inline Services.

      The commonly deployed example, CrossSell, hosts a batch implementation named CrossSellSelectOffers, shown in the preceding example.

9.5.3 Additional Configuration Tasks for BI Publisher

This section contains the following topics:

9.5.3.1 Setting Scheduler Configuration Options

Perform the following steps to set Scheduler configuration options:

  1. On APPHOST1, log in to BI Publisher with Administrator credentials and select the Administration tab.

  2. Under System Maintenance, select Scheduler Configuration.

  3. Select Quartz Clustering under the Scheduler Selection.

  4. Click Apply.

9.5.3.2 Configuring Integration with Oracle BI Presentation Services

Perform the following steps to configure BI Publisher integration with Oracle BI Presentation Services:

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

  2. Under Integration, select Oracle BI Presentation Services.

  3. Verify and update the following:

    • Server Protocol: HTTP

    • Server: biinternal.mycompany.com

    • Port: 80

    • URL Suffix: analytics-ws/saw.dll

  4. Click Apply.

  5. Restart the BI Publisher application.

9.5.3.3 Setting the Oracle BI EE Data Source

The Oracle BI EE Data Source must point to the clustered Oracle BI Servers through the Cluster Controllers. Perform this task in BI Publisher.

Perform the following steps to set the Oracle BI EE data source in BI Publisher:

  1. Log in to BI Publisher with Administrator credentials and select the Administration tab.

  2. Under Data Sources, select JDBC Connection.

  3. Update the Oracle BI EE data source setting by changing the Connection String parameter to the following:

    jdbc:oraclebi://primary_cluster_controller_host:primary_cluster_controller_
    port/PrimaryCCS=primary_cluster_controller_host;PrimaryCCSPort=primary_cluster_
    controller_port;SecondaryCCS=secondary_cluster_controller_host;
    SecondaryCCSPort=secondary_cluster_controller_port;
    

    For example:

    jdbc:oraclebi://APPHOST1:9706/PrimaryCCS=APPHOST1;PrimaryCCSPort=9706;
    SecondaryCCS=APPHOST2;SecondaryCCSPort=9706;
    
  4. Select Use System User.

    If you do not want to use the system user for the connection, then 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 Presentation Catalog" in Oracle Fusion Middleware Developer's Guide for Oracle Business Intelligence Enterprise Edition.

  5. Click Test Connection. You see a "Connection established successfully" message.

  6. Click Apply.

9.5.3.4 Configuring JMS for BI Publisher

You must configure the location for all persistence stores to a directory that is visible from both nodes. Change all persistent stores to use this shared base directory. Perform the following steps to configure JMS:

  1. Log into the Administration Console.

  2. In the Domain Structure window, expand the Services node and click the Persistent Stores node. The Summary of Persistent Stores page is displayed.

  3. In the Change Center, click Lock & Edit.

  4. Click New and Create File Store.

  5. 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
    
  6. Click OK and Activate Changes.

  7. In the Domain Structure window, expand the Services node and click the Messaging > JMS Servers node. The Summary of JMS Servers page is displayed.

  8. In the Change Center, click Lock & Edit.

  9. Click New.

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

  11. Select BI_SERVER2 as the target.

  12. Click Finish and Activate Changes.

  13. In the Domain Structure window, expand the Services node and click the Messaging > JMS Modules node. The JMS Modules page is displayed.

  14. In the Change Center, click Lock & Edit.

  15. Click BipJmsResource and click the Subdeployments tab.

  16. Select BipJmsSubDeployment under Subdeployments.

  17. Add the new BI Publisher JMS Server, BipJmsServer2, as an additional target for the subdeployment.

  18. Click Save and Activate Changes.

To validate the JMS configuration performed for BI Publisher, perform the steps in Section 9.5.3.5, "Updating the BI Publisher Scheduler Configuration."

9.5.3.5 Updating the BI Publisher Scheduler Configuration

Follow the steps in this section to update the JMS Shared Temp Directory for the BI Publisher Scheduler. You need to perform the steps in this section on only one of the APPHOSTS (either APPHOST1 or APPHOST2).

Perform the following steps to update the BI Publisher Scheduler configuration:

  1. Log in to BI Publisher at the one of the following URLs:

    • http://APPHOST1VHN1:9704/xmlpserver

    • http://APPHOST2VHN1:9704/xmlpserver

  2. Click the Administration link.

  3. Click Scheduler Configuration under System Maintenance. The Scheduler Configuration screen is displayed.

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

  5. Click Test JMS.

    You see a confirmation message that JMS tested successfully.

    Note:

    If you do not see a confirmation message for a successful test, then verify that the JNDI URL is set to the following:

    cluster:t3://bi_cluster

  6. Click Apply.

  7. Check the Scheduler status from the Scheduler Diagnostics tab.

9.5.4 Additional Configuration Tasks for Oracle BI Composer

Perform the following steps for Oracle BI Composer to change the port value to the load balancer port:

  1. Log in to Fusion Middleware Control Console.

  2. Expand Application Deployments in the left-hand navigation pane.

  3. Under bicomposer(11.1.1) (bi_cluster), right-click bicomposer(11.1.1) (bi_server1) and select System MBean Browser.

  4. Go to the following MBean:

    Application Defined MBeans > oracle.adf.share.connections > Server: bi_server1 > Application: bicomposer > ADFConnections > BISoapConnection > bi-default

  5. Set the Protocol attribute to http.

  6. Set the Port attribute to the load balancer HTTP port (80).

  7. Set the Host attribute to the internal load balancer URL as follows:

    biinternal.mycompany.com

  8. Click Apply.

  9. Go to the ADFConnections MBean and select the Operations tab.

  10. Click save and Invoke.

  11. Restart the BI Composer application using Fusion Middleware Control or the Administration Console.

9.6 Other Post-Configuration and Verification Tasks

After performing the high availability configuration tasks for Oracle BI Scheduler, Oracle RTD, BI Publisher, and Oracle BI Composer, follow these additional instructions for post-configuration and verification.

This section contains the following topics:

9.6.1 Configuring a Default Persistence Store for Transaction Recovery

Each server has a transaction log that stores information about committed transactions that are coordinated by the server that might not have been completed. The WebLogic Server uses this transaction log for recovery from system crashes 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 that is accessible to a server and its backup servers.

Note:

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

Perform the following steps for each Managed Server to set the location for the default persistence store:

  1. Log in to the Administration Console.

  2. In the Change Center, click Lock & Edit.

  3. In the Domain Structure window, expand the Environment node and click the Servers node. The Summary of Servers page is displayed.

  4. Click the name of the server (represented as a hyperlink) in the Names column of the table. The Settings page for the selected server is displayed, and defaults to the Configuration tab.

  5. Open the Services tab.

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

    ORACLE_BASE/admin/domain_name/bi_cluster_name/tlogs

    Use the same path for each Managed Server. When the Managed Servers are restarted, subdirectories are created for each one.

  7. Click Save and Activate Changes.

    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 bi_server1 and bi_server2 must be able to access this directory.

9.6.2 Starting and Validating Oracle Business Intelligence on APPHOST2

This section contains the following topics:

9.6.2.1 Starting the bi_server2 Managed Server

Perform the following steps to start the bi_server2 Managed Server:

  1. Start the bi_server2 Managed Server using the Administration Console, as in the following steps:

    1. Expand the Environment node in the Domain Structure window.

    2. Click Servers. The Summary of Servers page is displayed.

    3. Click the Control tab.

    4. Select bi_server2 and then click Start.

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

9.6.2.2 Starting the Oracle Business Intelligence System Components

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

Perform the following steps to start the Oracle Business Intelligence system components using the opmnctl command-line tool:

  1. Go to the directory that contains the OPMN command-line tool, located in ORACLE_INSTANCE/bin.

  2. Run the opmnctl command to start the Oracle Business Intelligence system components:

    • opmnctl startall

      Starts OPMN and all Oracle Business Intelligence system components.

    • opmnctl start

      Starts OPMN only.

    • opmnctl startproc ias-component=component_name

      Starts a particular system component. For example, where coreapplication_obips2 is the Presentation Services component:

      opmnctl startproc ias-component=coreapplication_obips2

  3. Check the status of the Oracle Business Intelligence system components:

    opmnctl status

9.6.2.3 Validating Oracle Business Intelligence URLs

Access the following URLs:

  • Access http://APPHOST2VHN1:9704/analytics to verify the status of bi_server1.

  • 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 is displayed.

    Note: The configuration is incorrect if no policies or assertion templates are displayed.

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

  • Access http://APPHOST2VHN1:9704/ui to verify the status of the Oracle RTD application.

  • Access http://APPHOST2VHN1:9704/mapviewer to verify the status of Oracle MapViewer.

  • Access http://APPHOST2VHN1:9704/aps/Essbase to verify the status of the Oracle Essbase application.

  • Access http://APPHOST2VHN1:9704/aps/SmartView to verify the status of the Smart View application.

  • Access http://APPHOST2VHN1:9704/workspace to verify the status of the Workspace application.

  • Access http://APPHOST2VHN1:9704/hr to verify the status of the Financial Reporting application.

  • Access http://APPHOST2VHN1:9704/calcmgr/index.htm to verify the status of the Calculation Manager application.

9.6.2.4 Validating Access Through the Load Balancer

Verify URLs to ensure that the appropriate routing and failover is working from Oracle HTTP Server to bi_cluster. Perform the following steps to verify the URLs:

  1. While bi_server2 is running, stop bi_server1 using the Administration Console.

  2. Access the following URLs to verify that routing and failover is functioning properly:

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

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

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

  3. Start bi_server1 from the Administration Console.

  4. Stop bi_server2 from the Administration Console.

  5. Access the following URLs to verify that routing and failover is functioning properly:

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

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

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

  6. Start bi_server2 from the Administration Console.

9.6.2.5 Validating Essbase Clustering

Perform the following steps to validate Essbase clustering:

  1. Check the APS (Hyperion Provider Services) test URL:

    https://bi.mycompany.com/aps/Essbase?ClusterName=EssbaseCluster-1

  2. Run the following command on APPHOST1:

    ORACLE_BASE/admin/instance1/bin/opmnctl stopproc
    ias-component=essbaseserver1
    
  3. Ensure that Essbase starts on APPHOST2:

    ORACLE_BASE/admin/instance2/bin/opmnctl status
    

    The status is init, then Alive.

  4. Check the APS test URL again:

    https://bi.mycompany.com/aps/Essbase?ClusterName=EssbaseCluster-1

9.6.3 Configuring Node Manager for the Managed Servers

Oracle recommends using host name verification for the communication between Node Manager and the servers in the domain. This verification requires the use of certificates for the different addresses that communicate with the Administration Server and other servers. See Chapter 10, "Setting Up Node Manager for an Enterprise Deployment" for further details. The procedures in that chapter must be performed twice using the information that is provided in Table 9-2.

Table 9-2 Details for Host Name Verification for Node Manager and Servers

Run Host Name (HOST) Server Name (WLS_SERVER)

Run1:

APPHOST1

bi_server1

Run2:

APPHOST2

bi_server2


9.6.4 Configuring Server Migration for the Managed Servers

Server Migration is required for proper failover of the BI Publisher components in the event of failure in any of the APPHOST1 and APPHOST2 nodes. See Chapter 11, "Configuring Server Migration for an Enterprise Deployment" for further details.

9.7 Backing Up the Installation

After you have verified that the scaled-out domain is working, back up the installation. This is a quick backup for the express purpose of immediate restore in case of problems in upcoming steps. The backup destination is the local disk. This backup can be discarded after the enterprise deployment setup is complete. At that point, the regular deployment-specific backup and recovery process can be initiated. The Oracle Fusion Middleware Administrator's Guide provides further details. For information on the Oracle HTTP Server data that must be backed up and restored, see the "Backup and Recovery Recommendations for Oracle HTTP Server" section in that guide. For information on how to recover components, see the "Recovering Components" and "Recovering After Loss of Component Host" sections in the guide. For recommendations that are specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" section in the guide. Also refer to Oracle Database Backup and Recovery User's Guide for information on database backup.

Perform the following steps to back up the installation at this point:

  1. Back up the web tier, using the following steps:

    1. Shut down the instance using opmnctl:

      WEBHOSTn> ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
      
    2. Back up the Middleware home on the web tier using the following command (as root):

      WEBHOSTn> tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
      
    3. Back up the Oracle instance on the web tier using the following command:

      WEBHOSTn> tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE
      

      Repeat this step for WEBHOST2.

    4. Start the instance using opmnctl:

      WEBHOSTn> cd ORACLE_BASE/admin/instance_name/bin
      WEBHOSTn> opmnctl startall
      
  2. Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or operating system tools such as tar for cold backups if possible.

  3. Back up the BI Instance in the application tier, using the following steps:

    1. Shut down the instance using opmnctl:

      APPHOSTn> ORACLE_INSTANCE/bin/opmnctl stopall
      
    2. Back up the Middleware home on the application tier using the following command:

      APPHOSTn> tar -cvpf BACKUP_LOCATION/bi.tar MW_HOME
      
    3. Back up the Oracle instance on the application tier using the following command:

      APPHOSTn> tar -cvpf BACKUP_LOCATION/bi_instance_name.tar ORACLE_INSTANCE
      
    4. Start the instance using opmnctl:

      APPHOSTn> ORACLE_INSTANCE/bin/opmnctl startall
      
  4. Back up the Administration Server and Managed Server domain directories to save the domain configuration. The configuration files all exist in the ORACLE_BASE/admin/domain_name directory. Run the following command to create the backup:

    APPHOSTn> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
    

    Note: Create backups on all computers in the application tier by following the steps that are described in this section.