7 Understanding the Oracle RAC Installed Configuration

7.6.1 Tablespaces and Data files

For both single-instance and cluster database environments, 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-2 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 option 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 on shared file systems. The data file names created by the preconfigured database configuration options vary by storage type such as Oracle ASM, or a cluster file system.

7.6.2 Control Files

The database is configured with two control files that must be stored on shared storage. Every database must have 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.6.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 file names of the redo log files that are created with the preconfigured database configuration option vary by storage type.

7.9.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, such as sales.example.com. A client uses a service name to identify the database it must access. During installation, Oracle RAC databases are configured with a default database service that has the same name as the database. This service can be used for performing database management tasks. Additional services should be created for client and application connections to the database.

A service name can be associated with multiple database instances, and an instance can be associated with multiple services. The listener acts as a mediator between the client and database instances and routes the connection request to the appropriate instance. Clients connecting to a service do not have to specify which instance they want to connect to.

7.9.2 Naming Methods and Connect Descriptors

Each net service name is associated with a connect descriptor. A connect descriptor provides the location of the database and the name of the database service. A connect descriptor is comprised of one or more protocol addresses of the listener and the connect information for the destination service.

The information needed to use a service name to create a database connection can be 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 service name to a connect descriptor. 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.

7.9.3 Easy Connect Naming Method

The Easy Connect naming method eliminates the need to look up service names in the tnsnames.ora file or other repository for TCP/IP environments. With Easy Connect, clients use a connect string for a simple TCP/IP address, which consists of a host name, and an optional port and service name. If you use this method, then no naming or directory system is required. See Example 7-1, "Connecting to Oracle RAC Using the Easy Connect Naming Method" for an example.

Networking elements for the Oracle Database server and clients are preconfigured for most environments. The Easy Connect naming method is enabled by default and does not require a repository. If you use a naming method other than Easy Connect, then additional configuration of Oracle Net Services may be required.

7.9.4 Understanding SCANs

This section contains the following topics:

• About the SCAN

• SCAN VIP Addresses

• SCAN Listeners

7.9.5 How to Connect to an Oracle RAC Database Using SCANs

Oracle recommends that you configure Oracle RAC database clients to use the SCAN and the Easy Connect naming method to connect to the database instead of configuring the tnsnames.ora file.

Clients configured to connect to the cluster using node VIP addresses for Oracle RAC releases earlier than Oracle Database 11g Release 2 can continue to use their existing connection addresses; using the SCAN is not required. When an earlier release of Oracle Database is upgraded, the database is not only registered with the local listeners, but is also registered with the SCAN listeners, allowing clients to start using the SCAN to connect to that database.

sqlplus system/manager@sales1-scan.mycluster.example.com:1521/oltp

If the SCAN is resolved by DNS, then DNS returns all three SCAN VIP addresses in round-robin order to the client. If the SCAN is resolved by GNS, then DNS zone delegation sends the lookup request to GNS, which then returns all three SCAN VIP addresses in round-robin order to the client.

The client then uses one of the returned SCAN VIP addresses to contact a SCAN listener. When a SCAN listener receives a connection request from a client, the SCAN listener identifies the least loaded instance in the cluster that provides the requested service. It then redirects the connection request to the local listener on the node where the least loaded instance is running, and the client is given the local listener address. The local listener then creates the connection to the database instance.

7.9.6 Listener Configuration for an Oracle RAC Database

An Oracle database receives connection requests through the local listener. The local listener brokers a client request, handing off the request to the server. The listener is configured with a protocol address, and clients configured with the same protocol address can send connection requests to the listener. When a connection is established, the client and Oracle database communicate directly with one another.

The local listener, or default listener, is located in the Grid home when you have Oracle Grid Infrastructure installed. Local listeners are configured to respond to database connection requests, and to non-database connection requests, such as external procedures or Oracle XML Database (XDB) requests. When the database starts, the Database Agent process (oraagent, previously known as racgimon) sets the LOCAL_LISTENER parameter to a connect descriptor that does not require an Oracle Net service name. The value for LOCAL_LISTENER is computed to be the endpoints of the Grid home listeners.

You can configure multiple Oracle Database listeners, each with a unique name, in one listener.ora file. Multiple listener configurations for database listeners are possible because each of the top-level configuration parameters has a suffix of the listener name or is the listener name itself. To configure a database to register with multiple local listeners, you must manually modify the LOCAL_LISTENER parameter.

