8
Understanding The Installed Configuration for Real Application Clusters

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

• Understanding the Configured Environment

• Raw Device Configuration

• UNIX Operating System Configurations

• Database Components Created Using the Oracle Database Configuration Assistant

• Managing Undo Tablespaces

• Initialization Parameter Files

• Shared Server Configuration

• Dedicated Server Configuration

• 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

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

• Raw Device Configuration

• UNIX Operating System Configurations

• Shared Server Configuration

• Dedicated Server Configuration

• Directory Server Access (ldap.ora File)

• Net Service Names (tnsnames.ora File)

• Profile (sqlnet.ora File)

  Note: Configuration files are created on each node in your cluster.

Raw Device Configuration

The Oracle Database Configuration Assistant uses a shared raw device in UNIX environments, or a shared logical partition in Windows environments, to store Real Application Clusters database configuration information. The Oracle Universal Installer (OUI) automatically initializes the shared device by executing the srvconfig -init command. If this initialization does not complete, manually initialize the raw device by executing the srvconfig -init command.

You can also use the srvconfig command to import or export the contents of a configuration raw volume on UNIX, or the contents of a logical drive on Windows platforms, to or from a text file. You can also use srvconfig to convert a pre-Oracle9i Oracle Parallel Server dbname.conf file to a shared raw device. Refer to one of the following sections for platform-specific information on 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 point to a raw device or shared cluster file system file.

Using path_name as the complete path name for the raw device you specify, the srvConfig.loc file must contain the entry:

srvconfig_loc=path_name

The srvConfig.loc file resides in:

• The /var/opt/oracle directory on Sun Solaris

• The /etc on directory HP-UX

Executing srvconfig on Windows Platforms

When you execute the srvconfig -init command on Windows NT and Windows 2000 you must have a symbolic link named srvcfg that you created using the Object Link Manager (OLM). This symbolic link must point to the correct disk partition.

UNIX Operating System Configurations

This section describes the oratab file configuration.

oratab File on UNIX

Oracle creates an entry for the 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 it should be auto-started on reboot. 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 reboot time. A sample entry for a database named db is:

db:/private/system/db:N

Database Components Created Using the Oracle Database Configuration Assistant

This section describes the database components created by the Oracle Database Configuration Assistant (DBCA). The topics in this section include:

• Tablespaces and Datafiles

• Redo Log Files

• Control Files

Tablespaces and Datafiles

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

Table 8-1 Tablespace Names used by Oracle Real Application Clusters Databases

Tablespace Name	Contents
SYSTEM	Consists of the data dictionary, including definitions of tables, views, and stored procedures needed by the database. Information in this area is maintained automatically. The SYSTEM tablespace is present in all Oracle9i databases.
SPFILE	This is a tablespace for the binary server parameter file.
USER	Consists of application data. As you create and enter data into tables, Oracle fills this space with your data.
TEMP	Contains temporary tables and/or indexes created during SQL statement processing. You may need to expand this tablespace if you are executing a SQL statement that involves significant sorting, such as ANALYZE COMPUTE STATISTICS on a very large table, or the constructs GROUP BY, ORDER BY, or DISTINCT. Note: A future release of Oracle will limit the use of the ANALYZE statement to collect optimizer statistics.
UNDOTBS_n	These are the undo tablespaces that the Oracle Database Configuration Assistant creates for automatic undo management.
RBS	If you do not use automatic undo management, then Oracle uses the RBS tablespace for the rollback segments.
INDX	Stores indexes associated with the data in the USER tablespace.
TOOLS	Stores tables for Oracle Enterprise Manager.
DRSYS	Consists of data for Oracle9i interMedia Text.
EXAMPLE	Stores the Oracle9i Sample Schemas
CWMLITE	Stores the OLAP files.

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

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

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

Tablespaces	Windows NT and Windows 2000 Symbolic Link Names
SYSTEM	db_name_system1
SPFILE	db_name_spfile1
USERS	db_name_users1
TEMP	db_name_temp1
UNDOTBS1	db_name_undotbs1
UNDOTBS2	db_name_undotbs2
RBS (optional)	db_name_rbs1
EXAMPLE	db_name_example1
CWMLITE	db_name_cwmlite1
INDX	db_name_indx1
TOOLS	db_name_tools1
DRSYS	db_name_drsys1
Control File 1	db_name_control1
Control File 2	db_name_control2
SRVM Configuration	srvcfg

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

