7 Understanding the Oracle Real Application Clusters Installed Configuration

7.4.1 Tablespaces and Data files

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 on the shared storage. Table 7-1 shows the tablespace names used by an Oracle RAC database and the types of data they contain.

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 Oracle ASM, or a file system.

7.4.2 Control Files

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

7.4.3 Redo Log Files

Each instance is configured with at least two redo log files that are stored in the shared storage. If you use a file system, then these files are shared file system files. If you use Oracle ASM, then these files are stored on the Oracle 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.

7.8.1 Understanding Single Client Access Name (SCAN) and Load-balancing

The Single Client Access Name (SCAN) is a fully qualified name (hostname+domain) that is configured to resolve to all the addresses allocated for the SCAN. The addresses resolve using Round Robin DNS either on the DNS server, or within the cluster in a GNS configuration. SCAN listeners can run on any node in the cluster.

Oracle Database 11g release 2 and later instances only register with SCAN listeners as remote listeners. Upgraded databases register with SCAN listeners as remote listeners, and also continue to register with all node listeners.

SCANs run on the cluster, not on a cluster node. SCANs provide location independence for the databases, so that client configuration does not have to depend on which nodes are running a particular database. For example, if you configure policy managed server pools in a cluster, then the SCAN enables connections to databases in these server pools regardless of which nodes are allocated to the server pool.

SCANs function like a node virtual IP (VIP) address. However, SCANs are resolved to SCAN VIPs that run on any node in the cluster, so unlike a virtual IP address for a node, clients connecting to the SCAN no longer require updated virtual IP addresses as nodes are added to or removed from the cluster. Because the SCAN addresses resolve to the cluster, rather than to a node address in the cluster, nodes can be added to or removed from the cluster without affecting the SCAN address configuration.

During Oracle Grid Infrastructure installation, SCAN listeners are created for as many IP addresses as there are addresses assigned to resolve to the SCAN. Oracle recommends that the SCAN resolves to three addresses, to provide high availability and scalability. If the SCAN resolves to three addresses, then there are three SCAN listeners created.

Oracle RAC provides failover with the node VIP addresses by configuring multiple listeners on multiple nodes to manage client connection requests for the same database service. If a node fails, then the service connecting to the VIP is relocated transparently to a surviving node, enabling fast notification of the failure to the clients connecting through the VIP. If the application and client are configured with transparent application failover options, then the client is reconnected to the surviving node. Oracle Clusterware routes client application requests from the SCAN to the VIP on the least loaded instance providing the service.

Clients configured to use IP addresses for Oracle Database releases prior to Oracle Database 11g release 2 can continue to use their existing connection addresses; using SCANs is not required. When an earlier version of Oracle Database is upgraded, it registers with the SCAN listeners, and clients can start using the SCAN to connect to that database. The database registers with the SCAN listener through the remote listener parameter in the init.ora file. The REMOTE_LISTENER parameter must be set to SCAN:PORT. Do not set it to a TNSNAMES alias with a single address with the SCAN as HOST=SCAN.

7.8.2 Understanding Load-Balancing, Failover, and High Availability

Connection load balancing and failover increase availability by taking advantage of the redundant resources within a cluster database.

The Database Agent (previously known as racgimon) configures the LOCAL_LISTENER initialization parameters automatically. You do not need to alter this setting. Set the REMOTE_LISTENER to the SCAN port and SCAN using the SQL command ALTER SYSTEM SET REMOTE_LISTENER. If you change the SCAN port, then you need to change the REMOTE_LISTENER configuration.

The LOCAL_LISTENER parameter identifies the local listener, and the REMOTE_LISTENER parameter identifies the global list of listeners. The REMOTE_LISTENER parameter is always set to the SCAN address. For example, if the name of the cluster is mycluster, and the domain is example.com, then the SCAN address will be similar to myscan.mycluster.example.com:1521.

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

7.9.1 Grid Naming Service (GNS) and Listeners

If you enable Grid Naming Service (GNS), then you do not have to manually configure the listener. In GNS configurations, there is one GNS daemon for the cluster. Service requests to the cluster domain that GNS manages are routed to the GNS virtual IP address, which routes these requests to the GNS daemon.

The GNS daemon listens for registrations. When a SCAN virtual IP starts, it registers its addresses with GNS. When GNS receives a request from a DNS for the SCAN, it returns the registered addresses to the DNS.

7.9.2 About Local Listeners

During Oracle Database creation, the LOCAL_LISTENER parameter is automatically configured to point to the local listener for the database. The Database Agent sets the LOCAL_LISTENER parameter to a connect descriptor that does not require a TNS alias.

