Oracle® Files Administrator's Guide Release 2 (9.0.4) Part Number B10872-02 |
|
|
View PDF |
This appendix describes how to configure Oracle Files to leverage the features of Oracle9i Real Application Clusters (RAC). It provides high-level background information about RAC and discusses the configuration steps that must be performed to allow Oracle Files to function properly with a RAC configuration.
This appendix includes the following topics:
A cluster is a group of computers acting together that behave like a single system. Clustering requires both hardware (interconnect) and software (clusterware) support. Traditionally, clusters were used in high availability read-only applications, such as data warehouses. These days, clusters are increasingly becoming a lower-cost approach to computing applications that require very high availability and scalability.
An Oracle9i Real Application Cluster consists of two or more computers configured to interact to provide the appearance of a single Oracle database. These two or more nodes are linked by an interconnect. The interconnect serves as the communication path between each node in the cluster database. Each Oracle instance uses the interconnect for the messaging that synchronizes each instance's use of shared resources. Oracle also uses the interconnect to transmit data blocks that are shared by the multiple instances. The datafiles accessed by all the nodes are the primary type of shared resource.
RAC requires that all nodes have simultaneous access to the shared disks to give the instances concurrent access to the database. The implementation of the shared disk subsystem is based on your operating system: you can use either a cluster file system, or place the files on raw devices. Cluster file systems greatly simplify the installation and administration of Oracle9i Real Application Clusters.
See Figure D-1 for an example of a RAC configuration.
For more information about Oracle9i RAC, see Oracle9i Real Application Clusters Concepts.
The following sections provide information on load balancing, failover, and connect descriptor settings:
Oracle9i RAC is a set of instances operating against the same database. The instances have a common service name, but distinct instance names. In order to enable client load balancing, you should set up multiple database listeners. Clients can balance connection requests across these listeners by supplying a list of listener addresses in their connect descriptor, which Net8 will use on a round-robin basis.
Figure D-2 illustrates client load balancing.
Example D-1 Sample tnsnames.ora Entry Enabling Load Balancing
myrac.us.oracle.com = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = myrac1.us.oracle.com)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = myrac2.us.oracle.com)(PORT = 1521)) (LOAD_BALANCE = ON) (FAILOVER = OFF) (CONNECT_DATA = (SERVICE_NAME = myrc.us.oracle.com) (FAILOVER_MODE = (TYPE=SELECT)(METHOD=BASIC)) ) )
Another benefit of multiple listeners is fault-tolerance of listener failure. Clients can failover to alternate listeners at connect time by supplying a list of listeners in their connect descriptor. Figure D-3 illustrates connect time failover.
Figure D-3 When lsnr1 Fails, Requests Can Be Re-routed to lsnr2
Example D-2 Sample tnsnames.ora Entry Enabling Failover
myrac.us.oracle.com = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = myrac1.us.oracle.com)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = myrac2.us.oracle.com)(PORT = 1521)) (LOAD_BALANCE = OFF) (FAILOVER = ON) (CONNECT_DATA = (SERVICE_NAME = myrc.us.oracle.com) (FAILOVER_MODE = (TYPE=SELECT)(METHOD=BASIC)) ) )
Transparent Application Failover (TAF) allows an existing connection to fail over to another listener, without needing to reestablish the connection. The in-progress transaction must be rolled back, but there is no need to reestablish the database connection. Cursors may be optionally preserved (with a performance overhead for all normal select operations). Clients request TAF through the connect descriptor.
By setting the <DatabaseUrl>
entry in the registry.xml
configuration file, Oracle Files services can opt-out of the default connect descriptor and specify a connect identifier whose corresponding connect descriptor specifies the FAILOVER_MODE
and failover listeners.
A database listener sitting in front of multiple RAC instances can provide load balancing across them. The listener is aware of each instance, whether it is running or down, and its load. In creating a database connection, a client generally specifies only the database service name and listener address, and not the instance name, in order to defer instance selection to the listener's load balancing algorithm. This is called listener or connection load balancing (see Figure D-4).
For more information about listeners and database connections, see the Oracle9i Net Services Administrator's Guide.
If you configure your system for listener-only load balancing, note the following:
You do not need to set the <DatabaseUrl>
property in registry.xml
. For more information, see "Oracle Files Connect Descriptor Settings for RAC".
You cannot use TAF.
The listener becomes a single point of failure for your system.
For optimal high availability and performance, you should configure your system for both client and listener load balancing. Figure D-5 illustrates this scenario.
When planning to use Oracle Files in a RAC environment, you should set the <DatabaseUrl>
property in registry.xml
since this value can be used by the Domain Controller, the management and administration tools, and the Oracle Files nodes during their operation. You must set this entry on all middle tiers.
If you are setting up your system for listener-only load balancing, you do not need to set the <DatabaseUrl>
property in registry.xml
. Oracle Files will synthesize a minimally-defined connect descriptor from the domain name.
Read the following sections for information on preconfiguration, configuration, and post-configuration tasks for Oracle Files in a RAC environment.
You can choose to run Oracle Files against a Oracle9i Real Applications Clusters database at any time, either preconfiguration or post-configuration. However, if you know that you want to point to a RAC database for your initial Oracle Files deployment, perform the preconfiguration steps listed in the following sections.
You should set the MAX_COMMIT_PROPAGATION_DELAY
system parameter in the RAC database as follows:
MAX_COMMIT_PROPAGATION_DELAY=1
During Oracle Files configuration and operation, objects are often created and then read back right away for various reasons, like the creation of subclasses or keeping middle-tier caches up-to-date. In a RAC configuration, looking for a data value from instance A that was committed by instance B can cause problems if instance A does not yet have the updated information. For this reason, you should set the MAX_COMMIT_PROPAGATION_DELAY
to a very small value so that the information is instantaneously made available to all instances.
Setting MAX_COMMIT_PROPAGATION_DELAY
to zero or to any value below 100 will have the same effect, that is to use the broadcast on commit System Change Number (SCN) generation scheme. By default, the system uses a scheme called the Lamport scheme and a MAX_COMMIT_PROPAGATION_DELAY
value of 700 hundredths of a second, or seven seconds. You can see this in the alert.log
file ("Picked xxx scheme to generate SCNs"). The only exception is Tru-64: on that platform, setting MAX_COMMIT_PROPAGATION_DELAY
to zero is not recommended because it causes excessive system CPU consumption. Unfortunately, zero is the default on Tru-64, so this value must be changed for this platform. Setting the parameter to anything between 1 and 99 will have the desired broadcast on commit behavior, although it will not be reported as such in the alert.log
file (instead it will say "Picked Lamport Server scheme to generate SCNs"). The bottom line is that if you want to set this parameter to a value that guarantees broadcast on commit for all platforms, select a value between 1 and 99. The fact that the parameter is a number in hundredths of a second is misleading, as anything between 1 and 99 works exactly the same way.
Ensure that the JOB_QUEUE_PROCESSES
parameter is set to a value of 10 or higher. This parameter is required for running Oracle Files database jobs and is typically not set high enough (it may even be 0 by default).
Make a TNS entry in the tnsnames.ora
file for load balancing and connection failover options in each Oracle home used by Oracle Files. See Oracle9i Real Application Clusters Administration for more information on making a TNS entry for these options. Here is a sample TNS entry which specifies multiple hosts for use in a RAC environment using sample address values:
myrac.us.oracle.com = (DESCRIPTION = (ENABLE = BROKEN) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = myrac1.us.oracle.com)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = myrac2.us.oracle.com)(PORT = 1521)) ) (LOAD_BALANCE = ON) (FAILOVER = ON) (CONNECT_DATA = (SERVICE_NAME = myrc.us.oracle.com) (FAILOVER_MODE=(TYPE=select)(METHOD=basic)(RETRIES=20)(DELAY=15)) ) )
For general information about TNS entries, see the Oracle9i Net Services Reference Guide.
Configure Oracle Files, specifying the name of the RAC database on the Database Selection screen of the Oracle Files Configuration Assistant.
For information about how to configure Oracle Files using the Oracle Files Configuration Assistant, see the Oracle Collaboration Suite Installation and Configuration Guide.
Perform the post-configuration tasks listed in the following sections if you are using Oracle Files with a RAC database.
On each middle tier, back up and then edit the registry.xml
file (located in $ORACLE_HOME/ifs/common/
) to add a <DatabaseUrl>
entry. You can add the <DatabaseUrl>
entry anywhere between <Instance>
and </Instance>
.
In the following example, the entry is added directly under the tag. Note that the TNS value you specify should be the same as that specified in the RAC pre-configuration steps.
<Instance> <DatabaseUrl>jdbc:oracle:oci8:@myrac.us.oracle.com</DatabaseUrl> <Domain>ifs://DBHOME:1521:dbservice:ifssys</Domain> <DomainType>files</DomainType> <Registered>1018925008096</Registered> <LastModified>1028330926700</LastModified> <LastStarted>1028329087966</LastStarted> <Ports></Ports> </Instance>
If you are using the Oracle Enterprise Manager Grid Control, you need to configure the Oracle Files target in the Grid Control for a RAC environment.
The Grid Control provides Oracle Files SQL metrics, such as Document Statistics, Documents By MIME Type, and Users. For these metrics to work against a RAC database, you must properly configure the DBConnectDescriptor
for the Oracle Files target in the Grid Control.
The value of DBConnectDescriptor
can be either a naming service connect identifier in the tnsnames.ora
, or an explicit identifier for the database connect descriptor. If you choose to specify a naming service connect identifier, you must create a TNS entry in the tnsnames.ora
file that resides in the Oracle home of the Grid Control Management Agent that resides on the Oracle Files middle tier.
For details on how to set this property, see Oracle Enterprise Manager Managing Oracle Collaboration Suite on the Oracle Technology Network at: