8
Understanding the Real Application Clusters Installed Configuration

This chapter describes the Oracle Real Application Clusters installed configuration. The topics in this chapter include:

• Understanding the Configured Environment in Real Application Clusters
• Shared Configuration File in Real Application Clusters
• UNIX oratab Configurations for Real Application Clusters
• Database Components Created Using the Database Configuration Assistant
• Managing Undo Tablespaces in Real Application Clusters
• Initialization Parameter Files
• Configuring Service Registration-Related Parameters in Real Application Clusters
• Configuring the Listener File (listener.ora)
• Directory Server Access (ldap.ora File)
• Net Service Names (tnsnames.ora File)
• Profile (sqlnet.ora File)

Understanding the Configured Environment in Real Application Clusters

The Oracle Net Configuration Assistant and the Database Configuration Assistant (DBCA) configure your environment to meet the requirements for database creation and Oracle Enterprise Manager discovery of Real Application Cluster databases.

Shared Configuration File in Real Application Clusters

The Database Configuration Assistant uses a shared configuration file for storing the configurations for the cluster databases that it creates. This file is a shared file in a cluster file system environment. If you do not use a cluster file system, then you must make this file a shared raw device in UNIX environments, or a shared logical partition in Windows environments.

The Oracle Universal Installer (OUI) automatically initializes this shared configuration file by executing the srvconfig -init command. If this initialization does not complete, manually initialize the shared configuration file by executing the srvconfig -init command.

You can also use the srvconfig command to import or export the contents of the shared configuration file to or from a text file. In Windows environments, you can convert the configuration for a pre-Oracle9i Oracle Parallel Server in the Registry entries into a shared configuration file using the srvconfig -convert command. In UNIX environments you can also use the srvconfig command to convert a pre-Oracle9i Oracle Parallel Server dbname.conf file into a shared configuration file. Refer to one of the following sections for platform-specific information about the srvconfig command:

• Executing srvconfig on UNIX Platforms
• Executing srvconfig on Windows Platforms

Executing srvconfig on UNIX Platforms

Executing the srvconfig -init command syntax requires that the srvConfig.loc file exists and that it contains the following entry:

srvconfig_loc=path_name

Where path_name is the complete path name for the shared configuration file. The srvConfig.loc file usually resides in the /var/opt/oracle directory. However, on HPUX, it resides in the /etc directory.

Executing srvconfig on Windows Platforms

Executing the srvconfig -init command on Windows NT and Windows 2000 platforms requires a symbolic link named srvcfg that you create using the Object Link Manager (OLM). This symbolic link must refer to the correct disk partition.

UNIX oratab Configurations for Real Application Clusters

This section describes the oratab file configuration for UNIX operating systems.

The oratab File on UNIX

Oracle creates an entry for each Real Application Clusters database in the oratab file. Oracle Enterprise Manager uses this file during service discovery to determine the name of the Real Application Clusters database as well whether the database should be auto-started on restart. The Real Application Clusters database entry has the following syntax:

db_name:$ORACLE_HOME:N

Where db_name is the database name for your Real Application Clusters database, $ORACLE_HOME is the directory path to the database, and N indicates that the database should not be started at restart time. A sample entry for a database named db is:

db:/private/system/db:N

Database Components Created Using the Database Configuration Assistant

This section describes the database components that the DBCA creates which include:

• Tablespaces and Datafiles
• Control Files
• Redo Log Files

Tablespaces and Datafiles

An Oracle database for both single-instance and cluster database environments is divided into smaller logical areas of space known as tablespaces. Each tablespace corresponds to one or more datafiles stored on a disk. Table 8-1 shows the tablespace names used by a Real Application Clusters database and the types of data they contain:

Table 8-1  Tablespace Names that Real Application Clusters Databases Use

You cannot alter these tablespace names when using the preconfigured database configuration options from the Oracle Universal Installer. However, you can change the names of the tablespaces if you use the Customized database creation method.