You can set a value manually for LOCAL_LISTENER. However, Oracle recommends that you leave the parameter unset so that the Database Agent can maintain it automatically.

For example, after you create the database, if you need to add a second listener, listening on port 2012, then use the following command to have the database register with both listeners on startup:

> alter system set local_listener='(DESCRIPTION=
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.61)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.61)(PORT=2012))))' 
scope=BOTH SID='OCRL1';

The tnsnames.ora file is located in the path $ORACLE_HOME/network/admin. By default, the tnsnames.ora file is read from the Oracle Grid Infrastructure home, in the path Grid_home/network/admin.

The listener association no longer requires tnsnames.ora file entries. The REMOTE_LISTENER is configured by DBCA to reference the SCAN name and port, without any need for a tnsnames.ora entry.

The following is an example of an Oracle RAC 11g release 2 (11.2) tnsnames.ora file:

# tnsnames.ora Network Configuration file:
/u01/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
# Generated by Oracle Configuration tools
RACDB =
   (DESCRIPTION = 
     (ADDRESS = (PROTOCOL = TCP)(HOST = myscan.mycluster.example.com)(PORT = 1521)
)
     (CONNECT_DATA =
       (SERVER = DEDICATED)
       (SERVICE_NAME = RACDB)
      )
    )

7.9.3 About Multiple Listeners

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

7.9.4 How Oracle Database Uses the Listener File (listener.ora)

Services coordinate their sessions by registering their load with the Local Listener and the SCAN Listeners. Clients are redirected by the SCAN Listener to a local listener on the least loaded node that is running the instance for a particular service. That Listener either redirects the client to a Dispatcher process (if the database was configured for Shared Server), or redirects the client to a dedicated server process. Local Listeners are configured to respond to database connection requests, and to non-database connection requests, such as external procedures or XDB requests.

The Listener agent dynamically updates endpoints with the listener. With the Oracle Database 11g release 2 installation, the listener.ora file now only contains an IPC key and the following information:

(ADDRESS = (PROTOCOL=TCP)(HOST=)(PORT=1521))

This information refers implicitly to the local node's HOST endpoint. The listener.ora file is the same on every node.

Before you install Oracle RAC, during the Oracle Grid Infrastructure installation, Oracle Net Configuration Assistant creates and starts a default listener in the Grid home called LISTENER. The listener is configured with default protocol listening addresses. The listener is configured to respond to connection requests that are directed to one protocol address specified during installation.

During Oracle RAC installation, the Oracle RAC database uses the Oracle Clusterware listener, and configures service information about the Oracle RAC database. An Oracle Database 11g release 2 (11.2) 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.

After installation, you can modify listeners by using srvctl commands, or by using NetCA. Manual editing of the listener.ora file is not required.

The following is an example listener.ora file with an entry for a node named node1:

LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_
SCAN1))))               # line added by Agent
LISTENER_NODE1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC) (KEY=LISTENER))))
          # line added by Agent
# listener.ora.mycluster Network Configuration File:
/u01/app/oracle/11.2.0/dbhome_1/network/admin/listener.ora.mycluster
# Generated by Oracle configuration tools.
 
LISTENER_NODE1 =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )
 
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_NODE1=ON              # line added by Agent
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN2=ON              # line added by Agent
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN1=ON              # line added by Agen

7.10.1 Net Service Names for Database Connections

Clients that connect to any instance of the database use the SCAN name for the database. This entry also enables Oracle Enterprise Manager to discover an Oracle RAC database.

Three SCAN addresses are configured for the cluster, and allocated to servers. If the chosen address fails, then the connection request to the SCAN name fails over to the next address. Thus, if an instance fails, then clients can still connect using another instance.

In the following example, myscan.mycluster.example.com is used by the client to connect to the target database, mycluster.example.com.

mycluster.example.com =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = host=myscan.mycluster.example.com)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = myApp)
    )
  

An Easy Connect address for this database should be similar to the following:

myscan.mycluster.example.com/mycluster.example.com

7.10.2 Net Service Name Instance Connections

Clients that connect to a particular instance of the database use the SCAN name 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 myscan.mycluster.example.com to connect to an instance named mycluster1 on node1:

mycluster1.example.com=
 (description= 
  (address=(protocol=tcp)(host=myscan.mycluster.example.com)(port=1521))
  (connect_data= 
    (service_name=mycluster.example.com)
    (instance_name=mycluster1)))

7.10.3 tnsnames.ora Example File

This example is a sample tnsnames.ora file that is created during a preconfigured database configuration installation.

# tnsnames.ora Network Configuration File: /u01/app/oracle/11.2.0/dbhome_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.
 
sales =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = myscan.mycluster.example.com)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = myApp)
    )