CertMan

Post Contents

Oracle 19c Real Application Cluster Overview and Tips

Oracle 19c Real Application Cluster Overview and Tips

The Oracle Real Application Cluster (RAC) is a robust solution that allows an Oracle database to run across multiple servers, providing high availability, scalability, and performance. This system is essential for organizations requiring continuous system availability and scalable resources. Understanding RAC architecture, installation, configuration, and best practices for management and optimization is crucial for database administrators. RAC Tips are critical for effective management and optimization of these clusters. The Real Application Cluster is designed to provide a resilient database environment that ensures data consistency and reliability across multiple nodes.

Architecture of Oracle Real Application Cluster

Oracle Real Application Cluster architecture involves several key components:

Cluster Servers: Multiple servers sharing access to a common set of storage disks, which ensures that the database can continue to operate even if one server fails. The Real Application Cluster architecture allows for seamless failover and load balancing.

Cluster Interconnect: A high-speed network enabling communication between cluster servers. This network is critical for maintaining synchronization and data consistency across the servers. The Real Application Cluster relies on this interconnect to ensure that all nodes can communicate effectively and efficiently.

Database Services: Services managing user sessions and workload distribution. These services allow for load balancing and failover, ensuring that user requests are efficiently managed across the cluster. In a Real Application Cluster environment, database services are configured to optimize performance and availability.

Shared Storage: A storage system accessible by all cluster servers. This shared storage is typically managed using Oracle Automatic Storage Management (ASM) to optimize performance and manageability. Shared storage is a cornerstone of the Real Application Cluster, providing a unified and consistent data source.

Cluster Servers

Cluster servers in an Oracle Real Application Cluster environment are configured to work together, sharing the load of database processing. Each server in the cluster is connected to the shared storage, ensuring that all servers have access to the same data. This configuration helps in achieving high availability and fault tolerance. For instance, if one server fails, the workload is redistributed among the remaining servers without disrupting the service. The Real Application Cluster configuration ensures that the system can handle hardware failures gracefully.

Cluster Interconnect

The cluster interconnect is a dedicated, high-speed network that connects all the servers in the cluster. It is used for communication between the instances running on different servers. This communication is essential for coordinating the database operations across the cluster. The performance and reliability of the interconnect directly affect the overall performance of the Real Application Cluster system. Therefore, it is crucial to use high-performance networking hardware and configure it properly. In a Real Application Cluster, the interconnect ensures that all nodes stay in sync and can share data efficiently.

Database Services

Database services in Oracle Real Application Cluster manage the distribution of user connections across the cluster. You can define services to run on specific instances, allowing for customized load balancing and failover configurations. For example, configure different services for OLTP (Online Transaction Processing) and batch processing workloads, optimizing resource usage and performance. The Real Application Cluster uses these services to ensure the most appropriate node handles user requests, enhancing performance and reliability.

Shared Storage

Shared storage is a critical component of Oracle Real Application Cluster. It ensures that all servers in the cluster have access to the same set of data files. Oracle ASM (Automatic Storage Management) is often used to manage the shared storage, providing a high-performance and scalable storage solution. ASM simplifies database storage management by providing a virtualization layer between the database and storage devices. This allows administrators to manage storage resources more efficiently. In a Real Application Cluster environment, shared storage ensures data consistency and availability across all nodes.

Installation and Configuration of Oracle Real Application Cluster

The installation and configuration of Oracle Real Application Cluster involve several critical steps:

Environment Preparation

Setting up the hardware, networks, and operating systems of the servers is the first step in deploying Oracle Real Application Cluster. This includes configuring network interfaces, setting kernel parameters, and ensuring the system meets all prerequisites. For example:

$ yum install oracle-rdbms-server-19c-preinstall

This command installs the required packages and sets up the environment for Oracle Real Application Cluster installation. Proper environment preparation is essential to ensure smooth installation and configuration of the Real Application Cluster.

Oracle Grid Infrastructure Installation

The Oracle Grid Infrastructure provides the necessary software to manage the cluster and the shared storage. The installation can be initiated with the following command:

$ ./gridSetup.sh

This script launches the Oracle Universal Installer (OUI), which guides you through the installation process. The Grid Infrastructure is a key component of the Real Application Cluster, providing the tools needed to manage cluster resources effectively.

Oracle Database Installation

After installing the Grid Infrastructure, the next step is to install the Oracle Database software. This involves configuring the database to operate in a clustered environment:

$ ./runInstaller

The Oracle Universal Installer will guide you through the process of installing the Oracle Database software and configuring it for Real Application Cluster. Proper database installation and configuration are crucial to ensure that the Real Application Cluster operates optimally.