Redo Log Files

Each instance is configured with two redo log files that are stored on the raw devices. The redo log files' names created with the preconfigured database configuration options vary by operating system. You must enter the file names on UNIX unless you are using a cluster file system.

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 Customize database creation method, locate the redo log files in the Storage Page and set their filenames fields to the correct raw devices or symlink names.

Note: Where the notation db_name appears above and throughout this chapter, it refers to the database name you entered when prompted by the DBCA, or to the entry you made for the DATABASE keyword of the CREATE DATABASE statement.

Control Files

The database is configured with two control files that are stored on the raw devices. The control files' names created by the preconfigured database configuration options vary by operating system. UNIX prompts you to set the file names. Windows NT and Windows 2000 use symbolic link names of db_name_control1 and db_name_control2. The Customized database creation method prompts you to specify control file names or symbolic link names.

Managing Undo Tablespaces

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 Rollback Segment Undo mode.

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.

See Also: Oracle9i Real Application Clusters Administration for more information on managing undo tablespaces

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 can access this parameter file. This file is a binary file that you cannot directly modify.

To change the values of parameters in this file, use Oracle Enterprise Manager or the ALTER SYSTEM SET syntax. Although not recommended, you can also use the traditional client-side parameter files.

See Also: Chapter 6, "Configuring the Server Parameter File in Real Application Clusters Environments" for more information on the creation and use of parameter files

Shared Server Configuration

If you use the Transaction Processing preconfigured database option, Oracle configures the database for shared server. For an Customized installation, shared server is configured if 20 or more users are configured. If you use the New Database database creation type, then you have a choice of using either shared server or dedicated server.

Shared server is configured as in the following example:

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

This configuration enables connection load balancing. Connection load balancing equalizes the number of active connections among the various instances and shared server dispatchers for the same service. The (listener=listeners_db_name) setting enables an instance to register its instance load information with remote listeners on the other nodes. The TNS connect descriptor to which listeners_db_name refers should include the addresses of each listener that listens for instances of this cluster database.

Oracle resolves listeners_db_name to listener addresses through a tnsnames.ora file like the one shown in Example 8-1. In shared server configurations, a listener selects a dispatcher in the following order: 1) least loaded node, 2) least loaded instance, and 3) least loaded dispatcher for that instance.

See Also: "Net Service Names (tnsnames.ora File)" The Oracle Net Services Administrator's Guide for further information about the DISPATCHERS parameter

Dedicated Server Configuration

A dedicated server configuration requires one dedicated server process for each user process. You can implement connection load balancing in Real Application Clusters, however, the throughput and scalability of dedicated server processing is limited by the ability of the server processes to accommodate the user load.

When using dedicated server, configure connection load balancing as in the following example:

REMOTE_LISTENERS=listeners_db_name

This configuration also enables connection load balancing. Connection load balancing equalizes the number of active connections among the various instances for the same service. The REMOTE_LISTENERS setting enables an instance to register its instance load information with remote listeners on the other nodes. The TNS connect descriptor to which listeners_db_name refers should include the addresses of all listeners that listen for instances of this cluster database.

Oracle resolves listeners_db_name to listener addresses through a tnsnames.ora file like the one shown in Example 8-1. In dedicated server configurations, a listener selects an instance in the following order: 1) least loaded node, and 2) least loaded instance.

See Also: Oracle Net Services Administrator's Guide for further information about dedicated server configurations and connection load balancing

Configuring the Listener File (listener.ora)

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

• Nondefault Listeners

• Multiple Listeners

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

Nondefault Listeners

If you configured a listener that does not use the default listener address of TCP/IP port 1521, the Oracle Database Configuration Assistant automatically configures the LOCAL_LISTENER parameter in the initialization parameter file as follows, where listener_sid is resolved to a listener address through either a tnsnames.ora file on the machine, or through the Oracle Names Server:

sid.local_listener=listener_sid

Multiple Listeners

If the DBCA detects more than one listener on each node, it displays a list of the listeners. You can select one of these listeners. If you select a nondefault listener, the LOCAL_LISTENER parameter is set in the initialization parameter file, as described previously in "Nondefault Listeners".

How Oracle Uses the Listener (listener.ora File)

