Oracle9i Real Application Clusters Setup and Configuration Release 2 (9.2) Part Number A96600-01 |
|
This chapter describes the installed configuration for Real Application Clusters. The topics in this chapter include:
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.
Note: Configuration files are created on each node in your cluster database. |
The Database Configuration Assistant uses a shared configuration file for storing the configuration 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 UNIX environments you can also use srvconfig
to convert a pre-Oracle9i Oracle Parallel Server dbname.conf
file to the shared configuration file. Refer to one of the following sections for platform-specific information on the srvconfig
command:
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.
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.
This section describes the oratab
file configuration.
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 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
This section describes the database components created by the Database Configuration Assistant (DBCA). The topics in this section include:
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 tablespace names used by a Real Application Clusters database and the types of data they contain:
Tablespace Name | Contents |
---|---|
|
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 |
|
Consists of application data. As you create and enter data into tables, Oracle fills this space with your data. |
|
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 Note: A future release of Oracle will limit the use of the |
|
These are the undo tablespaces for each instance that the Database Configuration Assistant creates for automatic undo management. |
|
If you do not use automatic undo management, then Oracle uses the RBS tablespace for the rollback segments. |
|
Stores indexes associated with the data in the |
|
Stores tables for Oracle Enterprise Manager. |
|
Consists of data for Oracle9i interMedia Text. |
|
Stores the Oracle9i Sample Schemas |
|
Stores the OLAP files. |
XML |
To accommodate XML features. |
ODM |
To accommodate Oracle Data Mining features. |
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 or more datafiles. 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:
You can specify different symbolic names with the Customized database configuration option.
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' 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 to be the correct raw device names or symbolic link names.
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.
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 rbs
thread_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 |
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. 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. 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 |
Two of the 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 within a cluster database. In addition, Real Application Clusters provides failover by configuring multiple listeners on multiple instances 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-node registration.
Cross-node registration in Real Application Clusters occurs when an instance's PMON process not only registers with the local listener, but when it also registers with all other listeners. Thus, all instances in the cluster register with all listeners in the cluster. This enables all listeners to manage connections across all instances for both load balancing and failover.
Cross-node registration requires configuration of 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 of the instance. Both of these parameters are dynamic initialization parameters. Oracle commonly changes the setting for REMOTE_LISTENER
dynamically when you reconfigure your cluster, for example, when you add or delete nodes.
By default, the DBCA only configures 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 DISPATCHER
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, then the PMON registers dispatcher information with the listeners specified by the LISTENER
attribute. In this case, setting the LISTENER
attribute overrides the settings for LOCAL_LISTENER
and REMOTE_LISTENER
for the specified dispatchers as in the following example:
DISPATCHERS="(protocol=tcp)(listener=listeners_
db_name)"
See Also:
Oracle9i Net Services Administrator's Guide for further information about cross-node registration, shared and dedicated server configurations, and connection load balancing |
You can configure two types of listeners in the listener.ora file as described under the following headings:
If you configured a listener that does not use the default listener address of TCP/IP port 1521
, then the 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
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, then the LOCAL_LISTENER
parameter is set in the initialization parameter file, as described previously in "Nondefault Listeners".
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 |
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 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=/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
)))
Note: In Real Application Clusters environments, the |
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:
Oracle9i Net Services Administrator's Guide for further information about the listener and the |
If you configure access to an 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:
See Also:
Oracle9i Net Services Administrator's Guide for further information about directory naming configuration and directory server access configuration |
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:
SERVICE_NAME
for an Oracle release 8.1 or later, or sid for pre-8.1 Oracle releases
The Database Configuration Assistant creates net service names for the connections as shown in Table 8-3:
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 Real Application Clusters database. A listener address is configured for each node that runs an instance of the database. The In the following example, db.us.acme.com= (description= (load_balance=on) Note: |
Instance connections |
Clients that connect to any instance of the database use the Net Service Name entry for the database. 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= (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 "Configuring Service Registration-Related Parameters in Real Application Clusters", the Whether using shared servers or dedicated servers, the list of remote listeners is supplied using the REMOTE_LISTENERS=listeners_<dbname> This enables the instance connect to remote listeners on the other nodes, and In the following example, listeners_db.us.acme.com= The instance uses this list to determine the addresses of the remote listeners with which to register its information. |
Nondefault listeners |
As discussed in "Nondefault Listeners" and "Multiple Listeners", the sid.local_listener=listener_sid
In the following sample,
listener_db1.us.acme.com=
|
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))) |
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:
Oracle9i Net Services Administrator's Guide for further information about the |
The sqlnet.ora file is automatically configured with:
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
.
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 Oracle9i Net Services Administrator's Guide for further information about the |
|
Copyright © 1998, 2002 Oracle Corporation. All Rights Reserved. |
|