15 Application-Specific Deployment Topics

This chapter discusses topics for deploying online (OLTP), data warehouse, and general purpose (hybrid) applications in Oracle Real Application Clusters (Oracle RAC) environments. The topics in this chapter are:

General Deployment Strategies for Oracle Real Application Clusters-Based Applications
Deploying OLTP Applications in Oracle Real Application Clusters
Deploying Data Warehouse Applications with Oracle Real Application Clusters
Data Security Considerations in Oracle Real Application Clusters

General Deployment Strategies for Oracle Real Application Clusters-Based Applications

All single-instance application development and deployment techniques apply to Oracle RAC. If your applications run well on a single-instance Oracle database, then they will run well on an Oracle RAC database.

Deploying OLTP Applications in Oracle Real Application Clusters

Cache Fusion makes Oracle RAC databases the optimal deployment servers for online transaction processing (OLTP) applications. This is because these types of applications require:

High availability in the event of failures
Scalability to accommodate increased system demands
Load balancing according to demand fluctuations

The high availability features of Oracle and Oracle RAC can re-distribute and load balance workloads to surviving instances without interrupting processing. Oracle RAC also provides excellent scalability so that if you add or replace a node, then Oracle re-masters resources and re-distributes processing loads.

Flexible Implementation with Cache Fusion

To accommodate the frequently changing workloads of online transaction processing systems, Oracle RAC remains flexible and dynamic despite changes in system load and system availability. Oracle RAC addresses a wide range of service levels that, for example, fluctuate due to:

Varying user demands
Peak scalability issues like trading storms (bursts of high volumes of transactions)
Varying availability of system resources

Deploying Data Warehouse Applications with Oracle Real Application Clusters

This section discusses how to deploy data warehouse systems in Oracle RAC environments by briefly describing the data warehouse features available in shared disk architectures. The topics in this section are:

Speed-Up for Data Warehouse Applications on Oracle Real Application Clusters
Parallel Execution in Data Warehouse Systems and Oracle RAC
Using Parallel Instance Groups

Speed-Up for Data Warehouse Applications on Oracle Real Application Clusters

Oracle RAC is ideal for data warehouse applications because it augments the single instance benefits of Oracle. Oracle RAC does this by maximizing the processing available on all of the nodes that belong to an Oracle RAC database to provide speed-up for data warehouse systems.

The query optimizer considers parallel execution when determining the optimal execution plans. The default cost model for the query optimizer is CPU+I/O and the cost unit is time. In Oracle RAC, the query optimizer dynamically computes intelligent defaults for parallelism based on the number of processors in the nodes of the cluster. An evaluation of the costs of alternative access paths, table scans versus indexed access, for example, takes into account the degree of parallelism (DOP) available for the operation. This results in Oracle selecting the execution plans that are optimized for your Oracle RAC configuration.

Parallel Execution in Data Warehouse Systems and Oracle RAC

Oracle's parallel execution feature uses multiple processes to run SQL statements on one or more CPUs. Parallel execution is available on both single-instance Oracle databases and Oracle RAC databases.

Oracle RAC takes full advantage of parallel execution by distributing parallel processing across all available instances. The number of processes that can participate in parallel operations depends on the DOP assigned to each table or index.

Using Parallel Instance Groups

You can control the instances that allocate parallel execution server processes with instance groups. To do this, assign each active instance to at least one or more instance groups. Then dynamically control which instances spawn parallel processes by activating a particular group of instances.

Note:

An instance can belong to one or more groups. You can enter several instance group names with the INSTANCE_GROUPS parameter using a comma as a separator.

Data Security Considerations in Oracle Real Application Clusters

This section describes the following two Oracle RAC security considerations:

Transparent Data Encryption and Wallets
Windows Firewall Considerations

Transparent Data Encryption and Wallets

Wallets used by Oracle RAC instances for Transparent Database Encryption may be a local copy of a common wallet shared by multiple nodes or a shared copy residing on a network file system that all of the nodes can access. A deployment with a single wallet on a shared disk requires no additional configuration to use Transparent Data Encryption. Deployments where no shared storage exists require that each Oracle RAC node maintain its own local wallet. Details about creating and provisioning a wallet can be found in the Database Security Guide.

After you create and provision a wallet a single node, you must copy the wallet and make it available to all of the other nodes. For systems using Transparent Data Encryption with encrypted wallets, you can use any standard file transport protocol. For systems using Transparent Data Encryption with obfuscated wallets, file transport through a secured channel is recommended. The wallet must reside in the directory specified by the setting for the WALLET_LOCATION or ENCRYPTION_WALLET_LOCATION parameter in sqlnet.ora. The local copies of the wallet need not be synchronized for the duration of Transparent Data Encryption usage until the server key is re-keyed though the ALTER SYSTEM SET KEY SQL statement. Each time you run the ALTER SYSTEM SET KEY statement at a database instance, you must again copy the wallet residing on that node and make it available to all of the other nodes. To avoid unnecessary administrative overhead, reserve re-keying for exceptional cases where you are certain that the server master key is compromised and that not re-keying it would cause a serious security problem.

Windows Firewall Considerations

By default, all installations of Windows Server 2003 Service Pack 1 and higher enable the Windows Firewall to block virtually all TCP network ports to incoming connections. As a result, any Oracle products that listen for incoming connections on a TCP port will not receive any of those connection requests, and the clients making those connections will report errors.

Depending upon which Oracle products you install and how they are used, you may need to perform additional Windows post-installation configuration tasks so that the Firewall products are functional on Windows Server 2003.

This section contains these topics:

Oracle Executables Requiring Firewall Exceptions
Configuring the Windows Firewall
Troubleshooting Windows Firewall Exceptions

