Release 3.3.1 for Windows
Part No. A96684-01
 Contents |
 Index |
|
Oracle® Fail Safe Concepts and Administration Guide
Release 3.3.1 for Windows Part No. A96684-01 |
|
Oracle Fail Safe provides high availability for Oracle Reports applications, including both client/server and Web-based Oracle Reports applications. (To make your Oracle Reports available on the Web, you must also create and add an Oracle HTTP Server to a group.)
Using Oracle Fail Safe to configure Oracle Reports provides the following high-availability benefits:
Minimizes downtime for your Oracle Reports applications
Protects jobs that are scheduled for Oracle Reports Server
Eliminates the master Oracle Reports Server as a point of failure
The topics discussed in this chapter include the following:
Oracle Fail Safe helps you to configure new and existing Oracle Reports Servers for high availability, using any of the following implementations:
Master/slave implementations (which can be set up using either of the preceding two implementations)
The following sections describe these implementations in more detail.
The term tier refers to the logical location of the components that make up the Oracle Reports Server architecture. Each of the tiers, however, can reside on the same or different cluster nodes, the same or different clusters from one another, or on a system that is not clustered. Using Oracle Fail Safe with components installed on cluster nodes, you can make the Oracle HTTP Servers, the Oracle Reports Servers, and the Oracle databases highly available, thus creating a highly available Web-based business solution. This is the ideal solution. However, you are not required to make all components highly available. You might decide to configure for high availability only the component or components that are most critical to your business needs.
You can use the Oracle Reports Server in conjunction with the Reports Web Cartridge, Reports Web CGI, or Reports Servlet to run reports from a Web browser. (See the Oracle Reports documentation for details on how to set up the Reports Web Cartridge, Reports Web CGI, and the Reports Servlet.)
In the Web-based implementation, the Oracle Reports Server architecture consists of three or four tiers, as follows:
Client tier
Includes Web browsers
Application tier
Includes both the Oracle HTTP Server and the Oracle Reports Server as a single tier, or can be separated into two tiers: the Oracle HTTP Server tier and the Oracle Reports Server tier
Database tier
Includes the Oracle database or databases that the Oracle Reports Server accesses
Figure 10-1 illustrates a highly available three-tier configuration for the Oracle Reports Server in a Web environment. In this configuration, the Oracle Reports Server tier and the Oracle HTTP Server tier are combined to form the application tier. For additional configurations, see the Oracle Reports documentation.
Figure 10-1 Three-Tiered Architecture for Oracle Reports Web Implementation
In the client/server implementation, the Oracle Reports Server architecture consists of three tiers, as follows:
Client tier
Includes client applications
Application tier
Includes Oracle Reports Servers
Database tier
Includes the Oracle databases that the Oracle Reports Server accesses
Figure 10-2 illustrates a common configuration for a highly available Oracle Reports Server in a client/server environment.
Figure 10-2 Three-Tiered Architecture for Oracle Reports Client/Server Implementation
The master/slave implementation allows you to configure the Oracle Reports Server to improve performance and load balancing.
|
Note: The Oracle Fail Safe documentation uses the term master/slave implementation to refer to what the Oracle Reports documentation calls the "cluster configuration." |
In this configuration, you use several Oracle Reports Servers, one of which you designate as the master; the rest you designate as slaves. Users send report requests to the master Oracle Reports Server. The master Oracle Reports Server then redirects the report requests to the slave servers, using a round-robin algorithm. If one of the slaves is unavailable, the master Oracle Reports Server does not send it requests.
In this way, Oracle Reports provides highly available reports without the use of Oracle Fail Safe. However, the master Oracle Reports Server can still be a point of failure. If it becomes unavailable, the entire master/slave configuration will become unavailable. By using Oracle Fail Safe to configure the master Oracle Reports Server for high availability, you eliminate this point of failure in the configuration.
See Section 10.5 for information on post-configuration requirements for a master/slave implementation in an Oracle Fail Safe environment.
You configure Oracle Reports Servers for high availability using Oracle Fail Safe Manager. Before you can view standalone Oracle Reports Servers in the Oracle Fail Safe Manager interface, they must first be discovered. Oracle Services for MSCS discovers Oracle Reports Servers by reviewing the list in the Windows service manager, finding Oracle Reports Server entries, and determining which have not already been configured for high availability. Oracle Fail Safe displays the newly discovered services in the Oracle Fail Safe Manager tree view under the Standalone Resources folder.
To configure an Oracle Reports Server for high availability, you add it to a group that currently contains at least one virtual address. Oracle Fail Safe adds all other resources upon which the Oracle Reports Server depends. Typically, the group includes the following resources:
The Oracle Reports Server
One or more cluster disks where the cache directory, the source directory, and the scheduled jobs are located
One or more virtual addresses
If the Oracle Reports Server will be a Web implementation, you can make the entire application highly available by also adding an Oracle HTTP Server to a group. The group to which you add the Oracle HTTP Server need not be the same group to which you added the Oracle Reports Server.
If the Oracle Reports Server will be a master server in a master/slave configuration, you configure it for high availability using the same method as for any Oracle Reports Server: by adding it to a group. Section 10.5 explains the post-configuration steps you need to follow.
Before you add an Oracle Reports Server to a group, note the following:
The Oracle Reports Server executable files must be installed on a private disk on each cluster node configured to run Oracle Reports Server.
All other necessary Oracle product executable files must be installed on a private disk on each cluster node configured to run Oracle Reports Server.
All Oracle Reports Server data files and output files must be located on cluster disks so that they can be accessed regardless of which cluster node is hosting the Oracle Reports Server.
The group must contain at least one virtual address.
Oracle Fail Safe automates the steps required to configure an Oracle Reports Server for high availability by providing a wizard. You can add an existing Oracle Reports Server to a group, or you can create and add a new Oracle Reports Server.
Table 10-1 provides a quick reference to the tasks needed to configure an Oracle Reports Server for high availability. For step-by-step instructions for a task, refer to the online help and tutorial. From the Oracle Fail Safe Manager menu bar, choose Help, then "Search for Help on" or Help, then Tutorial.
Table 10-1 Steps for Configuring an Oracle Reports Server
| Step | Procedure | Comments |
|---|---|---|
| 1 | Ensure that the Oracle Reports software is installed on private disks on each node in the cluster where you want it to be possible to run. | See the Oracle Reports documentation for installation information. |
| 2 | Copy the Oracle Reports definition (.rdf or .rep) files to the source directory location. | The definition files must be located on the cluster disks on the shared storage interconnect. |
| 3 | Test the Oracle Reports application on a standalone node. | Before adding an Oracle Reports Server to a group, test the Oracle Reports application on a single node in standalone mode. For example, you might run the report to the desired format and destination. |
| 4 | Invoke Oracle Fail Safe Manager. | From the Windows Start menu, choose Oracle - <Oracle_Home>, then Oracle Fail Safe Manager. |
| 5 | Verify the cluster. | Choose Troubleshooting, then Verify Cluster to run a procedure that validates the cluster hardware and software configurations. |
| 6 | Create a group and add one or more virtual addresses. | Choose Groups, then Create to run the Create Group Wizard. The wizard helps you to set up failover and failback policies and automatically opens the Add Resource to Group Wizard to allow you to add a virtual address to the group. (Choose Resources, then Add to Group to add additional virtual addresses to the group.) |
| 7 | Add the Oracle Reports Server to the group. | Choose Resources, then Add to Group in Oracle Fail Safe Manager to run the Add Resource to Group Wizard. The wizard helps you select the Oracle Reports Server, specify its port number, indicate the location of the source files, select the database used by the Reports application, and so on. |
| 8 | Verify the group. | Choose Troubleshooting, then Verify Group to check for and fix any problems with the group, virtual addresses, resources, or the failover configuration. |
| 9 | Modify the tnsnames.ora file on each client system. | Configure clients (modify the tnsnames.ora file on each client system) to recognize the virtual server (refer to Section 10.4.1). If you are using a master/slave implementation, modify the tnsnames.ora file on the master and slave systems (refer to Section 10.5). |
| 10 | Configure the Oracle HTTP Server for failover. | Create and add an Oracle HTTP Server to a group to make your Oracle Reports application highly available on the Web. See Chapter 11 for information about creating and adding an Oracle HTTP Server to a group. |
Oracle Fail Safe Manager provides the Add Resource to Group Wizard to assist you in configuring an Oracle Reports Server for high availability. When you use the Add Resource to Group Wizard, you need the following data:
Possible owner nodes for the Oracle Reports Server, if the cluster consists of more than two nodes, or if one node is not available in a two-node cluster
Virtual address to be associated with the Oracle Reports Server, if the group contains more than one virtual address
Name of the Oracle Reports Server and the port on which it will run
Location of the Oracle Reports Server cache directory, source directory, and jobs directory
The database or databases that the Oracle Reports Server accesses
The account under which the Oracle Reports Server will run
The following sections describe these requirements in detail.
If you are adding an Oracle Reports Server to a group and the cluster consists of more than two nodes, you are asked to specify which nodes should be possible owners for the Oracle Reports Server by specifying a list of selected nodes, as shown in Figure 10-3. To specify that a particular node should not be a possible owner for the Oracle Reports Server, select the node from the Selected Nodes list and click the left arrow.
Section 2.6.6 describes in detail the concept of the possible owner nodes list.
Figure 10-3 Choose Nodes Wizard Page When All Nodes Are Available
If you are adding an Oracle Reports Server to a group and the cluster consists of two or more nodes, but one or more nodes are unavailable, you are also asked to specify which nodes should be possible owners for the Oracle Reports Server. In this case, the wizard page displays which nodes are unavailable and why, as shown in Figure 10-4.
Figure 10-4 Choose Nodes Wizard Page When Any Node Is Unavailable
A group must contain at least one virtual address before you add an Oracle Reports Server to it. If the group to which you are adding an Oracle Reports Server contains more than one virtual address, you are asked to select which one you would like to associate with the Oracle Reports Server, as shown in Figure 10-5. If the Oracle Reports application is accessed from a client application, the virtual address will be the host that applications specify to connect to the Oracle Reports Server. If the Oracle Reports application is accessed from a highly available Web site, the Reports Server name and the virtual address of the Oracle HTTP Server will be the URL users specify to connect to it. For instance, the following example shows a URL you might specify to access a report on the Web when both the Oracle Reports Server and an Oracle HTTP Server have been made highly available:
http://ntclu4-6:4000/web_cgi/rwcgi60.exe?server=Reports_Tutorial+report=sample+userid=internal/internal@Tutorial_DB.world+destype=cache+desformat=HTML
In this example:
ntclu4-6:4000 is the virtual address and port of the Oracle HTTP Server.
web_cgi is a virtual directory that points to the physical directory containing the rwcgi60.exe executable file.
Reports_Tutorial is the name of the Oracle Reports Server (as specified in tnsnames.ora).
Tutorial_DB.world is the database that the Oracle Reports Server accesses.
Figure 10-5 Oracle Reports Virtual Address Wizard Page
The Oracle Reports Server identity consists of the Oracle Reports Server name and the port on which you want the Oracle Reports Server to run, as shown in Figure 10-6. Two or more Oracle Reports Servers running on the same cluster cannot use the same combination of port number and virtual address. If two Oracle Reports Servers use the same virtual address, they must use different port numbers.
Figure 10-6 Oracle Reports Server Identity Wizard Page
These directories specify where the definition files for the reports application are located, where the output should be written, and where the scheduling information for jobs is located. For an existing Reports Server, these values are filled in on the Reports Disks page of the wizard. For a new Reports Server, Oracle Fail Safe uses the values you specify to create the Oracle Reports Server configuration file (<reports-server-name>.ora, where <reports-server-name> is the name of the Oracle Reports Server. The Oracle Reports Server configuration file is always in <Oracle_Home>\Report60\Server\<reports-server-name>.ora.
The directories you need to specify for a new Reports Server, as shown in Figure 10-7, are as follows:
Specifies the directory where you want the Oracle Reports Server output files to be written. This directory specification can be a cluster disk and directory, or a file share.
Specifies the directory where the .rdf or .rep files are located. The directory specification can be a cluster disk and directory, or a file share.
Specifies the directory containing the .dat file that holds the schedule for running Oracle Reports Server tasks. The directory specification must be a cluster disk and directory. Even if you do not plan to schedule jobs, you must specify this directory.
The <reports-server-name>.ora file parameters that are set when you create and add a new Oracle Reports Server to a group are as follows:
Cache directory = cachedir parameter
Source directory = sourcedir parameter
The persistfile parameter indicates where the <reports-server-name>.dat file is located. The <reports-server-name>.dat file contains the schedule for running Oracle Reports Server jobs. The persistfile parameter must point to a cluster disk so that the Oracle Reports Server can find the schedule regardless of the node on which it is currently running.
Figure 10-7 Oracle Reports Server Disks Wizard Page
The Oracle Reports Server needs to know which database or databases to use for displaying and updating data through the reports application it serves, as shown in Figure 10-8. Oracle Fail Safe updates the tnsnames.ora file with the database information on all cluster nodes that are possible owners of the Oracle Reports Server, so that connection information is available to the Oracle Reports Server regardless of the node on which the Oracle Reports Server or the database is running.
You can specify a standalone database or one that has been configured for high availability. However, to ensure high availability across your business solution, you should add the database or databases accessed by a fail-safe Oracle Reports Server to a group. You need not add the database to the same group as the Oracle Reports Server.
Figure 10-8 Oracle Reports Server Databases Wizard Page
For the Oracle Reports Server to run properly, it must have access to one or more printers.Foot 1 Therefore, you must specify a user account that has access to a printer. Even if the report is not being sent to a printer, the Oracle Reports Server must be run from an account that has access to a printer. Figure 10-9 shows the wizard page on which you specify this information.
When the Oracle Reports Server is run as a service, make sure that the user account has the Password Never Expires option selected in the Windows User Manager and that it has membership in the appropriate groups to run the Oracle Reports Server and access the reports files. Also make sure that the default printer is set and that the user has print permission on that printer.
Figure 10-9 Oracle Reports Server Account Wizard Page
The following sections describe how clients connect to Oracle Reports Servers that have been configured for high availability using Oracle Fail Safe. You do not need to make changes to existing Oracle Reports applications for the applications to work with Oracle Reports Servers that have been configured with Oracle Fail Safe.
When a cluster node is shut down or fails, the group that contains the Oracle Reports Server fails over to another cluster node automatically, and users can resume access to the Oracle Report within seconds. To restart a failed Oracle Reports application on the Web, the user reloads the URL in the Web browser. Although it is the Oracle Reports Server component that is made highly available, it appears to the user that the entire application has been made highly available.
To display a highly available report on the Web:
Configure a Web listener to listen on a virtual address. Users specify the virtual address of the Web listener and the static .html file in a Web browser to access the report. For example, depending on how you have set up the Oracle HTTP Server, a user might enter the following URL:
http://ntclu4-5/reports.html:801
In this URL, ntclu4-5 is the virtual address of the Web listener, reports.html is the static HTML file for the Oracle Reports application, and 801 is the port number that the Web listener is listening on. Edit the .html file of your Web site home page to reference the virtual address of the group to which you added the Oracle Reports Server and the Oracle HTTP Server, and the port number of the Oracle HTTP Server. The HREF format is as follows:
<A HREF="http://virtual_address:port_number/">
If you use a key mapping file, make sure that the REPORTS60_CGIMAP environment variable is defined on all cluster nodes (that are possible owners of the Oracle HTTP Server) to specify where the key mapping file can be found.
Oracle Fail Safe automatically updates the tnsnames.ora files on the cluster nodes that are possible owners for the Oracle Reports Server and on the system where you are running the Add Resource to Group Wizard to add an Oracle Reports Server to a group.
However, you must edit the tnsnames.ora files on the client systems so that clients can access the Oracle Reports Server at the virtual address, rather than the physical address of the node.
|
Note: Client systems accessing Oracle Reports Servers with a Web browser do not need to update the tnsnames.ora file. |
Follow these steps to update client systems that need to access Oracle Reports Servers in an Oracle Fail Safe environment:
Determine the virtual address used by the Oracle Reports Server using either of the following methods:
In the tree view, select the Oracle Reports Server resource and click the Dependencies tab. Write down the virtual address that is listed.
Find the Oracle Reports Server entry in the tnsnames.ora file on one of the cluster nodes. (Oracle Fail Safe automatically updates the tnsnames.ora files on the cluster nodes that are possible owners of the Oracle Reports Server.)
Edit the tnsnames.ora file on the client systems that need to access the Oracle Reports Server. The entry in the tnsnames.ora file for an Oracle Reports Server will be similar to the following:
reportserver.world =
(ADDRESS =
(PROTOCOL = TCP)
(Host = NTCLU-162) <- virtual address
(Port=9100) <- port specified in the
Add Resource to Group Wizard
)
After you configure an Oracle Reports Server for high availability, additional steps are needed if you are using a master/slave configuration.
This section provides step-by-step instructions for implementing master/slave Oracle Reports Servers. The example presented in this section describes the following:
Necessary background information for the master/slave example (Section 10.5.1)
Enabling communication between the master and the slaves (Section 10.5.2)
Adding a slave server to an existing implementation (Section 10.5.3)
Table 10-2 shows the server systems used for the master/slave configuration example.
Table 10-2 Example Master/Slave Implementation
| Reports Server Name | System Name | Master or Slave | TNS Name |
|---|---|---|---|
| Reports_Master | ntclu4-3 | Master | ntclu4-5 (virtual address) |
| nt-2 | nt-2 | Slave | nt-2 |
| sun-1 | sun-1 | Slave | sun-1 |
The following statements are true for each system:
The Oracle Reports Server component is installed.
A central file server is running and set up with three directories: a source directory (where report definition files are stored), a cache directory (where all cached report output is sent), and a jobs directory (where the Oracle Reports Server job scheduling data file is located). This central file server is the shared cluster disk you specify when you add an Oracle Reports Server to a group and specify the source directory, cache directory, and jobs directory.
Each Oracle Reports runtime engine must write its output to a central cache, and each Oracle Reports runtime engine reads report definition files from a central source directory. A central source directory guarantees that all runtime engines run the same reports. This also eliminates the need for you to copy updated report definition files to various locations. A central cache enables the master server to serve duplicate jobs, and jobs run within the specified tolerance without going to each slave server's local disk.
All Oracle Reports runtime engines use the same aliases for printers (unless the output is always sent to the default printers).
To enable communication between the master and slaves, you need to alter the tnsnames.ora files and Oracle Reports Server configuration files on all cluster nodes where the master Oracle Reports Server can run, and on the systems where the slave Oracle Reports Servers can run.
This is true whether or not the master server is configured for high availability. However, when the master server is configured for high availability, you specify the virtual address of the master server in the tnsnames.ora file, rather than the host name of the system on which the master server is currently running. The following sections describe the steps in detail.
(Throughout this example, Reports_Master.world, nt-2.world, and sun-1.world are the names of the server instances, and .world is the domain specified in the NAMES.DEFAULT_DOMAIN setting in the sqlnet.ora file. If the NAMES.DEFAULT_DOMAIN setting is not defined in the sqlnet.ora file, then omit .world from the name of the server instance.)
On the cluster node where the group containing the Reports_Master Server resides, take the following steps to identify the slave servers to the master server, specify the central location of the cache directory for each slave server, and specify the runtime parameters for each slave server.
In a text editor, open the tnsnames.ora file located in the <Oracle_Home>\NET80\ADMIN directory on the cluster node where the Reports_Master Server is running, and add the following lines to identify the slave servers:
nt-2.world=(ADDRESS=(PROTOCOL=tcp) (HOST=nt-2) (PORT=1949)) sun-1.world=(ADDRESS=(PROTOCOL=tcp) (HOST=sun-1) (PORT=1949))
Edit the Reports_Master.ora file (the master Oracle Reports Server configuration file) located in the <Oracle_Home>\REPORT60\SERVER directory, and set the CLUSTERCONFIG parameter to identify the slave servers to the master, as follows:
sourcedir="x:\Source" cachedir="x:\Cache" persistfile="x:\Jobs" . . . clusterconfig="(server=nt-2 minengine=0 maxengine=2 initengine=2 cachedir="W:\Cache") (server=sun-1 minengine=0 maxengine=2 initengine=2 cachedir="/share/Cache")"
Take the Reports_Master Server offline, and then place it online again using either Oracle Fail Safe Manager or the FSCMD command. The new configuration will not be used until this is done.
Verify the group containing the Reports_Master Server so that the configuration files (tnsnames.ora and Reports_Master.ora) are updated on the other cluster nodes that are possible owners for the master Reports Server.
Note the following:
Each cluster node is mapped to the central file server using the X: drive.
The server parameter is the TNS service entry name of the slave server.
The values specified for minengine, maxengine, and initengine are specified only to provide context for the example. There is no requirement for you to specify these values in your master/slave implementation. See the Oracle Reports documentation for information on setting these parameters for the slave server.
The cachedir parameter is the central cache directory for the master server.
The cache directory settings for the slave servers are different. Not all servers need to see the shared file system by the same definition. (In this example, the master is mapped to the X: drive, while the NT slave is mapped to the W: drive, and the Sun (UNIX) slave is mapped to the /share/Cache network share. However, all definitions point to the same location: the shared cluster disk that you added when you configured the Oracle Reports Server for high availability.)
The slave servers must have the REPORT60_PATH environment variable set to /share/Source (for the sun-1 system) and set to W:\Source (for the nt-2 system).
The following steps describe the adjustments to make for each slave server. The main purpose is to update the tnsnames.ora file on each slave system so that each can locate the Reports_Master Server at its virtual server address.
Open the tnsnames.ora file located in the <Oracle_Home>\NET80\ADMIN directory in a text editor, and add the following lines to identify the master Oracle Reports Server and the database that the slave Oracle Reports Server should access:
Reports_Master.world=(ADDRESS=(PROTOCOL=tcp) (HOST=ntclu4-5) (PORT=1949)) Reports_db.world=(ADDRESS=(PROTOCOL=tcp) (HOST=ntclu4-7) (PORT=7687))
Note that the host for the Reports_Master.world is the virtual address of the highly available master Oracle Reports Server. Similarly, if you have made the database that the Oracle Reports Servers access highly available, the HOST entry for the database should be the virtual address of the database.
Open the nt-2.ora file (the Oracle Reports Server configuration file) located in the <Oracle_Home>\REPORT60\SERVER directory, and set the INITENGINE parameter to 0. This ensures that the only runtime engines created at startup are those started by the master.
Repeat steps 1 and 2 on the sun-1 system. However, in step 2, edit the sun-1.ora configuration file in the <Oracle_Home>/Report60/Server directory.
If you want to add a new slave server to an existing master/slave implementation, you need to adjust the tnsnames.ora file and the Oracle Reports Server configuration file on both the master and the slave server systems.
Assume the existing implementation is that shown in Table 10-2 and that you want to add a slave server named sun-2 running on a Sun Solaris system, also named sun-2. The following sections describe the changes you need to make on the cluster where the Reports_Master Server resides and on the system where the slave is running.
In this example, nt-2.world, sun-1.world, and sun-2.world are the names of the server instances and .world is the domain specified in the NAMES.DEFAULT_DOMAIN setting in the sqlnet.ora file. If the NAMES.DEFAULT_DOMAIN setting is not defined in the sqlnet.ora file, then omit .world from the name of the server instance.
On the cluster node where the group containing the Reports_Master Server resides:
Open the tnsnames.ora file located in the <Oracle_Home>\NET80\ADMIN directory and add the following entry:
sun-2.world=(ADDRESS=(PROTOCOL=tcp) (HOST=sun-2) (PORT=1949))
Open the Reports_Master.ora file (Oracle Reports Server configuration file) and add the following bolded text to the already existing CLUSTERCONFIG parameter:
clusterconfig="(server=nt-2 minengine=0 maxengine=2 initengine=2 cachedir="W:\Cache") (server=sun-1 minengine=0 maxengine=2 initengine=2 cachedir="/share/Cache") (server=sun-2 minengine=0 maxengine=4 initengine=4 cachedir="/share/Cache")"
Take the Reports_Master server offline, and then place it online again using either Oracle Fail Safe Manager or the FSCMD command. The new configuration will not be used until this is done.
Verify the group containing the Reports_Master Server so that the configuration files (tnsnames.ora and Reports_Master.ora) are updated on the other cluster nodes that are possible owners for the master Reports Server.
The following steps describe the adjustments to make for the slave server. The main purpose is to update the tnsnames.ora file on the slave system so that it can locate the Reports_Master Server at its virtual server address.
Open the tnsnames.ora file located in the <Oracle_Home>/NET80/ADMIN directory and add the following lines to identify the master Oracle Reports Server and the database that the slave Oracle Reports Server should access:
Reports_Master.world=(ADDRESS=(PROTOCOL=tcp) (HOST=ntclu4-5) (PORT=1949)) Reports_db.world=(ADDRESS=(PROTOCOL=tcp) (HOST=ntclu4-7) (PORT=7687))
Note that the host for the Reports_Master.world is the virtual address of the highly available master Oracle Reports Server. Similarly, if you have made the database that the Oracle Reports Servers access highly available, the HOST entry for the database should be the virtual address of the database.
Open the sun-2.ora file (the Oracle Reports Server configuration file) located in the <Oracle_Home>/REPORT60/SERVER directory, and set the INITENGINE parameter to 0. (This ensures that the only runtime engines created at startup are those started by the master.) In addition, add the following entry:
Reports_Master.world=(ADDRESS=(PROTOCOL=tcp) (HOST=ntclu4-5) (PORT=1949))
In this example, ntclu4-5 is the virtual address associated with the master Oracle Reports Server, not the physical host on which it is currently running.
Oracle Reports supports the use of Oracle Portal for controlling user access to Oracle Reports. You can use Oracle Portal in this manner for an Oracle Reports Server that you have configured for high availability. Follow the instructions in the Oracle Reports Services documentation on publishing reports to the Web (which is part of the Oracle9i Applications Server documentation library), but make the following network adjustments so that the virtual address is used instead of the physical addresses of the Oracle Reports Server. This example specifies that the Oracle Portal database instance be configured for high availability.
Use Oracle Fail Safe Manager to make the Oracle Portal database instance that you will be using to control access to the reports highly available. (Add the Oracle Portal database instance to a group.)
Open the report-server.ora configuration file (located in the <Oracle_Home>\REPORT60\SERVER directory on the cluster node where the group containing the Oracle Reports Server resides) and add the following syntax:
SECURITYTNSNAME="sec-rep"
In this example, sec-rep is the virtual address of the group to which you added Oracle Portal database server instance.
Take the Oracle Reports Server offline and then place it online again using either Oracle Fail Safe Manager or the FSCMD command. The new configuration will not be used until this is done.
Edit the report-server.ora configuration file (as described in step 2) on the other cluster nodes that are possible owners for the Oracle Reports Server.
You can schedule jobs for highly available Oracle Reports Servers as you would for standalone Oracle Reports Servers. The job scheduling information is stored in a persist file (<reports-server-name>.dat). With Oracle Reports, you can set up a database to take snapshots of the Oracle Reports Server queue activity whenever jobs are run.
When you configure an Oracle Reports Server for high availability, the Add Resource to Group Wizard asks you to specify the location of the jobs schedule file (<reports-server-name>.dat). Oracle Fail Safe requires that you place the <reports-server-name>.dat file on a shared cluster disk, so that the Oracle Reports Server can find the .dat file, regardless of the cluster node on which the Oracle Reports Server is currently running. In a failover, Oracle Reports applications that are scheduled to run at a later time will do so; a failover will not affect the scheduled run of these reports.
However, note that any Oracle Reports applications that are running when a failover occurs will be lost. An Oracle Reports application will be retried only if it was scheduled to be retried and the retry limit has not been reached.
Oracle Reports provides a feature that allows you to set up a database to take snapshots of the Oracle Reports Server queue activity whenever jobs are run. This allows users to find out the status of any report they have submitted, and allows administrators find out how many concurrent users the Reports Server has. This is useful for both sizing the environment and to ensure license compliance.
The Oracle Reports Server posts the current report queue to the database each time a job request is submitted. This information is inserted into a table called RW_SERVER_QUEUE and includes such data as:
The name of the job
Who submitted a job
What output format was chosen for a job
The current status of a job
You can use a database in this manner for an Oracle Reports Server that you have configured for high availability. Follow the instructions in the Oracle Reports documentation (including creating a schema that will own the report queue and will have execute privileges on the server-queue API), but make sure that you also do the following:
Make the database that you are using as a jobs repository highly available by adding that database to a group.
Add the REPOSITORYCONN parameter to the Oracle Reports Server configuration file on the node where the group containing the Oracle Reports Server resides. Follow the instructions for adding this parameter as described in the Oracle Reports documentation.
Repeat step 2 on the other cluster nodes that are possible owners for the Oracle Reports Server.
Using Oracle Fail Safe Manager or the FSCMD command, stop and restart the Oracle Reports Server so that the changes to the configuration file are accepted.
The following sections describe how to troubleshoot specific problems you may encounter with Oracle Reports Servers configured for high availability. For general information about troubleshooting Oracle Reports Servers, see the Oracle Reports documentation.
In most cases, the first step in troubleshooting a problem is to issue the Verify Cluster or Verify Group command. These tools are described in Chapter 6.
When you issue a Verify Group command on a group containing an Oracle Reports Server, Oracle Fail Safe compares the information in the cluster registry to what is actually written in the configuration files. If the information does not match, Oracle Fail Safe will ask you if you want it to fix the problem.
You can run the Verify Group operation at any time. However, you should run it when any of the following occurs:
A group or resource in a group does not come online.
Failover or failback does not perform as you expect.
A new node is added to the cluster.
If you receive an error that the CGI executable file cannot be found, try the following:
If the Oracle Reports Server tries to download the rwcgi60.exe file instead of trying to run it, check the permissions in the Web server configuration. The virtual directory (for example, web_cgi) should be set to "execute."
If users cannot communicate with the Oracle Reports Server, perform the following actions:
Make sure the Oracle Reports Server resource is online.
Check that the server name that you specified as a URL to the Web browser, or that is specified in the .html file, is set correctly. The following example shows the server name in the boldface type:
<A HREF=".../rwcgi60.exe?server=demoreportserver+report=...">
The server name must be defined in the tnsnames.ora file.
If the Web browser cannot find the Oracle Reports definition (.rdf or .rep) file, perform the following actions:
Check that the Oracle Reports name that you specified as part of the URL to the Web browser, or that is specified in the .html file, is set correctly. The following example shows the Oracle Reports name in boldface type:
<A HREF="...?server=...+report=employees+userid...">
You do not need to specify the .rdf or .rep file extension on the file name.
Check that the Oracle Reports definition file exists in the source directory location. (The source directory is the location on a cluster disk that contains the Oracle Reports definition (.rdf or .rep) file.)
If the Oracle Reports application does not run properly in your Web browser, try the following:
Check the availability of the database that the Oracle Reports application is accessing, by connecting to and querying the database.
Correct any problems you encounter when you attempt to run the report locally and retry running the report in the Web browser.
If users cannot locate the output from the Reports application, perform the following actions:
Verify that the Web server virtual directory (output) points to the Oracle Reports cache directory.
Make sure that the following Windows registry entries are set correctly:
|
 Copyright © 1996, 2002 Oracle Corporation All rights reserved | | Ad Choices. |
|