Design and Deployment Techniques

Learn about methods to design and deploy Oracle RAC.

This chapter briefly describes database design and deployment techniques for Oracle Real Application Clusters (Oracle RAC) environments. It also describes considerations for high availability and provides general guidelines for various Oracle RAC deployments.

Deploying Oracle RAC for High Availability

Oracle RAC supports high availability by allowing applications to continue operating across multiple database instances, but the entire application infrastructure—including authentication, networking, storage, and operational processes—must be designed without single points of failure. Effective deployments define service-level objectives, recovery times, and failover expectations; validate them through functional, performance, and destructive testing; and apply Oracle Maximum Availability Architecture practices. Recommended measures include VIP-based connectivity, workload management services, resilient voting disks and OCR, tuned recovery, Oracle ASM, strong change control, infrastructure redundancy, Enterprise Manager administration, RMAN protection, and appropriate sequence and index strategies. RAC also supports consolidation through shared ASM storage, cluster-managed services, capacity policies, and Global Data Services, while enabling online scalability by adding instances or servers without outages.

General Design Considerations for Oracle RAC

Oracle RAC application design should proceed through application, memory and I/O, contention, and operating-system tuning, because RAC cannot compensate for an application that fails to scale on a symmetric multiprocessing system. For insert-intensive OLTP workloads, hash partitioning of tables and indexes can reduce concurrent insert contention and improve RAC performance transparently, although hash-partitioned indexes do not support index range scans.

Oracle RAC Sharding for Shard-Friendly Applications

Oracle RAC Sharding routes connections to instances according to a business sharding key, reducing inter-instance block transfers while preserving access to all tables from every instance. It is best suited to applications that know a stable, well-distributed key before connection checkout, use that key in SQL predicates, and concentrate transaction work on the same key; it is less effective for skewed or broadly distributed workloads. Deployment involves selecting and partitioning a frequently accessed table, enabling affinity, passing the key through the connection pool, and using it consistently in SQL, while unaffected application modules can continue using normal load balancing.

General Database Deployment Topics for Oracle RAC

Oracle RAC deployment benefits from locally managed tablespaces, automatic segment space management, and separate undo tablespaces for each instance, while limiting DDL during peak activity to avoid unnecessary overhead. Adding or removing nodes may require corresponding SYSAUX resizing. Poor XA transaction performance can be improved by directing all branches of a tightly coupled distributed transaction through a singleton DTP service on the same instance. RAC is well suited to OLTP because Cache Fusion supports availability, scalability, and load balancing, and to data warehouses because parallel execution can distribute work across instances using optimizer decisions based on cluster resources. TDE requires one shared keystore accessible to all nodes, Windows firewall settings must permit required Oracle connections, and ONS clients can be secured with wallets and appropriate configuration.

Introduction to Blocker Resolver

Blocker Resolver is an enabled-by-default RAC feature that detects, analyzes, verifies, and autonomously resolves database delays and deadlocks caused by blocking sessions. It runs as the DIA0 task, gathers cluster-wide information, waits for configurable thresholds, and terminates the blocking session or process when a delay does not resolve naturally, with priority given to protecting high-ranking sessions. Administrators can configure Normal or High sensitivity and control trace-file size and count through DBMS_BLOCKER_RESOLVER; the deprecated DBMS_HANG_MANAGER should no longer be used. Resolutions are recorded as ADR incidents with ORA-32701 in alert logs, while detailed diagnostics are written to DIA0 trace files.