Oracle Executables Requiring Firewall Exceptions

Table 15-1 lists the Oracle Database 10g Release 1 (10.1) or later executables that listen on TCP ports on Windows. If they are in use and accepting connections from a remote client computer, then Oracle recommends that you add them to the Windows Firewall exceptions list to ensure correct operation. Except as noted, they can be found in ORACLE_HOME\bin.

The RMI registry application and daemon executable listed in Table 15-1 are used by Oracle Ultra Search to launch a remote crawler. They must be added to the Windows Firewall exception list if you are using the Ultra Search remote crawler feature, and if the remote crawler is running on a computer with the Windows Firewall enabled.

Note:

If multiple Oracle homes are in use, then several firewall exceptions may be needed for the same executable: one for each home from which that executable loads.

Table 15-1 Oracle Executables Requiring Windows Firewall Exceptions

File Name	Executable Name
`CRS_HOME\bin\crsd.exe`	OracleCRService
`CRS_HOME\bin\evmd.exe`	OracleEVMService
`CRS_HOME\bin\evmlogger.exe`	Event manager logging daemon
`CRS_HOME\bin\GuiOracleObjManager.exe`	Oracle Object Link Manager (GUI version)
`CRS_HOME\bin\ocssd.exe`	OracleCSService
`CRS_HOME\bin\OracleObjManager.exe`	Oracle Object Link Manager (CLI version)
`CRS_HOME\bin\racgvip.exe`	Virtual Internet Protocol Configuration Assistant
`CRS_HOME\cfs\Ocfsfindvol.exe`	Oracle Cluster Volume Service
`dgmgrl.exe`	Data Guard Manager
`emagent.exe`	Oracle Database Control
`extproc.exe`	External Procedures
`hdodbc.exe`	Generic Connectivity
`oidldapd.exe`	Oracle Internet Directory LDAP Server
`omtsreco.exe`	Oracle Services for Microsoft Transaction Server
`oracle.exe`	Oracle Database
`ORACLE_HOME\apache\apache\apache.exe`	Apache Web Server
`ORACLE_HOME\bin\emagent.exe`	Enterprise Manager Agent
`ORACLE_HOME\bin\omtsreco.exe`	Oracle services for Microsoft Transaction Server
`ORACLE_HOME\bin\ORACLE.EXE`	Oracle
`ORACLE_HOME\bin\racgimon.exe`	RACG
`ORACLE_HOME\bin\TNSLSNR.exe`	Oracle Listener
`ORACLE_HOME\jdk\bin\java.exe`	Java Virtual Machine
`ORACLE_HOME\jdk\bin\rmid.exe`	RMI daemon executable
`ORACLE_HOME\jdk\bin\rmiregistry.exe`	RMI registry application
`ORACLE_HOME\jdk\jre\bin\rmiregistry.exe`	RMI registry application
`ORACLE_HOME\opmn\bin\ons.exe`	Oracle Notification Service
`ORACLE_HOME\opmn\bin\opmn.exe`	Oracle Process Manager
`pg4arv.exe`	Oracle Procedural Gateway for APPC
`pg4mqc.exe`	Oracle Procedural Gateway for Websphere MQ
`pg4mqs.exe`	Oracle Procedural Gateway for Websphere MQ
`pg4t4ic.exe`	Oracle Procedural Gateway for APPC
`tg4drsrv.exe`	Oracle Transparent Gateway for DRDA
`tg4msql.exe`	Oracle Transparent Gateway for MS-SQL Server
`tg4sybs.exe`	Oracle Transparent Gateway for SYBASE
`tg4tera.exe`	Oracle Transparent Gateway for Teradata
`tnslsnr.exe`	Oracle TNS Listener
`WINDOWS_HOME\system32\drivers\Ocfs.sys`	System file for Oracle Cluster File System

Configuring the Windows Firewall

Post-installation configuration for the Windows Firewall must be undertaken if all of the following conditions are met:

Oracle server-side components are installed.

These components include the Oracle Database, network listeners, and any Web servers or services.
The computer services connections from other computers over a network.

If no other computers connect to the computer with the Oracle software, then no post-installation configuration steps are required and the Oracle software will function as expected.
The Windows Firewall is enabled.

If the Windows Firewall is not enabled, then no post-installation configuration steps are required.

You can configure Windows Firewall by opening specific static TCP ports in the firewall or by creating exceptions for specific executables so that they are able to receive connection requests on any ports they choose. To configure the firewall, choose Control Panel > Windows Firewall > Exceptions or enter netsh firewall add... at the command line.

Alternatively, Windows will inform you if a foreground application is attempting to listen on a port, and it will ask you if you wish to create an exception for that executable. If you choose to do so, then the effect is the same as creating an exception for the executable either in the Control Panel or from the command line.

Troubleshooting Windows Firewall Exceptions

If you cannot establish certain connections even after granting exceptions to the executables listed in Table 15-1, then follow these steps to troubleshoot the installation:

Examine Oracle configuration files (such as *.conf files), the Oracle key in the Windows registry, and network configuration files in ORACLE_HOME\network\admin.
Pay particular attention to any executable listed in ORACLE_HOME\network\admin\listener.ora in a PROGRAM= clause. Each of these must be granted an exception in the Windows Firewall, because a connection can be made through the TNS Listener to that executable.
Examine Oracle trace files, log files, and other sources of diagnostic information for details on failed connection attempts. Log and trace files on the database client computer may contain useful error codes or troubleshooting information for failed connection attempts. The Windows Firewall log file on the server may contain useful information as well.
If the preceding troubleshooting steps do not resolve a specific configuration issue on Windows XP Service Pack 2, then provide the output from command netsh firewall show state verbose=enable to Oracle Support for diagnosis and problem resolution.