As mentioned, each tablespace has one or more datafiles. The datafile names created by the preconfigured database configuration options vary by operating system. UNIX operating systems, for example, prompt you to set the file names. Windows NT and Windows 2000 operating systems use the symbolic link names shown in Table 8-2:

Table 8-2  Windows NT and Windows 2000 Symbolic Link Names

db_redo1_1
db_redo1_2

db_redo2_1
db_redo2_2

You can specify different symbolic names with the Customized database configuration option.

Control Files

The database is configured with two control files that are stored on the raw devices. The control files' file names that are created by the preconfigured database configuration options vary by operating system. UNIX operating systems prompt you to set the file names. Windows NT and Windows 2000 operating systems use symbolic link names of db_name_control1 and db_name_control2. You can change the control file names or symbolic link names using the DBCA Storage page.

Redo Log Files

Each instance is configured with at least two redo log files that are stored in the shared files. If you have a cluster file system, then these files are file system files. If you do not have a cluster file system, then these files are raw devices. The redo log files' file names created with the preconfigured database configuration options vary by operating system.

You must enter the raw device names on UNIX unless you are using a cluster file system. On Windows NT and Windows 2000 use symbolic link names of \\.\db_name_thread_number, where thread is the thread ID of the instance, and number is the number, 1 or 2, of the redo log file.

To use the Customized database creation method, locate the redo log files in the Database Storage page and replace their default filenames with the correct raw device names or symbolic link names.

Managing Undo Tablespaces in Real Application Clusters

Oracle stores rollback or undo information in undo tablespaces. To manage undo tablespaces, Oracle Corporation recommends that you use automatic undo management. Automatic undo management is an automated undo tablespace management mode that is easier to administer than manual undo management.

If you are not using automatic undo management, then the undo rollback segments created for the Customized database creation type have names in the format of rbsthread_number, where thread is the thread ID of the instance, and number is the number, 1 or 2, of the rollback segment.

Initialization Parameter Files

Oracle Corporation recommends using the server parameter file. This file resides on the server on the shared disk; all instances in a cluster database can access this parameter file.

Configuring Service Registration-Related Parameters in Real Application Clusters

Two key benefits of Real Application Clusters are connection load balancing and failover. Real Application Clusters extends the ability of single-instance Oracle database load balancing, where connections are distributed among local dispatchers, to the balancing of connections among all instances in a cluster database. In addition, Real Application Clusters provides failover by configuring multiple listeners on multiple nodes to manage client connection requests for the same database service. Connection load balancing and failover increase availability by taking advantage of the redundant resources within a cluster database. These features, however, require cross instance registration.

Cross instance registration in Real Application Clusters occurs when an instance's PMON process registers with the local listener and with all other listeners. Thus, all instances in the cluster database register with all listeners in the cluster. This enables all listeners to manage connections across all instances for both load balancing and failover.

Cross instance registration requires configuring the LOCAL_LISTENER and REMOTE_LISTENER initialization parameters. The LOCAL_LISTENER parameter identifies the local listener and the REMOTE_LISTENER parameter identifies the global list of listeners. The REMOTE_LISTENER parameter is dynamic initialization parameters. Oracle changes the setting for REMOTE_LISTENER dynamically when you reconfigure your cluster database, for example, when you add or delete instances.

By default, the DBCA configures your environment with dedicated servers. However, if you select the Shared server option on the DBCA, then Oracle configures the shared server. In this case, Oracle uses both dedicated and shared server processing. When shared servers are configured, the DISPATCHERS parameter is specified as in the following example:

DISPATCHERS="(protocol=tcp)"

If the DISPATCHERS initialization parameter does not specify the LISTENER attribute as in the previous example, then the PMON process registers information for all dispatchers with the listeners specified by the LOCAL_LISTENER and REMOTE_LISTENER parameters.

However, when the LISTENER attribute is specified, the PMON process registers dispatcher information with the listeners specified by the LISTENER attribute. In this case, setting the LISTENER attribute overrides REMOTE_LISTENER settings for the specified dispatchers as in the following example:

