[Contents] [Index] [Info] [Previous]

APPENDIX D. SQL*Net Configuration for OpenVMS Clusters

This appendix describes how to configure SQL*Net for easy operation in OpenVMS Clusters/shared disk configurations.

The topics are:

Background/Advantages of OpenVMS Clusters

OpenVMS systems that share resources in a clustered configuration provide many advantages for the data center manager and user. A clustered configuration provides a useful resilience of service and can considerably reduce start-up costs through sharing peripheral resources.

In a clustered configuration, sharing resources is a prime consideration from a system management perspective. Sharing configuration files required by SQL*Net Version 2 is definitely a prime consideration. The configuration files are not initially set up to provide this common file facility, but with some simple coding and management techniques, the single directory, single file facility can be arranged.

Standard Configuration

The standard configuration has a minimum of three files in a directory, and these files are accessed via the logical name TNS_ADMIN. The three files are LISTENER.ORA, SQLNET.ORA and TNSNAMES.ORA, and they contain the following information:

Normally these files are concerned with only a single node and the default configuration is adequate. However, if a multiple node configuration is required, the directory containing the files must be duplicated on each of the nodes and has a node-specific TNS_ADMIN location set up. This overhead can be considerable for the system or network managers, because configuration changes need to be repeated many times.

The Oracle Name Server provides the centralized addressing facility required to ease the management of complex configurations. If the Oracle Name Server is not going to to be installed, changes can be made to the configuration files to ease the administration burden.

Clustered Configuration

The clustered configuration needs to overcome certain naming issues that prevent the listeners from being started on multiple nodes without introducing node-specific elements into the configuration. The changes are minor and can be greatly automated. The major problem with multiple listeners using the same file is that the logging files clash.

The second listener to be started then fails, because the file already exists and the first listener process holds it open. The solution is to configure the system so that the files do not clash. The next section, "SQL*Net Infrastructure," explains the easiest way to configure SQL*Net files so that the files do not clash.

SQL*Net Infrastructure

OpenVMS clustered systems can be configured to provide identical services with various means of "load balancing" the user community, usually by the use of LAT services that have one or more systems in them. The relative LAT and OpenVMS systems negotiate which one is least active and direct the user accordingly.

The listeners can be set up to access the same databases on a cluster-wide basis in only one of the following two ways:

The advantage of this duplicate system is that "load-balancing" can be achieved using DECnet and the OpenVMS cluster alias node facility. The steps to make the parallel/clustered access will be mentioned during the set-up details.

To configure the multiple listeners, set the LISTENER.ORA file format to allow the multiple listeners with independent logging and tracing file facilities to start.

Starting multiple listeners from the same file is more manageable if a sensible standard naming methodology can be determined first. The listeners have been named after the nodes upon which they are active. For ease of management, a DCL command file should act as an automatic listener start and stop facility to distinguish the node being acted upon and to relate this to the listener in question.

The following commands are an example associated with such a facility:

$ NODE_ID = "''F$GETSYI("NODENAME") 
$ DEFINE ORA_SID 'NODE_ID' 
$ LSNRCTL START LSNR'NODE_ID'

These commands invoke the listener process LSNR<nnnnnn>

where:

<nnnnnn> is the node name of the member of the OpenVMS Cluster.

The efficient way to submit this command procedure is to submit it to a batch queue on each of the nodes to run under the Oracle7 username.

Internally, the LISTENER.ORA file should be configured as follows: 

LSNR<nnnnnn> = (ADDRESS_LIST = 
               (ADDRESS =  
                 (PROTOCOL = DECNET) 
                 (NODE = <nnnnnn>) 
                 (OBJECT = LSNR_COMMON) 
               ) 
             ) 
STARTUP_WAIT_TIME_LSNR<nnnnnn> = 0 
CONNECT_TIMEOUT_LSNR<nnnnnn> = 10 
LSNR<mmmmmm> = (ADDRESS_LIST = 
               (ADDRESS =  
                 (PROTOCOL = DECNET) 
                 (NODE = <mmmmmm>) 
                 (OBJECT = LSNR_COMMON)  
               )      
             ) 
