Skip Headers
Oracle® Real Application Clusters Installation and Configuration Guide
10g Release 1 (10.1) for AIX-Based Systems, Apple Mac OS X, hp HP-UX, hp Tru64 UNIX, Linux, Solaris Operating System, and Windows Platforms
Part No. B10766-08
  Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

15 Understanding the Real Application Clusters Installed Configuration

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

Understanding the Configured Environment in Real Application Clusters

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


Note:

Configuration files are created on each node in your cluster database.

The Oracle Cluster Registry in Real Application Clusters

The Database Configuration Assistant uses the Oracle Cluster Registry (OCR) for storing the configurations for the cluster databases that it creates. The OCR 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-based systems, or a shared logical partition in Windows environments. The Oracle Universal Installer (OUI) automatically initializes the OCR during the CRS installation.

UNIX oratab Configurations for Real Application Clusters

Oracle creates an entry for each RAC database in the oratab configuration file. Oracle Enterprise Manager uses this file during service discovery to determine the name of the RAC database as well whether the database should be automatically started upon restart. The database entry has the following syntax:

db_unique_name:$ORACLE_HOME:N

where db_unique_name is the database name for your RAC 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


Note:

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

Database Components Created Using the Database Configuration Assistant

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

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 15-1 shows the tablespace names used by a RAC database and the types of data they contain:

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

Tablespace Name Contents
SYSTEM Consists of the data dictionary, including definitions of tables, views, and stored procedures needed by the database. Oracle automatically maintains information in this tablespace.
SYSAUX An auxiliary system tablespace that contains the DRSYS (contains data for OracleText), CWMLITE (contains the OLAP schemas), XDB (for XML features), ODM (for Oracle Data Mining), TOOLS (contains Enterprise Manager tables), INDEX, EXAMPLE, and OEM-REPO tablespaces.
USERS Consists of application data. As you create and enter data into tables, Oracle fills this space with your data.
TEMP Contains temporary tables and 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.
UNDOTBSn These are the undo tablespaces for each instance that the DBCA creates for automatic undo management.
RBS If you do not use automatic undo management, then Oracle uses the RBS tablespace for the rollback segments.

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 advanced 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 and storage type such as ASM, OFS, raw devices, and so on. UNIX-based systems, for example, prompt you to set the file names. Windows-based platforms use the symbolic link names for the datafile and other database files shown in Table 15-2:

Table 15-2 Windows-Based Platforms Symbolic Link Names and Files

Windows-Based Platforms Symbolic Link Names Tablespace or Other Database Files
db_name_system SYSTEM
db_name_SYSAUX SYSAUX
db_name_users USERS
db_name_temp TEMP
db_name_undotbs1 UNDOTBS1
db_name_undotbs2 UNDOTBS2
db_name_rbs RBS (optional)
db_name_example EXAMPLE
db_name_indx INDX
db_name_spfile SPFILE
db_name_control1 Control File 1
db_name_control2 Control File 2
db_name_redo_instance_number log_number

Where instance_number is the number of the instance and log_number is the log number (1 or 2) for the instance.

Redo Log Files

Each instance must have at least two redo log files. If the database name is db, then the link names for the first instance are:

db_redo1_1
db_redo1_2

The link names for the second instance's redo log files are:

db_redo2_1
db_redo2_2

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

Control Files

The database is configured with two control files that are stored on shared storage.

Redo Log Files

Each instance is configured with at least two redo log files that are stored in the shared storage. If you chose cluster file system, then these files are shared file system files. If you do not have a cluster file system, then these files are raw devices. If you use ASM, then these files are stored on the ASM disk group.

The file names of the redo log files that are created with the preconfigured database configuration options vary by storage type. You must enter the raw device names unless you are using a cluster file system.

When using raw devices, to use the advanced 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 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.


See Also:

Oracle Real Application Clusters Administrator's Guide for more information about managing undo tablespaces

Initialization Parameter Files

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