DISPATCHERS="(protocol=tcp)(listener=listeners_db_name)"

Configuring the Listener File (listener.ora)

You can configure two types of listeners in the listener.ora file as described under the following headings:

• Local Listeners
• Multiple Listeners
• How Oracle Uses the Listener (listener.ora File)

Local Listeners

If you configured dedicated server mode using the DBCA Database Connection Options page, then DBCA automatically configures the LOCAL_LISTENER parameter even when the listener uses a default address port 1521.

If you configured the dedicated server mode by setting the REMOTE_LISTENER initialization parameter, then you must also configure the instance-specific LOCAL_LISTENER initialization parameter.

For example, to configure the LOCAL_LISTENER parameter add the following entry, add the following entry to the initialization parameter file, where listener_sid is resolved to a listener address through either a tnsnames.ora file or through the Oracle Names Server:

sid.local_listener=listener_sid

The following entry should be in your tnsnames.ora file:

listener_sid=<address=<protocol=tcp><host=node1><port=1521>>

Multiple Listeners

If the DBCA detects more than one listener on the node, it displays a list of the listeners. You can select one or all of these listeners with which to register your database.

How Oracle Uses the Listener (listener.ora File)

Services coordinate their sessions using listener file entries by running a process on the server that receives connection requests on behalf of a client application. Listeners are configured to respond to connection requests sent to protocol addresses for a database service or non-database service.

Protocol addresses are configured in the listener configuration file, listener.ora, for a database service or a non-database service. Clients configured with the same addresses can connect to a service through the listener.

During a preconfigured database configuration installation, the Oracle Net Configuration Assistant creates and starts a default listener called LISTENER. The listener is configured with default protocol listening addresses for the database and external procedures. A Customized installation prompts you to create at least one listener with the Oracle Net Configuration Assistant. The listener is configured to respond to connection requests that are directed at one protocol address you specify, as well as an address for external procedures.

Both installation modes configure service information about the Real Application Clusters database and external procedures. An Oracle9i Release 2 (9.2) database service automatically registers its information with the listener, such as its service name, instance name(s), and load information.

This feature, called service registration, does not require configuration in the listener.ora file. However, Oracle Enterprise Manager tools require static service configurations in the listener.ora file to discover the database instance-to-listener mappings. The database service information includes the Oracle home of the database instance and the Oracle System Identifier (sid) information of the instance.

After listener creation, the Oracle Net Configuration Assistant starts the listener. A sample listener.ora file with an entry for an instance named db1 is:

listener= 
  (description= 
    (address=(protocol=ipc)(key=extproc))) 
    (address=(protocol=tcp)(host=db1-server1)(port=1521)))
sid_list_listener= 
  (sid_list= 
    (sid_desc= 
      (sid_name=plsextproc) 
      (oracle_home=/private/system/db) 
      (program=extproc)
 (sid_desc=
 (oracle_home=/private/system/db)
 (sid_name=db1)))

Notice that the second sid_DESC entry for the instance does not use the GLOBAL_DBNAME parameter entry; this prevents the disabling of transparent application failover (TAF). This entry is typical for a listener.ora file entry for a single-instance database, as shown in the following:

 (sid_desc=
  (global_dbname=sales.us.acme.com)
  (sid_name=sales)
  (oracle_home=/private/system/db)))

Listener Registration and PMON Discovery

When a listener starts after the Oracle instance starts, and the listener is listed for service registration, registration does not occur until the next time the PMON discovery routine executes. By default, PMON discovery occurs every 60 seconds.

To override the 60 second delay, use the SQL statement ALTER SYSTEM REGISTER. This statement forces PMON to register the service immediately.

Oracle Corporation recommends that you create a script to execute this statement immediately after starting the listener. If you execute this statement while the listener is up and the instance is already registered, or while the listener is down, then the statement has no effect.

Directory Server Access (ldap.ora File)

