7 Understanding the Oracle Real Application Clusters Installed Configuration

7.4.1 Tablespaces and Data Files

In 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 if you select a preconfigured database templates, or database configuration type when installing Oracle RAC. However, you can change the names of the tablespaces if you select the Advanced database configuration type during the Oracle RAC installation. See "Selecting an Oracle Database Configuration Type" for more information about database configuration types.

As mentioned, each tablespace has one or more data files. The data file names created by the preconfigured database configuration types vary by storage type such as Oracle Automatic Storage Management (Oracle ASM), or a file system.

Windows platforms use symbolic link names for the data files and other database files as shown in Table 7-2. You can specify different symbolic link names when you select the Advanced database configuration type during installation.

7.4.2 Control Files

The database is configured with two control files that must be stored on shared storage. Every database must has one unique control file; any additional control files configured for the database are identical copies of the original control file.

If a control file becomes unusable, then the database instance fails when it attempts to access the damaged control file. By multiplexing (creating multiple copies of) a control file on different disks, the database can achieve redundancy and thereby avoid a single point of failure.

7.4.3 Online Redo Log Files

Each database instance must have at least two online redo log files. The online redo log files for a database instance are called the redo thread. Each Oracle RAC database instance has its own redo thread to avoid contention for a single set of online redo log files. In case of instance failure, the online redo log files must be accessible by the surviving instances. Therefore, the online redo log files for an Oracle RAC database must be placed on shared storage or Oracle ASM. If you use a file system for storage, then the file system must be a shared or cluster file system.

The generated file names created by the preconfigured database configuration types for the online redo log files can vary depending on the type of storage used. Unless you are using a cluster file system or Oracle ASM, during installation or database creation, you must specify a raw device name for the storage location of each online redo log file.

7.8.1 Database Services for an Oracle RAC Database

Each database is represented by one or more services. A service is identified by a service name, for example, sales.example.com. A client uses a service name to identify the database it must access. The information about the database service and its location in the network is transparent to the client.

The information needed to use a service name to create a database connection is stored in a repository, which is represented by one or more naming methods. A naming method is a resolution method used by a client application to resolve a connect identifier (such as the service name) to a connect descriptor when attempting to connect to a database service. Oracle Net Services offers several types of naming methods that support localized configuration on each client, or centralized configuration that can be accessed by all clients in the network.

An Oracle Database 11g release 2 (11.2) database service automatically registers with the listeners specified in the LOCAL_LISTENER and REMOTE_LISTENER parameters. During registration, PMON sends information such as the service name, instance names, and workload information to the listeners. This feature is called service registration

Services coordinate their sessions by registering their workload, or the amount of work they are currently handling, 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. This feature is called load balancing. The local listener either directs the client to a dispatcher process (if the database was configured for shared server), or directs the client to a dedicated server process.

When a listener starts after the Oracle instance starts, and the listener is available for service registration, registration does not occur until the next time the Oracle Database process monitor (PMON) starts its discovery routine. By default, the PMON discovery routine is started every 60 seconds. To override the 60-second delay, use the SQL statement ALTER SYSTEM REGISTER. This statement forces PMON to register the service immediately.

7.8.2 Configuring the Listener Configuration File (listener.ora)

You can configure Oracle Net Services and listeners as described in the following sections:

• Grid Naming Service and Listeners

• Local Listeners

• Configuring Multiple Listeners for Your Database Using DBCA

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

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

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:
C:\app\oracle\product\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 Agent

7.8.3 Net Service Names (tnsnames.ora File)

A tnsnames.ora file is created on each node and acts as a repository of net service names. Each net service name is associated with a connect identifier. A connect identifier is an identifier that maps a user-defined name 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 parameter, with the value set to the name of a database service

  Note:

  The SERVICE_NAME parameter you use in the tnsnames.ora file is singular, because you can specify only one service name. There is also the service_names parameter in the database initialization file. The service_names database parameter defaults to the global database name, a name comprising the db_name and db_domain parameters in the initialization parameter file.

#  tnsnames.ora Network Configuration File:
C:\app\grid\11.2.0\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)
    )
  )