Clusterware Configuration

Clusterware is a key component of Oracle Real Application Cluster, responsible for managing cluster resources and ensuring high availability. The following command can be used to add a new node to the cluster:

DBMS_CLS_CONFIG.addNode(nodeName => 'node2', instance => 'instance2');

This command adds a new node named ‘node2’ with an instance named ‘instance2’ to the cluster, expanding its capacity and improving its fault tolerance. The Real Application Cluster can easily scale by adding new nodes, enhancing its capacity and resilience.

Managing Oracle Real Application Cluster

Effective management of Oracle Real Application Cluster includes monitoring performance, managing faults, and performing regular maintenance.

Performance Monitoring and Tuning

Using tools like Oracle Enterprise Manager, administrators can monitor the performance of the cluster and make necessary adjustments to optimize performance. For instance, to check the status of the database, you can use:

srvctl status database -d exampledb

This command provides the current status of the specified database, helping administrators monitor its health and performance. Regular performance monitoring and tuning are essential to maintain the efficiency of the Real Application Cluster.

Fault Management

Implementing fault tolerance and recovery strategies is crucial for ensuring high availability. Administrators can check the status of the cluster using the following command:

$ crsctl check cluster -all

This command checks the health of all cluster components, ensuring that the system is functioning correctly and identifying any potential issues. In a Real Application Cluster, fault management ensures that the system can recover quickly from failures.

Cluster Maintenance

Regular maintenance tasks include applying updates and patches to the Oracle Real Application Cluster software. The following command can be used to apply a patch:

$ opatch auto <patch_id>

This command applies the specified patch to the entire cluster, ensuring that all nodes are updated simultaneously, minimizing downtime and maintaining system consistency. Regular maintenance is essential to keep the Real Application Cluster running smoothly and securely.

RAC Administration

Show database configurations, including SPFILE and PASSWORD FILE:

srvctl config database -db exampledb

This command shows the current configuration of the database, including the SPFILE and PASSWORD FILE. It is useful for administrators to review and verify the configuration settings of the Real Application Cluster.

Starting and stopping instances:

Start an instance in an Oracle Real Application Cluster environment:

srvctl start instance -db db_unique_name -node node_name -instance instance_name_list

This command starts a specific instance on a particular node within the Real Application Cluster. For example:

srvctl start instance -db orcl -instance orcl1,orcl2

Stop an instance:

srvctl stop instance -db orcl -instance orcl1,orcl2

This command stops a specific instance in the Real Application Cluster. It is useful for maintenance tasks or shutting down instances that are not needed.

Start the database:

srvctl start database -db orcl -startoption open

This command starts the entire database in the Real Application Cluster, making it available for user connections and operations.

Starting a pluggable database and service across servers:

Add a service linked to the server pool and containing the PDB:

srvctl add service -db exampledb -pdb pdbexample -service plug -serverpool prdpool

This command adds a new service to the Real Application Cluster that is linked to a server pool and a pluggable database (PDB). It ensures that the PDB is accessible through the specified service.

Start the service:

srvctl start service -db exampledb -service plug

This command starts the specified service in the Real Application Cluster, making the PDB accessible to users.

Stop the service:

srvctl stop service -db exampledb -service plug

This command stops the specified service in the Real Application Cluster, preventing access to the PDB through that service.

Check configuration:

srvctl config database -db exampledb -a

This command provides a detailed configuration report for the specified database in the Real Application Cluster. It includes information about instances, services, and other database settings.

Check resources running in ORACLE_HOME:

srvctl status home -oraclehome /u01/app/oracle/19.0.0 -statefile ~/stat1.dmp -node host1

This command checks the status of all resources running in the specified ORACLE_HOME directory on a specific node. It is useful for monitoring the health and status of the Real Application Cluster environment.

Stop and start resources in ORACLE_HOME:

Stop resources:

srvctl stop home -oraclehome /u01/app/oracle/19.0.0 -statefile ~/stat1.dmp -node host1

This command stops all resources in the specified ORACLE_HOME directory and saves their current state to a state file. It is useful for maintenance and troubleshooting tasks.

Start resources based on state file:

srvctl start home -oraclehome /u01/app/oracle/19.0.0 -statefile ~/stat1.dmp -node host1

This command starts all resources in the specified ORACLE_HOME directory based on the state saved in the state file. It ensures that the Real Application Cluster environment is restored to its previous state.

Change Management Policy for planned maintenance:

srvctl modify database -db exampledb -policy manual

This command changes the management policy of the specified database to manual, preventing automatic startup and shutdown during planned maintenance windows. It is useful for controlling the behavior of the Real Application Cluster during maintenance.

