Oracle Real Application Clusters (RAC) combined with Multitenant Architecture offers enterprises unmatched scalability, availability, and performance. As organizations increasingly rely on high-availability database systems, understanding Oracle RAC administration within a multitenant environment becomes essential for database administrators.
In this guide, we’ll explore Oracle RAC architecture, redo and undo tablespace management, local temporary tablespaces, service management, pluggable databases (PDBs), and key administrative tasks required to maintain RAC databases effectively.
Understanding Oracle RAC and Multitenant Architecture
Oracle RAC allows multiple instances to access a single database simultaneously, providing load balancing, failover protection, and enhanced system reliability. In a multitenant architecture, a Container Database (CDB) can host multiple Pluggable Databases (PDBs), each functioning as an independent database.
This architecture introduces additional layers of management because:
- Multiple RAC instances support one CDB
- Each PDB automatically receives a service
- Redo and undo management must align with RAC threads and containers
- Services must be monitored across nodes
Key Components:
- CDB$ROOT – Root container
- PDB$SEED – Template seed database
- PDBs – User-created pluggable databases
- RAC Instances – Multiple nodes (e.g., host01, host02, host03)
Every newly created PDB automatically gets its own default service, which can be managed within the RAC cluster.
Oracle RAC Service Management
Services are critical in RAC because they define how applications connect to specific databases or PDBs.
To check database status across RAC instances:
srvctl status database -d orcl
This command displays which instances are running the database, such as:
- host01
- host02
- host03
Each PDB’s service ensures workload routing and proper connection handling across RAC nodes.
Benefits of RAC Services:
- Load balancing
- Transparent failover
- Application continuity
- Instance-specific workload management
Shared Undo vs Local Undo in Multitenant RAC
Undo management in Oracle RAC Multitenant is crucial for transaction consistency and recovery.
Shared Undo Mode:
- One undo tablespace per CDB instance
- Standard configuration
- Simpler administration
Local Undo Mode:
- Each PDB has its own undo tablespace
- Greater isolation
- Better for advanced workload separation
In shared mode, all instances can read undo blocks for consistent reads, while transaction recovery can occur across instances when necessary.
Viewing Undo Tablespaces:
SELECT inst_id, name, value
FROM gv$parameter
WHERE name='undo_tablespace';
This query helps DBAs identify:
- Instance associations
- Active undo tablespaces
- Configuration consistency
Switching Undo Tablespaces:
When assigning a new undo tablespace:
ALTER SYSTEM SET undo_tablespace='UNDOTBS3' SID='RAC01';
The previous undo tablespace remains pending offline until Oracle confirms it is no longer needed.
Redo Log Management in RAC
Each RAC instance requires at least two redo log groups.
Important RAC Redo Features:
- Each instance has its own redo thread
- Thread numbers distinguish node-specific redo
- Round-robin redo writing
- Mandatory before enabling new RAC instances
Example:
- Node 1 → Thread 1
- Node 2 → Thread 2
Before enabling an instance:
ALTER DATABASE ENABLE INSTANCE;
Proper redo log planning ensures:
- High availability
- Crash recovery
- Instance-specific transaction tracking
Creating and Managing Pluggable Databases in RAC
Oracle RAC allows flexible PDB creation methods.
Create New PDB from Seed:
CREATE PLUGGABLE DATABASE pdb1
ADMIN USER pdbadmin IDENTIFIED BY password
FILE_NAME_CONVERT=('pdbseed','pdb1');
Clone Existing PDB:
CREATE PLUGGABLE DATABASE pdb3 FROM pdb1;
Using Oracle Managed Files (OMF) simplifies storage management significantly.
Opening the PDB:
ALTER PLUGGABLE DATABASE pdb1 OPEN;
Once opened, Oracle automatically starts the default PDB service.
Dropping a PDB in RAC
Dropping a PDB requires additional service cleanup.
Steps:
- Close PDB across all instances:
ALTER PLUGGABLE DATABASE pdb1 CLOSE INSTANCES=ALL;
- Remove associated dynamic service
- Drop PDB:
DROP PLUGGABLE DATABASE pdb1 INCLUDING DATAFILES;
Including datafiles permanently removes storage, though DBAs may choose to preserve files for backup or migration purposes.
Managing Local Temporary Tablespaces
Local temporary tablespaces can be configured to improve temporary segment management within PDBs.
Benefits:
- Better workload isolation
- Improved performance
- PDB-specific temporary operations
This is especially useful in environments where different PDBs serve varied application workloads.
RAC Initialization Parameters
Oracle RAC requires both shared and instance-specific initialization parameters.
Common Parameters:
cluster_databaseinstance_numberundo_tablespacethread
Instance-specific settings can be managed via:
ALTER SYSTEM SET parameter=value SID='instance_name';
Proper parameter configuration ensures:
- Stable cluster performance
- Correct node identity
- Optimized resource allocation
Best Practices for Oracle RAC Administration
To maximize RAC efficiency:
Recommended Strategies:
- Use Automatic Undo Management
- Maintain separate redo threads per instance
- Monitor services regularly with
srvctl - Standardize naming conventions
- Leverage Oracle Managed Files
- Configure local undo when workload isolation is required
- Periodically validate undo and redo configurations
- Remove unused PDB services promptly
Conclusion
Oracle RAC administration in a multitenant environment introduces advanced capabilities alongside additional complexity. From managing multiple instances per CDB to configuring undo tablespaces, redo threads, and pluggable services, DBAs must adopt a strategic approach.
By mastering:
- RAC services
- Shared and local undo
- Redo thread management
- PDB lifecycle administration
- Initialization parameters
Organizations can achieve exceptional database scalability, resilience, and performance.
Oracle RAC with Multitenant Architecture is a powerful solution for modern enterprise workloads, and with proper administration, it becomes a cornerstone of mission-critical infrastructure.