See Also:

Chapter 14, " Configuring the Server Parameter File in Real Application Clusters Environments" for more information about the creation and use of parameter files

Configuring Service Registration-Related Parameters in Real Application Clusters

Two key benefits of RAC are connection load balancing and failover. RAC 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, RAC 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 RAC 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 that run on nodes that run instances of the cluster database. 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. 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)"


See Also:

Oracle Net Services Administrator's Guide for further information about cross instance registration, shared and 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:

Local Listeners

If you configured dedicated server mode using the DBCA Connection Mode tab on the Initialization Parameters page, then DBCA automatically configures the LOCAL_LISTENER parameter when the listener uses a nondefault address port.

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 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-vip)(port=1522))

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_NODENAME. The listener is configured with a default protocol listening addresses for the database and external procedures. The advanced installation process 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 RAC database and external procedures. An Oracle Database 10g Release 1 (10.1) database service automatically registers its information with the listener, such as its service name, instance names, and load information.

This feature, called service registration, does not require configuration in the listener.ora file. After listener creation, the Oracle Net Configuration Assistant starts the listener. A sample listener.ora file with an entry for an instance named node1 is:

listener_node1= 
  (description= 
    (address=(protocol=ipc)(key=extproc))
    (address=(protocol=tcp)(host=node1-vip)(port=1521))
    (address=(protocol=tcp)(host=node1-ip)(port=1521)))