Services coordinate their sessions with the help of a listener, a process on the server that receives connection requests on behalf of a client application. Listeners are configured to "listen on" 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 install, 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. During a Customized installation, you are prompted to create at least one listener with the Oracle Net Configuration Assistant. The listener is configured to listen on one protocol address you specify, as well as an address for external procedures.

Note: If your platform supports a cluster file system, the default name for the listener is listener_node_name,

Both installation modes configure service information about the Real Application Clusters database and external procedures. An Oracle9i release 1 (9.0.1) 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 configuration in the listener.ora file to discover the database instance. 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 listener is started by Oracle Net Configuration Assistant. 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=/orahome81) 
      (program=extproc)

 (sid_desc=
   (oracle_home=/orahome81)
   (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=/u01/app/oracle/9.0.1)))

Note: In Real Application Clusters environments, the GLOBAL_DBNAME parameter disables connect-time failover or transparent application failover (TAF), Oracle Corporation strongly recommends against adding this parameter to your listener.ora file.

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, this is 60 seconds later.

This problem occurs when a listener is started after the Oracle instance and every time that listener fails and is restarted. To override the 60 second delay, you can use the system-level 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.

See Also: Oracle Net Services Administrator's Guide for further information about the listener and the listener.ora file

Directory Server Access (ldap.ora File)

If you configure access to an Lightweight Directory Access Protocol (LDAP)-compliant directory server with the Oracle Net Configuration Assistant during an 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: Oracle 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 and an LDAP directory (if configured during an 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:

• Network route to the service, including the location of the listener through a protocol address

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

Oracle creates net service names for the connections as shown in Table 8-3:

Table 8-3 Connections for Net Service Names

Net Service Name Type	Description
Database connections	Oracle Enterprise Manager searches for a net service name entry for the database. This entry enables Oracle Enterprise Manager to discover a Real Application Clusters database and to determine which instances to use for a connection. A listener protocol address is configured for each instance. In addition, the LOAD_BALANCE and FAILOVER options force the address to be chosen randomly. If the chosen address fails, the connection request is failed over to the next address. This way, if an instance should go down, Oracle Enterprise Manager can still connect by way of another instance. In the following example, db.us.acme.com is used by Oracle Enterprise Manager to connect to the target database, db.us.acme.com. 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))) Note: FAILOVER=ON is set by default for a list of addresses. Thus, you do not need to explicitly specify the FAILOVER_ON parameter.
Instance connections	Oracle Enterprise Manager searches for a net service name entry for each instance. This entry enables Oracle Enterprise Manager to discover the instances in the cluster. These entries are also used to start and stop instances. In the following example, db1.us.acme.com, is used by Oracle Enterprise Manager to connect to an instance named db1 on db1-server: 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	As discussed in "Shared Server Configuration", the DISPATCHERS parameter is set in the initsid.ora file with the LISTENER attribute: DISPATCHERS="(protocol=tcp)(listener=listeners_db_name)" This enables the instance to know about the remote listeners on the other nodes. listeners_db_name is then resolved through the tnsnames.ora file. In the following example, listeners_db.us.acme.com is resolved to list of listeners available in the cluster database as shown below: listeners_db.us.acme.com= (address=(protocol=tcp)(host=db1-server)(port= 1521)) (address=(protocol=tcp)(host=db2-server)(port=1521)) The instance uses this list to determine the names of the remote listeners to register its information.
Nondefault listeners	As discussed in "Nondefault Listeners" and "Multiple Listeners", the LOCAL_LISTENER parameter is set in the initsid.ora file if a nondefault listener is configured. sid.local_listener=listener_sid listener_sid is resolved to a listener address. In the sample below, listener_db1.us.acme.com is resolved to the nondefault listener address: listener_db1.us.acme.com= (address=(protocol=tcp)(host=db1-server)(port= 1421))
External procedures	An entry for connections to external procedures. This enables an Oracle9i database to connect to external procedures. 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 install:

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)))

See Also: Oracle Net Services Administrator's Guide for further information about the tnsnames.ora file

Profile (sqlnet.ora File)

The sqlnet.ora file is automatically configured with:

• Computer's domain.

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

• A naming method the server can use 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)

See Also: The Oracle Net Services Administrator's Guide for further information about the sqlnet.ora file