If you configure access to a Lightweight Directory Access Protocol (LDAP)-compliant directory server with the Oracle Net Configuration Assistant during a Customized installation, an ldap.ora file is created. The ldap.ora file contains the following types of information:

• Type of directory
• Location of the directory
• administrative context from which this server can look up, create, and modify a net service name, and the database service entries

  See Also: Oracle9i Net Services Administrator's Guide for further information about directory naming configuration and directory server access configuration

Net Service Names (tnsnames.ora File)

A tnsnames.ora file is created on each node with net service names or with an LDAP directory (if configured during a Customized installation) is configured with net service names. A connect identifier is an identifier that maps to a connect descriptor. A connect descriptor contains the following information:

• The network route to the service, including the location of the listener through a protocol address
• The SERVICE_NAME for an Oracle release 8.1 or later, or sid for pre-8.1 Oracle releases

  Note: The SERVICE_NAME parameter you use in tnsnames.ora is singular because you can only specify one service name.

The DBCA creates net service names for connections as shown in Table 8-3:

Table 8-3  Connections for Net Service Names

db.us.acme.com= 
 (description= 
  (load_balance=on)
   (address=(protocol=tcp)(host=db1-server)(port=1521)
   (address=(protocol=tcp)(host=db2-server)(port=1521) 
  (connect_data=
     (service_name=db.us.acme.com)))

db1.us.acme.com= 
 (description= 
  (address=(protocol=tcp)(host=db1-server)(port=1521))
  (connect_data= 
    (service_name=db.us.acme.com)
    (instance_name=db1)))

REMOTE_LISTENERS=listeners_<dbname>

listeners_db.us.acme.com= 
   (address=(protocol=tcp)(host=db1-server)(port= 1521))
   (address=(protocol=tcp)(host=db2-server)(port=1521))

sid.local_listener=listener_sid

listener_db1.us.acme.com= 
   (address=(protocol=tcp)(host=db1-server)(port= 1421))

extproc_connection_data.us.acme.com= 
 (description= 
  (address_list= 
    (address=(protocol=ipc)(key=extproc0))
  (connect_data= 
    (sid=plsextproc)))

Example 8-1 Example tnsnames.ora File

The following is a sample tnsnames.ora file that is created during a preconfigured database configuration installation:

db.us.acme.com= 
 (description= 
  (load_balance=on)
  (failover=on)
  (address_list=
   (address=(protocol=tcp)(host=db1-server)(port=1521))
   (address=(protocol=tcp)(host=db2-server)(port=1521))) 
  (connect_data=
     (service_name=db.us.acme.com)))

db1.us.acme.com= 
 (description= 
  (address=(protocol=tcp)(host=db1-server)(port=1521))
  (connect_data= 
    (service_name=db.us.acme.com)
    (instance_name=db1)))

db2.us.acme.com= 
 (description= 
  (address=(protocol=tcp)(host=db2-server)(port=1521))
  (connect_data= 
    (service_name=db.us.acme.com)
    (instance_name=db2)))

listeners_db.us.acme.com= 
   (address=(protocol=tcp)(host=db1-server)(port=1521))
   (address=(protocol=tcp)(host=db2-server)(port=1521))

extproc_connection_data.us.acme.com= 
 (description= 
  (address_list= 
    (address=(protocol=ipc)(key=extproc))
  (connect_data= 
    (sid=plsextproc)
    (presentation=RO)))

Profile (sqlnet.ora File)

The sqlnet.ora file is automatically configured with:

• The computer's domain

  This domain is automatically appended to any unqualified net service name. For example, if the default domain is set to us.acme.com, then Oracle resolves db in the connect string CONNECT scott/tiger@db as: db.us.acme.com.

• A naming method the server uses to resolve a name to a connect descriptor

  The order of naming methods is as follows: directory naming (for the Customized installations only), tnsnames.ora file, Oracle Names server, and host naming.

The following is a sample SQLNET.ORA file created during a preconfigured database configuration install:

names.default_domain=us.acme.com
names.directory_path=(tnsnames, onames,hostname)