When you use the interactive method to install Oracle Database Gateway, Oracle Universal Installer displays a series of screens that enable you to specify all of the required information.

By creating a response file and specifying this file when you start Oracle Universal Installer, you can automate some or all of the Oracle Database Gateway installation. These automated installation methods are useful if you need to perform multiple installations on similarly configured systems or if the system where you want to install the software does not have X Window system software installed.

When you use a response file, you can run Oracle Universal Installer in the following modes, depending on whether you specify all of the required information or not:

• Silent Mode

  Oracle Universal Installer runs in silent mode if you use a response file that specifies all required information. None of the Oracle Universal Installer screens are displayed.

• Suppressed Mode

  Oracle Universal Installer runs in suppressed mode if you do not specify all required information in the response file. Oracle Universal Installer displays only the screens that prompt for the information that you did not specify.

For more information about these modes and about how to complete an installation using response files, refer to Using Response Files for Noninteractive Installation.

Read the release notes for the product before installing it. The release notes are available on the Oracle Database 12c Release 2 (12.2) installation media. The latest version of the release notes is also available on the Oracle Technology Network (OTN) Web site:

http://docs.oracle.com

The platform-specific hardware and software requirements included in this installation guide were current at the time this guide was published. However, because new platforms and operating system software versions might be certified after this guide is published, review the certification matrix on the My Oracle Support Web site for the most up-to-date list of certified hardware platforms and operating system versions. The My Oracle Support Web site is available at the following Web site:

https://support.oracle.com/

This product supports multiple Oracle homes. This means that you can install this release or previous releases of the software more than once on the same system, in different Oracle home directories.

1. Create a directory to hold the Oracle Database Gateway software:

   $ mkdir gateway
   

2. Change directory to the directory you created in step 1:

   $ cd gateway
   

3. Copy the contents to the new directory as follows:

   $ cp -R /directory_path gateway
   

   In this example, /directory_path is the installation media mount point directory. The mount point directory is /cdrom.

Oracle Database 11g Release 2 and higher clients connect to the database using Support for Single Client Access Name (SCAN). It provides a single name to the clients connecting to Oracle RAC that does not change throughout the life of the cluster, even if you add or remove nodes from the cluster. Clients connecting with SCAN can use a simple connection string, such as a thin JDBC URL or EZConnect, and achieve load balancing and client connection failover.

In addition to the three SCAN listeners (one per virtual IP address), there is a node listener on every node hosting a database instance. The purpose of using two layers of listeners (SCAN listeners and node listeners) is to separate the two functions of listeners in an Oracle RAC, firstly to load balance connections and secondly to spawn-and-bequeath sessions. The SCAN listeners will receive connection requests from clients, randomly distributed by the GNS (Grid Naming Services). The SCAN listener will then use load balancing metrics to redirect the request intelligently to the node listener on the node best able to offer the requested service. Database instances register with the SCAN listeners as remote listeners, and with the node listeners as local listeners.

Oracle Database Gateway can not be configured with SCAN, a single name for Database to connect to the gateway. There are two reasons for this. Gateway does not work with remote listeners. Unlike Database where you can specify REMOTE_LISTENER to set to the SCAN listener, there is no support for it in gateways. This is essential for SCAN listener to route the connection to the node listener. Secondly, the gateway does not register with the cluster for it to be managed as a cluster resource.

For gateway, SCAN is not very useful when the Oracle Database and Oracle Database Gateway are running on the same cluster. Oracle Database Gateway can be installed and configured on each node where database is installed, and database can be configured such that each instance connect to the Gateway running on the same node.

Oracle Database Gateway service should be configured using the local listener. It is the local listener that spawns the gateway process. That means listener should know which gateway process to spawn. Use the listener.ora in Grid infrastructure home to add the Gateway SID. If a SCAN listener for Database is already running on that node, you can use the same listener.ora file to configure the local listener.

Oracle Database Gateway itself does not support either the client-side (using tnsnames in database home) or server-side (using SCAN) load balancing. Load balancing at the Gateway level is not applicable because the Gateway process is currently dedicated to a single session. However, by associating a different Oracle Database Gateway instance for each database instance, you can achieve node level load balancing, that is, selecting a least loaded node happens through load balancing on the database.

Oracle Database Gateway supports connection failover feature. If you configure client-side connection load balancing for Gateway, it works similar to failover.

Whenever database fail over happens, that is, session migrates from one database instance to other database instance (on a new node), the migrated session will use the gateway instance from that new node.

Three types of Oracle Net failover functionality are available by default to Oracle Call Interface (OCI) applications:

• session: Set to failover the session. If a user connection is lost, then a new session is automatically created for the user on the backup. This type of failover does not attempt to recover select operations.

• select: Set to enable users with open cursors to continue fetching on them after failure. However, this mode involves overhead on the client side in normal select operations.

• none: This is the default. No failover functionality is used. This can also be explicitly specified to prevent failover from happening.

For failover to work, tnsnames.ora in Database home need to be configured with multiple listener addresses.

If the instance fails after the connection, then the TAF application fails over to the other node's listener, reserving any SELECT statements in progress.

In the following example of tnsnames.ora for load balancing that only works as failover, the database connects to the gateway on host gateway2-server only if the gateway on gateway1-server is not available:

dg4sybs.us.example.com=
 (DESCRIPTION=
  (LOAD_BALANCE=on) 
  (FAILOVER=on) 
  (ADDRESS=
       (PROTOCOL=tcp)  
       (HOST=gateway1-server)  
       (PORT=1521)) 
  (ADDRESS=
       (PROTOCOL=tcp)  
       (HOST=gateway2-server)  
       (PORT=1521)) 
  (CONNECT_DATA=
     (SERVICE_NAME=dg4sybs.us.example.com) (HS=OK)
     (FAILOVER_MODE=
       (TYPE=select) 
       (METHOD=basic))))