The tnsnames.ora file is located in both the Grid_home\network\admin and Oracle_home\network\admin directories. By default, the tnsnames.ora file is read from the Grid home when Oracle Grid Infrastructure is installed.

RACDB =
   (DESCRIPTION = 
     (ADDRESS = (PROTOCOL = TCP)(HOST=myscan.mycluster.example.com)(PORT=1521))
     (CONNECT_DATA =
       (SERVER = DEDICATED)
       (SERVICE_NAME = RACDB)
      )
    )

With Oracle Clusterware 11g release 2 and later, the listener association no longer requires tnsnames.ora file entries. The listener associations are configured as follows:

• DBCA no longer sets the LOCAL_LISTENER parameter. The Oracle Clusterware agent that starts the database sets the LOCAL_LISTENER parameter dynamically, and it sets it to the actual value, not an alias. So listener_alias entries are no longer needed in the tnsnames.ora file.

• The REMOTE_LISTENER parameters is configured by DBCA to reference the SCAN and SCAN port, without any need for a tnsnames.ora entry. Oracle Clusterware uses the Easy Connect naming method with scanname:scanport, so no listener associations for the REMOTE_LISTENER parameter are needed in the tnsnames.ora file.

DBCA creates net service names for connections as described in the following sections:

• Net Service Names for Database Connections

• Net Service Name for Instance Connections

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

username/@myscan.mycluster.example.com:1521/RACDB.example.com

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.8.4 Net Services Profile (sqlnet.ora File)

OUI starts NETCA after the database is created. NETCA creates the Oracle Net Services profile, or the sqlnet.ora file. In an Oracle Grid Infrastructure installation, the sqlnet.ora file is located in the following directory by default:

Grid_home\network\admin

In the %ORACLE_HOME%\network\admin directory, in addition to a default sqlnet.ora file, you also can find a sample sqlnet.ora file in the subdirectory sample.

During installation, NETCA creates the following entries in the sqlnet.ora file, where %ORACLE_BASE% is the path to the Oracle base directory for the Oracle RAC installation:

SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH=(TNSNAMES, EZCONNECT)
ADR_BASE =%ORACLE_BASE%

The AUTHENTICATION_SERVICES parameter specifies the method by which users are authenticated for database access. The value NTS indicates that Microsoft Windows native operating system authentication should be used to authorize access to the database. The parameter NAMES.DIRECTORY_PATH specifies the priority order of the naming methods to use to resolve connect identifiers to connect descriptors. The ADR_BASE parameter specifies the base directory into which tracing and logging incidents are stored when Automatic Diagnostic Repository (ADR) is enabled for the database.

The Easy Connect naming method eliminates the need to lookup service names 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 Example 7-5, "Connecting to Oracle RAC Using the Easy Connect Naming Method" for an example.

7.9.1 Understanding SCAN

SCAN is a fully qualified name (host name.domain name) that is configured to resolve to all the addresses allocated for the SCAN listeners. The default value for SCAN is cluster_name.GNS_sub_domain, or, cluster_name-scan.domain_name if GNS is not used. For example, in a cluster that does not use GNS, if your cluster name is salesRAC, and your domain is example.com, then the default SCAN address is salesRAC-scan.example.com:1521.

SCAN is configured in DNS to resolve to three IP addresses, and DNS should return the addresses using a round-robin algorithm. This means that when SCAN is resolved by DNS, the IP addresses are returned to the client in a different order each time.

SCAN provides location independence for the databases, so that the client configuration does not have to include the address of each node that hosts a particular database or database instance. For example, if you configure policy-managed server pools for a cluster, then SCAN enables connections to databases in these server pools regardless of which nodes are allocated to the server pool.

During the installation of Oracle Grid Infrastructure, several Oracle Clusterware resources are created for SCAN:

• A SCAN VIP is created for each IP address that SCAN resolves to

• A SCAN listener is created for each SCAN VIP

• A dependency on the SCAN VIP is configured for the SCAN listener

