Oracle® Real Application Clusters Installation Guide 11g Release 1 (11.1) for Linux and UNIX Part Number B28264-01 |
|
|
View PDF |
This chapter describes the Oracle Real Application Clusters (Oracle RAC) installed configuration.
This chapter contains the following topics:
Database Components Created Using Database Configuration Assistant
Oracle Database Vault Default Audit Policy and Initialization Parameters
Oracle Net Configuration Assistant (NETCA) and Database Configuration Assistant (DBCA) configure your environment to meet the requirements for database creation and Oracle Enterprise Manager discovery of Oracle RAC databases.
Note:
Configuration files are created on each node in your cluster database.Avoid changing host names after you complete the Oracle RAC installation, including adding or deleting domain qualifications. Hostnames are created with Oracle Clusterware installation, and are used extensively with database processes. Nodes with changed host names must be deleted from the cluster and added back with the new name.
DBCA uses 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 disk device file. Oracle Universal Installer (OUI) automatically initializes the OCR during the Oracle Clusterware installation.
Oracle creates an entry for each Oracle RAC database in the oratab
configuration file. The oratab
file is created by the root.sh
script during installation, and it is updated by the Database Configuration Assistant when creating or deleting a database. Oracle Enterprise Manager uses this file during service discovery to determine the name of the Oracle RAC database, and to determine if the database should be started automatically when the system is restarted.
The database entry has the following syntax:
$DB_UNIQUE_NAME:$ORACLE_HOME:N
A colon, ':', is used as the field terminator. A new line terminates the entry. Lines beginning with a pound sign, '#', are comments. The $DB_UNIQUE_NAME
environment variable is the Oracle system identifier, or SID
, for your Oracle RAC database. The $DB_UNIQUE_NAME
identifier for your RAC database must be unique across your enterprise. $ORACLE_HOME
is the directory path to the database, and N
indicates that the database should not be started at restart time. The following is an example entry for a database named sales
:
sales:u01/app/oracle/sales:N
This section describes the database components that DBCA creates, which include:
For both single-instance and cluster database environments, an Oracle Database is divided into smaller logical areas of space known as tablespaces. Each tablespace corresponds to one or more data files stored on a disk. Table 7-1 shows the tablespace names used by an Oracle RAC database and the types of data they contain.
Table 7-1 Tablespace Names Used with Real Application Clusters Databases
Tablespace Name | Contents |
---|---|
Consists of the data dictionary, including definitions of tables, views, and stored procedures needed by the database. Oracle Database automatically maintains information in this tablespace. |
|
|
An auxiliary system tablespace that contains the |
Consists of application data. As you create and enter data into tables, Oracle Database 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 running a SQL statement that involves significant sorting, such as |
|
These are the undo tablespaces for each instance that DBCA creates for automatic undo management. |
|
If you do not use automatic undo management, then Oracle Database uses the |
You cannot alter these tablespace names when using the preconfigured database configuration options from OUI. 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 data files. The data file names created by the preconfigured database configuration options vary by storage type such as ASM, OFS, block or raw devices, and so on.
The database is configured with two control files that are stored on shared storage.
Each instance is configured with at least two redo log files that are stored in the shared storage. If you use a cluster file system, then these files are shared file system files. If you do not have a cluster file system, then these files are block or 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. Unless you are using a cluster file system, you must enter the block or raw device names.
When using block or 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 block or raw device names, or symbolic link names.
Oracle Database 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 Administration and Deployment Guide for more information about managing undo tablespacesOracle 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 6, " Configuring the Server Parameter File in Oracle Real Application Clusters Environments" for more information about the creation and use of parameter filesOracle Database Vault installs a baseline database auditing policy. This policy covers the access control configuration information stored in Oracle Database Vault database tables, information stored in Oracle Catalog (rollback segments, tablespaces, and so on), the use of system privileges, and Oracle Label Security configuration.
See Also:
Oracle Database Vault Administrator's Guide for more information about the database audit policyTwo key benefits of Oracle RAC are connection load balancing and failover.
Oracle 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.
Oracle RAC provides failover by configuring multiple listeners on multiple nodes to manage client connection requests for the same database service. With Oracle RAC, if a node or interconnect fails, then the associated virtual IP address (VIP) is relocated to a surviving node, enabling fast notification of the failure to the clients connecting through that VIP. If the application and client are configured with transparent application failover options, then the client is reconnected to the surviving node.
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 Oracle RAC occurs when an instance's process monitor (PMON) 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 Database changes the setting for REMOTE_LISTENER
dynamically when you reconfigure your cluster database; for example, when you add or delete instances.
By default, DBCA configures your environment with dedicated servers. However, if you select the Shared server option when using DBCA, then Oracle configures the shared server. In this case, Oracle Database 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)"
Note:
Where the notationdb_name
appears in the previous example and throughout this chapter, it refers to the database name (or Oracle SID) that you entered when prompted by DBCA, or it refers to the entry you made for the DATABASE
keyword of the CREATE DATABASE
statement.See Also:
Oracle Database Net Services Administrator's Guide for further information about cross-instance registration, shared and dedicated server configurations, and connection load balancingYou can configure two types of listeners in the listener.ora
file as described in the following sections:
If you configured the 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))
If 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.
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. This process is either a dedicated process, or a shared server process, depending on your selection during database configuration. 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, Oracle Net Configuration Assistant creates and starts a default listener called LISTENER_
NODENAME
. The listener is configured with default protocol listening addresses for the database. The advanced installation process prompts you to create at least one listener with Oracle Net Configuration Assistant. The listener is configured to respond to connection requests that are directed to one protocol address you specify.
Both installation modes configure service information about the Oracle RAC database. An Oracle Database 11g release 1 (11.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, Oracle Net Configuration Assistant starts the listener. The following is an example listener.ora
file with an entry for a node named node1
:
LISTENER_NODE1= (DESCRIPTION_LIST = (DESCRIPTION= (ADDRESS = (PROTOCOL = TCP)(HOST = node1-vip)(PORT = 1521)(IP = FIRST)) (ADDRESS = (PROTOCOL = TCP)(HOST = 140.87.25.116)(PORT = 1521)(IP = FIRST))) SID_LIST_LISTENER_NODE1= (SID_LIST= (SID_DESC= (SID_NAME=) (ORACLE_HOME=/u01/app/oracle/11/db_1)
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 Oracle Database process monitor (PMON) discovery routine starts. By default, PMON discovery occurs every 60 seconds.
To override the 60-second delay, use the SQL ALTER SYSTEM REGISTER
statement. This statement forces the PMON process to register the service immediately.
Oracle recommends that you create a script to run this statement immediately after starting the listener. If you run 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 Database Net Services Administrator's Guide for further information about the listener and thelistener.ora
fileA 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 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 releases previous to Oracle8
Note:
TheSERVICE_NAME
parameter you use in the tnsnames.ora
file is singular, because you can specify only one service name.DBCA creates net service names for connections as shown in Table 7-2.
Table 7-2 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 an Oracle RAC database. A listener address is configured for each node that runs an instance of the database. The In the following example, db.example.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.example.com))) Note: When you set mydatabase.example.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.example.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, Oracle Enterprise Manager uses db1.example.com= (description= (address=(protocol=tcp)(host=node1-vip)(port=1521)) (connect_data= (service_name=db.example.com) (instance_name=db1))) |
Remote listeners |
As discussed in "Configuring Service Registration-Related Parameters", the Whether using shared servers or dedicated servers, the list of remote listeners is supplied using the REMOTE_LISTENER=listeners_db_unique_name
This enables the instance to register with remote listeners on the other nodes; In the following example, listeners_db.example.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", if a nondefault listener is configured, then the sid.local_listener=listener_sid The variable In the following example, listener_db1.example.com= (address=(protocol=tcp)(host=node1-vip)(port=1522)) |
Services Entries |
When you configure high availability services using the DBCA Services page, then DBCA creates net service entries similar to the following. The three services in the following examples, db_svc1.example.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.example.com) ) ) db_svc2.example.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.example.com) (failover_mode = (type=select) (method=basic) (retries=180) (delay=5) ) ) ) db_svc3.example.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.example.com) (failover_mode= (backup=db_svc3_preconnect.example.com) (type=select) (method=preconnect) (retries=180) (delay=5) ) ) ) |
Services Entries (continued) |
When a service has a TAF policy of db_svc3_preconnect.example.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.example.com) (failover_mode = (backup = db_svc3.example.com) (type = select) (method = basic) (retries = 180) (delay = 5) ) ) ) |
Example 7-1 Example tnsnames.ora File
This example is a sample tnsnames.ora
file that is created during a preconfigured database configuration installation.
db.example.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.example.com))) db1.example.com= (description= (address=(protocol=tcp)(host=node1-vip)(port=1521)) (connect_data= (service_name=db.example.com) (instance_name=db1))) db2.example.com= (description= (address=(protocol=tcp)(host=node2-vip)(port=1521)) (connect_data= (service_name=db.example.com) (instance_name=db2))) listeners_db.example.com= (address_list= (address=(protocol=tcp)(host=node1-vip)(port=1521)) (address=(protocol=tcp)(host=node2-vip)(port=1521)))
See Also:
Oracle Database Net Services Administrator's Guide for further information about thetnsnames.ora
fileOracle Universal Installer starts Oracle Net Configuration Assistant after the database is installed, and creates the Net Services profile, or sqlnet.ora
file.
By default, the sqlnet.ora
file is located in the following directory:
$ORACLE_HOME/network/admin
In this directory, in addition to the default sqlnet.ora
file generated during installation, you also can find a sample sqlnet.ora
file in the directory sample
.
During installation, Oracle Net Configuration Assistant creates the following entries in the sqlnet.ora
file:
NAMES.DIRECTORY_PATH=(TNSNAMES, EZCONNECT)
The parameter NAMES.DIRECTORY_PATH
specifies the priority order of the naming methods to use to resolve connect identifiers to connect descriptors.
The order of naming methods is as follows: directory naming (for Custom Install or Advanced database configuration options only), tnsnames.ora
file, Easy Connect, and host naming.
The Easy Connect naming method eliminates the need for service name lookup in the tnsnames.ora
files for TCP/IP environments. With Easy Connect, clients use a connect string for a simple TCP/IP address, consisting of a host name and optional port and service name. If you use this method, then no naming or directory system is required.
See Also:
Oracle Database Net Services Administrator's Guide for further information about thesqlnet.ora
file