STARTUP_WAIT_TIME_LSNR<mmmmmm> = 0 
CONNECT_TIMEOUT_LSNR<mmmmmm> = 10 
 
SID_LIST_LSNR<nnnnnn> = 
        (SID_LIST =  
            (SID_DESC = 
              (SID_NAME = SID1)        
              (PROGRAM = DISK:[DIR]ORACLE_SID1_NETV2.COM)
            ) 
            (SID_DESC = 
             (SID_NAME = SID2) 
             (PROGRAM = 'DISK:[DIR]ORACLE_SID2_NETV2.COM')
            ) 
            (SID_DESC = 
                        . other SID information as required 
            ) 
        ) 
SID_LIST_LSNR<mmmmmm> = 
        (SID_LIST =  
            (SID_DESC = 
              (SID_NAME = SID1)        
              (PROGRAM = 'DISK:[DIR]ORACLE_SID1_NETV2.COM') 
            ) 
            (SID_DESC = 
             (SID_NAME = SID2) 
             (PROGRAM = 'DISK:[DIR]ORACLE_SID2_NETV2.COM')
            ) 
            (SID_DESC = 
                        . other SID information as required 
            ) 
        ) 
 
#LOG_LEVEL may be 0, ADMIN OR DEV
LOG_LEVEL_LSNR<nnnnnn> = 0      
LOG_DIRECTORY_LSNR<nnnnnn> = DISK:[LOG_DIR] 
LOG_FILE_LSNR<nnnnnn> = LSNR<nnnnnn> 
 
#TRACE_LEVEL may be 0, ADMIN OR DEV
TRACE_LEVEL_LSNR<nnnnnn> = 0     
TRACE_DIRECTORY_LSNR<nnnnnn> = DISK:[TRACE_DIR] 
TRACE_FILE_LSNR<nnnnnn> = LSNR<nnnnnn> 
 
LOG_LEVEL_LSNR<mmmmmm> = 0     
LOG_DIRECTORY_LSNR<mmmmmm> = DISK:[LOG_DIR] 
LOG_FILE_LSNR<mmmmmm> = LSNR<mmmmmm> 
 
TRACE_LEVEL_LSNR<mmmmmm> = 0      
TRACE_DIRECTORY_LSNR<mmmmmm> = DISK:[TRACE_DIR] 
TRACE_FILE_LSNR<mmmmmm> = LSNR<mmmmmm>

where:

<nnnnnn> and <mmmmmm> are indicators of the specific node, such as ALPHA1 and VAX1

If you are using the Transparent Gateway to Rdb, the Oracle Parallel Server, or something similar that accepts connections from any node in a cluster, the initial portion of the LISTENER.ORA can be adapted. This allows the use of the DECnet alias feature when connection is made to a OpenVMS cluster node address and the load balancing happens automatically. The format requires that the listener object be identical, because there is no guarantee through which node the user will connect. The modified file portion is: 

LSNR<nnnnnn> = (ADDRESS_LIST = 
               (ADDRESS = 
                 (PROTOCOL = DECNET) 
                 (NODE = <nnnnnn>) 
                 (OBJECT = LSNR_COMMON) <------| 
               )                               | 
             )                                 | 
STARTUP_WAIT_TIME_LSNR<nnnnnn> = 0             | 
CONNECT_TIMEOUT_LSNR<nnnnnn> = 10              | 
LSNR<mmmmmm> = (ADDRESS_LIST =                 | 
               (ADDRESS =                      | 
                 (PROTOCOL = DECNET)           | 
                 (NODE = <mmmmmm>)             | 
                 (OBJECT = LSNR_COMMON)<--Changed to 						    )					load balance  
			  )					using VAX											cluster alias

[Contents] [Index] [Info] [Previous]