| Oracle® Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide 10g Release 2 (10.2) Part Number B14197-03 |
|
|
View PDF |
| Oracle® Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide 10g Release 2 (10.2) Part Number B14197-03 |
|
|
View PDF |
This chapter discusses topics for deploying online (OLTP), data warehouse, and general purpose (hybrid) applications in Oracle Real Application Clusters (RAC) environments. The topics in this chapter are:
General Deployment Strategies for Real Application Clusters-Based Applications
Deploying Data Warehouse Applications with Real Application Clusters
All single-instance application development and deployment techniques apply to RAC. If your applications run well on a single-instance Oracle database, then they will run well on a RAC database.
Cache Fusion makes 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 RAC can re-distribute and load balance workloads to surviving instances without interrupting processing. RAC also provides excellent scalability so that if you add or replace a node, then Oracle re-masters resources and re-distributes processing loads.
To accommodate the frequently changing workloads of online transaction processing systems, RAC remains flexible and dynamic despite changes in system load and system availability. 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
This section discusses how to deploy data warehouse systems in RAC environments by briefly describing the data warehouse features available in shared disk architectures. The topics in this section are:
RAC is ideal for data warehouse applications because it augments the single instance benefits of Oracle. RAC does this by maximizing the processing available on all of the nodes that belong to a 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 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 RAC configuration.
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 RAC databases.
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.
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 theINSTANCE_GROUPS parameter using a comma as a separator. |
This section describes the following two RAC security considerations:
Wallets used by 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 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.
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:
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 |
|---|---|
|
|
OracleCRService |
|
|
OracleEVMService |
|
|
Event manager logging daemon |
|
|
Oracle Object Link Manager (GUI version) |
|
|
OracleCSService |
|
|
Oracle Object Link Manager (CLI version) |
|
|
Virtual Internet Protocol Configuration Assistant |
|
|
Oracle Cluster Volume Service |
|
|
Data Guard Manager |
|
|
Oracle Database Control |
|
|
External Procedures |
|
|
Generic Connectivity |
|
|
Oracle Internet Directory LDAP Server |
|
|
Oracle Services for Microsoft Transaction Server |
|
|
Oracle Database |
|
|
Apache Web Server |
|
|
Enterprise Manager Agent |
|
|
Oracle services for Microsoft Transaction Server |
|
|
Oracle |
|
|
RACG |
|
|
Oracle Listener |
|
|
Java Virtual Machine |
|
|
RMI daemon executable |
|
|
RMI registry application |
|
|
RMI registry application |
|
|
Oracle Notification Service |
|
|
Oracle Process Manager |
|
|
Oracle Procedural Gateway for APPC |
|
|
Oracle Procedural Gateway for Websphere MQ |
|
|
Oracle Procedural Gateway for Websphere MQ |
|
|
Oracle Procedural Gateway for APPC |
|
|
Oracle Transparent Gateway for DRDA |
|
|
Oracle Transparent Gateway for MS-SQL Server |
|
|
Oracle Transparent Gateway for SYBASE |
|
|
Oracle Transparent Gateway for Teradata |
|
|
Oracle TNS Listener |
|
|
System file for Oracle Cluster File System |
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.
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.
|
See Also:
|