For an Oracle RAC database, the database parameter REMOTE_LISTENER 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.

The REMOTE_LISTENER parameter for an Oracle RAC database is always set to the SCAN address. For example, if the 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

7.9.7 Service Registration for an Oracle RAC Database

An Oracle Database 12c Release 1 (12.1) database service automatically registers with the listeners specified in the database initialization parameters LOCAL_LISTENER and REMOTE_LISTENER. During registration, the listener registration (LREG) process sends information such as the service name, instance names, and workload information to the listeners. This feature is called service registration.

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 LREG process starts its discovery routine. By default, the LREG discovery routine is started every 60 seconds. To override the 60-second delay, use the SQL statement ALTER SYSTEM REGISTER. This statement forces LREG to register the service immediately.

7.9.8 How Database Connections are Created When Using SCANs

Based on the environment, the following actions occur when you use a 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 LREG 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/webapp
   

   Note:

   If you use the Easy Connect naming method, then ensure that 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 the 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 that hosts the sales database and has an instance offering the webapp service, which in this example is sales1 and sales2. The SCAN listener compares the workload of the instances sales1 and sales2 and the workload of the nodes on which they run. If the SCAN listener determines that node2 is less loaded than node1, then the SCAN listener selects node2 and sends the address for the local 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.10.1 Load Balancing of Connections to Oracle RAC Databases

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 you configured the database to use shared servers), or directs the client to a dedicated server process.

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.

7.10.2 Connection Failover for Oracle RAC Databases

When a client issues a connection request using SCAN, the three SCAN addresses are returned to the client. If the first address fails, then the connection request to the SCAN fails over to the next address. Using multiple addresses allows a client to connect to an instance of the database even if the initial instance has failed.

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.

7.10.3 Shared Server Configuration for an Oracle RAC Database

Standalone Oracle databases perform load balancing by distributing connections among the shared server dispatcher processes. 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.

7.11.1 Database Initialization Parameters for Database Service Registration

An Oracle Database 12c Release 1 (12.1) database service automatically registers with the listeners specified in the LOCAL_LISTENER and REMOTE_LISTENER parameters. During registration, the listener registration (LREG) process sends information such as the service name, instance names, and workload information to the listeners.

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 LREG process starts its discovery routine. By default, the LREG discovery routine is started every 60 seconds. To override the 60-second delay, use the SQL statement ALTER SYSTEM REGISTER. This statement forces LREG to register the service immediately.

7.11.2 Net Service Names and the tnsnames.ora File

The installation process creates a tnsnames.ora file on each node. This file 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 that you use in the tnsnames.ora file is singular, because you can specify only one service name. The SERVICE_NAME parameter is not the same as the service_names database initialization parameter. 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. When you add service names using SRVCTL or Oracle Enterprise Manager Cloud Control, it lists additional cluster-managed services for the database.

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.

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 parameter 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.

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

SQL> 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';

7.11.3 Net Service Names Created by DBCA

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

• Net Service Names for Database Connections

• Net Service Names 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)
    )
  )

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.11.4 Listener Configuration and the listener.ora File

In Oracle RAC environments, Oracle recommends that you let the Oracle Agent manage Oracle listeners for Oracle Databases. The following sections describe Oracle Net listener configuration:

• Local Listener for an Oracle RAC Database

• Remote Listeners for an Oracle RAC Database

• Managing Multiple Listeners for an Oracle RAC Database

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

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/product/12.1.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.11.5 Net Services Profile File (sqlnet.ora)

Oracle Universal Installer starts Oracle Net Configuration Assistant (NETCA) after the database software is installed. 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

For the local listener for the Oracle RAC database instance, the default location of the sqlnet.ora file is $ORACLE_HOME/network/admin directory. In this directory there is a default sqlnet.ora file. Also, you can find a sample sqlnet.ora file in the subdirectory sample.

During installation of the Oracle RAC software, NETCA creates the following entry in the sqlnet.ora file, where $ORACLE_BASE is the path to the Oracle base directory for the Oracle RAC installation:

NAMES.DIRECTORY_PATH=(TNSNAMES, EZCONNECT)
ADR_BASE =$ORACLE_BASE

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.