Modifying Parameters

Each Real Application Cluster instance uses a PFILE on the local node, which points to the SPFILE located in shared storage:

[oracle@host1 dbs]$ pwd
/u01/app/oracle/19.0.0/dbs
[oracle@host1 dbs]$ cat initexampledb1.ora
SPFILE='+DATA/exampledb/spfileexampledb.ora'

Modify parameters:

Set a parameter temporarily:

ALTER SYSTEM SET parameter=value SCOPE=MEMORY SID='<sid|*>';

This command sets a parameter value temporarily in memory for a specific instance or all instances in the Real Application Cluster.

Reset a parameter to default temporarily:

ALTER SYSTEM RESET parameter SCOPE=MEMORY SID='<sid>';

This command resets a parameter to its default value temporarily in memory for a specific instance in the Real Application Cluster.

Reset a parameter to default in the SPFILE:

ALTER SYSTEM RESET parameter SCOPE=SPFILE SID='<sid>';

This command resets a parameter to its default value in the SPFILE for a specific instance in the Real Application Cluster. It ensures that the change is persistent across instance restarts.

 

Quiesce the Database

Restricting the database to prevent DML operations, connections, backups, etc.:

ALTER SYSTEM QUIESCE RESTRICTED;

This command restricts the database, preventing Data Manipulation Language (DML) operations, new connections, and backups. Only DBA users can log in during this state. It is useful for maintenance tasks that require a stable and consistent database state.

Deactivate quiesce mode:

ALTER SYSTEM UNQUIESCE;

This command deactivates the quiesce mode, allowing normal database operations, connections, and backups to resume.

Using GV$ Views to Manage RAC

For example, to kill a session:

ALTER SYSTEM DISCONNECT SESSION '140,3340,@2';

This command disconnects a specific session in the Real Application Cluster. The ‘@2’ indicates the instance number where the session is running. It is useful for managing and troubleshooting problematic sessions.

Checkpoint in RAC

Affect only the current instance:

ALTER SYSTEM CHECKPOINT LOCAL;

This command triggers a checkpoint operation in the current instance of the Real Application Cluster, ensuring that the system writes all modified data blocks to disk.

Affect all instances in the cluster:

ALTER SYSTEM CHECKPOINT;

This command triggers a checkpoint operation across all instances in the Real Application Cluster, ensuring that the system writes all modified data blocks to disk on all nodes.

Switch Logfile in RAC

Affect only the current instance:

ALTER SYSTEM SWITCH LOGFILE;

This command switches the log file for the current instance in the Real Application Cluster, forcing a log file switch and archival of the current redo log file.

Force a global switch:

ALTER SYSTEM ARCHIVE LOG CURRENT;

This command forces a global log file switch across all instances in the Real Application Cluster, ensuring that all redo log files are archived.

Convert RAC One Node Database to RAC

srvctl convert database -db exampledb -dbtype RAC -node node1

This command converts a RAC One Node database to a full RAC database, adding the specified node to the cluster. It is useful for scaling the database environment to multiple nodes.

Add instances:

srvctl add instance -db exampledb -instance exampledb_2 -node node2

This command adds a new instance to the specified database on the given node in the Real Application Cluster, increasing its capacity and fault tolerance.

RAC and Multitenant

Now we are going to explaing about Starting and Stopping Pluggable Databases.

Start a PDB on a specific instance:

ALTER PLUGGABLE DATABASE pdb2 OPEN INSTANCES = ('instance2');

This command opens the specified pluggable database (PDB) on the given instance within the Real Application Cluster. If instances are not specified, it opens the PDB only on the current instance.

Start a PDB on all instances:

ALTER PLUGGABLE DATABASE ALL OPEN INSTANCE=ALL;

This command opens all pluggable databases in the container database (CDB) on all instances of the Real Application Cluster, ensuring that all PDBs are accessible across the cluster.

Stop a PDB on all instances:

ALTER PLUGGABLE DATABASE ALL CLOSE INSTANCE=ALL;

This command closes all pluggable databases in the container database (CDB) on all instances of the Real Application Cluster, preventing access to the PDBs.

Stop a PDB in the current instance and open it in another:

ALTER PLUGGABLE DATABASE pdb2 CLOSE RELOCATE TO 'instance2';

This command closes the specified pluggable database (PDB) in the current instance and opens it in the specified instance within the Real Application Cluster, effectively relocating the PDB.

Create a PDB from SEED or Clone in CDB

Create:

CREATE PLUGGABLE DATABASE pdb2 ADMIN USER admin1 IDENTIFIED BY "password" ROLES = (CONNECT) FILE_NAME_CONVERT = ('PDB$SEEDdir', 'PDB2dir');

This command creates a new pluggable database (PDB) from the seed template in the container database (CDB). The new PDB is created with the specified administrative user and file name conversion settings.

Clone:

CREATE PLUGGABLE DATABASE pdb2 FROM pdb1;

This command clones an existing pluggable database (PDB) to create a new PDB. The source PDB needs to be in READ ONLY mode in all instances before cloning.

Drop a PDB from a CDB RAC

Remove dynamic services:

srvctl remove service -db cdb1 -service mypdb1serv

This command removes a specified service associated with a pluggable database (PDB) in the container database (CDB). Removing services is a necessary step before dropping a PDB.

Close the PDB in all instances:

ALTER PLUGGABLE DATABASE pdb1 CLOSE INSTANCES = ALL;

This command closes the specified pluggable database (PDB) in all instances of the Real Application Cluster, ensuring no one uses it before dropping it.

Drop the PDB:

DROP PLUGGABLE DATABASE pdb1 INCLUDING DATAFILES;

This command drops the specified pluggable database (PDB) and removes all its associated data files from the container database (CDB). This action is irreversible and should be performed with caution.

RAC One Node Database Administration

Show database configurations, including SPFILE and PASSWORD FILE:

srvctl config database -db exampledb

This command shows the current configuration of the database, including the SPFILE and PASSWORD FILE. It is useful for administrators to review and verify the configuration settings of the Real Application Cluster.

Convert RAC database to RAC One Node:

Check the status of the RAC database:

srvctl status database -db orcl

This command checks the status of the specified RAC database, providing information about the instances and their current state.

Stop instances of the RAC database (leave only one active):

srvctl stop instance -f -d orcl -node host2

This command stops a specific instance in the Real Application Cluster, leaving only one instance active. It is a necessary step before converting a RAC database to RAC One Node.

Check the status again:

srvctl status database -db orcl

This command checks the status of the specified RAC database again to ensure that only one instance is active.

Create a dynamic service:

srvctl add service -db orcl -s SERV1 -serverpool orcldb

This command adds a new dynamic service to the specified database in the Real Application Cluster, associating it with a server pool.

Convert the RAC database to RAC One Node:

srvctl convert database -db orcl -c RACONENODE

This command converts the specified RAC database to a RAC One Node configuration, making it a single-node active-passive cluster.

Check the database configuration:

srvctl config database -db orcl

This command shows the current configuration of the database, confirming the conversion to RAC One Node.

Check the status again:

srvctl status database -db orcl

This command checks the status of the specified RAC One Node database, providing information about the instances and their current state.

Perform online relocation:

srvctl relocate database -db orcl -node host2 -w 15 -verbose

This command performs an online relocation of the specified RAC One Node database to another node. The -w 15 option specifies a 15-minute wait time for active sessions to be relocated.

Convert RAC One Node to RAC:

Stop the database:

srvctl stop database -db orcl

This command stops the specified RAC One Node database, preparing it for conversion back to a full RAC configuration.

Convert the database:

srvctl convert database -db orcl -dbtype RAC

This command converts the specified RAC One Node database back to a full RAC configuration, enabling multiple active instances.

Start the database:

srvctl start database -db orcl

This command starts the specified RAC database, making it available for user connections and operations.

Check the status:

srvctl status database -db orcl

This command checks the status of the specified RAC database, providing information about the instances and their current state.

Add an instance to existing nodes if necessary:

srvctl add instance -db orcl -instance orcl3 -node host3

This command adds a new instance to the specified database on the given node in the Real Application Cluster, increasing its capacity and fault tolerance.

Server Pool Management

Remove the server pool:

srvctl remove srvpool -serverpool orcldb

This command removes the specified server pool from the Real Application Cluster, freeing up resources and simplifying management.

Check the status of the server pool:

srvctl status srvpool

This command checks the status of the specified server pool, providing information about its current state and the resources it manages.

Convert Single-Instance to RAC

Using DBCA, Enterprise Manager, or RCONFIG, convert a single-instance database to RAC.

Conclusion

Oracle Real Application Clusters provide a robust solution offering high availability, scalability, and performance for critical database environments. Proper implementation and management of Oracle Real Application Cluster are essential to fully leverage the benefits of this technology. Effective use of RAC Tips ensures the system’s efficiency, stability, and responsiveness.

See more on Oracle’s website!

Be Oracle RAC certified, this world is full of opportunities for qualified DBAs!

Leave a Reply

Your email address will not be published. Required fields are marked *