Supported Configurations with Oracle Data Guard and RAC

Oracle Clinical 5.4 supports a distributed environment over a network or within an Exadata machine.

For more information, see:

Supported Configurations with Oracle Real Application Clusters (RAC)

Oracle Clinical was re-architected in Release 5.0 to support Oracle Real Application Clusters (RAC). The Parameterized Submission process (PSUB), which runs and schedules most jobs in Oracle Clinical, no longer uses DBMS pipes, which can only be used within a single database instance, for communication between the user session and the PSUB service. It now uses Oracle Advanced Queuing.

Because databases have traditionally been constrained to run only on a single server, customers have typically followed a hardware "scale-up" strategy for the database tier: Whenever the database server becomes a bottleneck to overall application performance, the server is replaced with a larger, faster machine. While this approach is well understood, it can be highly disruptive to ongoing business.

Oracle Real Application Clusters (RAC) provides an alternative approach for scaling database performance. It is designed to tolerate server failures with little impact to mission-critical applications and users. As workloads and user connections are increased, additional nodes (servers) can be easily added to the cluster. Each server runs against the same database simultaneously. This approach is less disruptive to ongoing business operations, more reliable, and less expensive to implement.

RAC nodes can be individual computers in a network or nodes on an Oracle Exadata machine. RAC shares the database internally among all nodes so that even if the node where the database was originally installed goes down, the other nodes can still access the database. You can configure RAC nodes as follows:

Node 1: Install and Set Up Everything Required for Oracle Clinical

  • Oracle Real Application Clusters (RAC)—installed with Oracle Database
  • Oracle Clinical database server code
  • Oracle Clinical database(s)
  • Run the Oracle Clinical PSUB service on this node (one per database)
  • Create user-specific PSUB log file directories for randomization, batch data load, and labs batch jobs that require input files
  • Enter PSUB-related values in local reference codelist OCL_STATE
  • Install SAS 9.4 (Optional)

Node 2: Install the Minimum Required as a RAC Node

Install Oracle Database with Oracle Real Application Clusters (RAC).

You can have multiple nodes set up this way, each accessing the same database(s). Additional nodes set up this way improve database performance.

Node 3: Install Everything Required for Oracle Clinical as Backup

In case either the PSUB service or Node 1 itself fails, install all required software on another node so that you can start the PSUB service as quickly as possible to continue normal operation. PSUB can run on only one server at a time.

A node set up this way also improves performance but requires additional maintenance; any Oracle Clinical database server patches you install on the primary node (Node 1 in this example) must also be installed on this node.

  • Install Oracle Real Application Clusters (RAC) and Oracle Database
  • Install Oracle Clinical database server code (includes PSUB server code)
  • Create the same PSUB directory structure as on Node 1 so that the OCL_STATE reference codelist values on the middle tier still work. If you use NFS to share the files, users will still be able to access files for jobs performed on the other node unless the node itself fails. For more information, see Set Up the Parametrized Submission Process.

    Note:

    You do not need to reinstall the Oracle Clinical database.

You can have multiple nodes set up this way, each accessing the same database(s).

Recommended Options for RAC

Oracle Clinical 5.4 is supported with an Oracle Real Applications Cluster (RAC) distributed database installation on UNIX. Oracle recommends:

  • Configuring a Maximum Availability Architecture (MAA) in which you use Oracle RAC for both your primary and standby database, synchronized using Oracle Data Guard.
  • Using the Single Client Access Name (SCAN) option. This RAC feature provides a single name for clients to access Oracle databases running in a cluster. The benefit is that the client's connect information does not need to change if you add or remove nodes in the cluster. Having a single name to access the cluster allows clients to use the EZConnect client and the simple JDBC thin URL to access any database running in the cluster, independent of which server(s) in the cluster the database is active. SCAN provides load balancing and failover for client connections to the database. The SCAN works as a cluster alias for databases in the cluster.
  • SCAN is configured during the installation of Oracle Grid Infrastructure that is distributed with Oracle Database. Oracle Grid Infrastructure is a single Oracle Home that contains Oracle Clusterware and Oracle Automatic Storage Management (ASM). You must install Oracle Grid Infrastructure first in order to use Oracle RAC.

Supported Configurations with Oracle Data Guard

The following Oracle Data Guard configurations are supported. All Oracle Clinical components (database server, database) must be installed on each node.

  • Standalone server with Oracle Data Guard failover
  • Oracle Clusterware for One Node with Oracle Data Guard failover
  • Oracle RAC One Node with Oracle Data Guard failover
  • Multi-node RAC with Oracle Data Guard failover

Oracle Data Guard is included in Oracle Database Enterprise Edition.