SCAN VIPs function like node VIPs, except that SCAN VIPs can run on any node in the cluster. Also, if you have three SCAN VIPs but only two nodes in your cluster, you can have two SCAN VIPs running on the same server. Clients (users or applications) that connect using SCAN instead of the node VIPs do not have to update the list of VIP addresses in their local tnsnames.ora file when nodes are added to or removed from the cluster.

7.9.2 Understanding SCAN Listeners and Listener Registration

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.

The addresses for the SCAN listeners resolve with either the domain name service (DNS), or within the cluster for the Grid Naming Service (GNS), using a round-robin method. SCAN listeners can run on any node in the cluster.

The database parameter LOCAL_LISTENER specifies the listening endpoint of the local database listener, and the database parameter REMOTE_LISTENER parameter identifies the SCAN listeners. The database registers with the local and SCAN listeners by using the connect description information contained in these parameters. 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.

Starting with Oracle Database 11g release 2, the REMOTE_LISTENER parameter is always set to the SCAN address. Do not set it to an Oracle Net alias that has a single address that uses SCAN for the host name (HOST=scan). For example, if SCAN for the cluster is myscan, and the GNS subdomain for the cluster is mycluster.example.com, then the REMOTE_LISTENER parameter has the following value:

myscan.mycluster.example.com:1521

The Database Agent process (previously known as racgimon) configures the LOCAL_LISTENER initialization parameter automatically for Oracle RAC databases by specifying a connect descriptor for the node VIP address of the local node. You do not have to alter this setting. The REMOTE_LISTENER parameter should be set to the SCAN and SCAN port. If you change the SCAN port, then you must change the value for the REMOTE_LISTENER parameter using the SQL statement ALTER SYSTEM SET REMOTE_LISTENER.

7.9.3 Understanding Failover, Load Balancing, and SCAN

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.

Clients configured to use VIP addresses for Oracle RAC releases prior to Oracle Database 11g release 2 can continue to use their existing connection addresses; using SCAN is not required. When an earlier release of Oracle Database is upgraded, it registers with the SCAN listeners, and clients can start using SCAN to connect to that database.

There are two types of load balancing that you can implement for an Oracle RAC database: client-side and server-side load balancing. Client-side load balancing balances the connection requests across the listeners. With server-side load balancing, the SCAN listener directs a connection request to the best instance currently providing the service by using the load balancing advisory.

Based on the environment, the following actions occur when you use SCAN to connect to an Oracle RAC database using a service name. The numbered actions correspond to the arrows shown in Figure 7-1.

1. The PMON process of each instance registers the database services with the default listener on the local node and with each SCAN listener, which is specified by the REMOTE_LISTENER database parameter. The listeners are dynamically updated on the amount of work being handled by the instances and dispatchers.

2. The client issues a database connection request using a connect descriptor of the form:

   orausr/@scan_name:1521/sales.example.com
   

   Note:

   If you use the Easy Connect naming method, then ensure the sqlnet.ora file on the client contains EZCONNECT in the list of naming methods specified by the NAMES.DIRECTORY_PATH parameter.

3. The client uses DNS to resolve scan_name. After DNS returns the three addresses assigned to SCAN, the client sends a connect request to the first IP address. If the connect request fails, then the client attempts to connect using the next IP address.

4. When the connect request is successful, the client connects to a SCAN listener for the cluster which hosts the sales database. The SCAN listener compares the workload of the instances sales1 and sales2 and the workload of the nodes on which they are running. Because node2 is less loaded than node1, the SCAN listener selects node2 and sends the address for the listener on that node back to the client.

5. The client connects to the local listener on node2. The local listener starts a dedicated server process for the connection to the database.

6. The client connects directly to the dedicated server process on node2 and accesses the sales2 database instance.

Figure 7-1 Load Balancing Actions for Oracle RAC Connections That Use SCAN

Description of "Figure 7-1 Load Balancing Actions for Oracle RAC Connections That Use SCAN"

7.9.4 Understanding Shared Server Use in an Oracle RAC Database

By default, DBCA configures your Oracle RAC database with dedicated servers, not shared servers. However, if you select the shared server option when using DBCA, then DBCA configures shared servers. Oracle RAC uses both dedicated and shared server processing when shared servers are configured.