sid_list_listener_node1= 
  (sid_list= 
    (sid_desc= 
      (sid_name=plsextproc) 
      (oracle_home=/private/system/db) 
      (program=extproc)

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 ALTER SYSTEM REGISTER statement. This statement forces PMON to register the service immediately.

Oracle 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 a Lightweight Directory Access Protocol (LDAP)-compliant directory server with the Oracle Net Configuration Assistant during a Custom Install or Advanced database configuration, an ldap.ora file is created. The ldap.ora file contains the following types of information:

Net Service Names (tnsnames.ora File)

A tnsnames.ora file is created on each node with net service names. A connect identifier is an identifier that maps to a connect descriptor. A connect descriptor contains the following information:

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

Table 15-3 Connections for Net Service Names

Net Service Name Type Description
Database connections Clients that connect to any instance of the database use the net service name entry for the database. This entry also enables Oracle Enterprise Manager to discover a RAC database.

A listener address is configured for each node that runs an instance of the database. The LOAD_BALANCE option causes Oracle to choose the address randomly. If the chosen address fails, then the FAILOVER option causes the connection request to fail over to the next address. Thus, if an instance fails, then clients can still connect using another instance.

In the following example, db.us.oracle.com is used by the client to connect to the target database, db.us.oracle.com.

db.us.acme.com= 
 (description= 
  (load_balance=on)
   (address=(protocol=tcp)(host=node1-vip)(port=1521)
   (address=(protocol=tcp)(host=node2-vip)(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.

When you set DB_UNIQUE_NAME by entering a global database name that is longer than eight characters, excluding DB_DOMAIN, then a net service entry similar to the following is created:

mydatabase.us.acme.com=
  (description =
     (address = (protocol = tcp)(host = node1-vip)(port = 1521))
     (address = (protocol = tcp)(host = node2-vip)(port = 1521))
  (load_balance = yes)
     (connect_data =
   (server = dedicated)
   (service_name = mydatabase.us.acme.com)
   )
   )
Instance connections Clients that connect to a particular instance of the database use the net service name entry for the instance. This entry, for example, 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=node1-vip)(port=1521))
  (connect_data= 
    (service_name=db.us.acme.com)
    (instance_name=db1)))
Remote listeners As discussed in "Configuring Service Registration-Related Parameters in Real Application Clusters", the REMOTE_LISTENER parameter identifies the global list of listeners and it is dynamic. Oracle changes the setting for REMOTE_LISTENER when you reconfigure your cluster database.

Whether using shared servers or dedicated servers, the list of remote listeners is supplied using the REMOTE_LISTENERS parameter, for example:

REMOTE_LISTENERS=listeners_db_unique_name

This enables the instance to register with remote listeners on the other nodes; listeners_db_unique_name is resolved through a naming method such as a tnsnames.ora file.

In the following example, listeners_db.us.acme.com is resolved to a list of listeners available on the nodes on which the cluster database has instances:

listeners_db.us.acme.com= 
(address_list=
   (address=(protocol=tcp)(host=node1-vip)(port=1521))
   (address=(protocol=tcp)(host=node2-vip)(port=1521)))

The instance uses this list to determine the addresses of the remote listeners with which to register its information.

Nondefault listeners As discussed in "Local Listeners" and "Multiple Listeners", the LOCAL_LISTENER parameter is set in the initsid.ora file if a nondefault listener is configured, for example:
sid.local_listener=listener_sid

Where listener_sid is resolved to a listener address through a naming method such as a tnsnames.ora file.

In the following sample, listener_db1.us.acme.com is resolved to the nondefault listener address:

listener_db1.us.acme.com= 
   (address=(protocol=tcp)(host=node1-vip)(port=1522))
Services Entries When you configure high availability services using the DBCA Services page, then the DBCA creates net service entries similar to the following. The three services in the following examples, db_svc1, db_svc2, and db_svc3, have TAF policies of NONE, BASIC and PRECONNECT respectively.
db_svc1.us.acme.com= 
  (description = 
    (address=(protocol=tcp)(host=node1-vip)(port=1521)) 
    (address=(protocol=tcp)(host=node2-vip)(port=1521))
    (load_balance=yes) 
    (connect_data=
        (server = dedicated) 
        (service_name = db_svc1.us.acme.com) 
  )
  )

db_svc2.us.acme.com= 
  (description=
    (address=(protocol=tcp)(host=node1-vip)(port=1521)) 
    (address=(protocol=tcp)(host=node2-vip)(port=1521)) 
    (load_balance=yes) 
    (connect_data =
        (server = dedicated)
        (service_name=db_svc2.us.acme.com)
        (failover_mode =
        (type=select)
        (method=basic)
           (retries=180)
           (delay=5)
     )
     )
     )

db_svc3.us.acme.com=
    (description=
      (address=(protocol=tcp)(host=node1-vip)(port=1521))
      (address=(protocol=tcp)(host=node2-vip)(port=1521))
      (load_balance=yes)
      (connect_data=
        (server=dedicated)
        (service_name=db_svc3.us.acme.com)
        (failover_mode=
        (backup=db_svc3_preconnect.us.acme.com)
        (type=select)
        (method=preconnect)
        (retries=180)
        (delay=5)
   )
   )
   )

Services Entries (continued) When a service has a TAF policy of PRECONNECT, then a service_name_preconnect net service entry is also created as in the following example:
db_svc3_preconnect.us.acme.com =
  (description =
    (address = (protocol = tcp)(host = node1-vip)(port = 1521))
    (address = (protocol = tcp)(host = node2-vip)(port = 1521))
    (load_balance = yes)
    (connect_data =
      (server = dedicated)
      (service_name = db_svc3_preconnect.us.amce.com)
      (failover_mode =
        (backup = db_svc3.us.acme.com)
        (type = select)
        (method = basic)
        (retries = 180)
        (delay = 5)
      )
    )
  )
External procedures An entry for connections to external procedures. This enables an Oracle Database 10g 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 15-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)
   (address=(protocol=tcp)(host=node1-vip)(port=1521))
   (address=(protocol=tcp)(host=node2-vip)(port=1521))
  (connect_data=
     (service_name=db.us.acme.com)))

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

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

listeners_db.us.acme.com= 
(address_list=
   (address=(protocol=tcp)(host=node1-vip)(port=1521))
   (address=(protocol=tcp)(host=node2-vip)(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:

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