Overview
Druva supports the protection of Oracle RAC databases where a single database runs on different servers (nodes or instances). With Oracle RAC support, you can protect your data seamlessly wherein even if one or more nodes in the cluster go down, the data protection continues on the next available node in the cluster. This ensures high data resiliency in mission-critical applications.
Key highlights
The following are some of the key highlights of Druva’s support for backup and recovery of RAC databases:
Phoenix policy-driven backup and recovery that allows hassle-free scheduling and triggering of jobs
Auto-discovery of all online and offline database instances
Efficient load balancing for backup and recovery
Parity with Phoenix core value propositions such as
On-demand full backup
Recovery catalog
Configurable RMAN channels
Automated restores and recovery
Point-in-time restore
Long Term Retention
Advance Jobs view, alerts, and reporting
The following video shows how to back up and restore RAC databases using Management Console:
Backup configuration pre-checks
The Druva agent runs a few checks before configuring a database for backup. These pre-checks look for potential issues that can cause your backup job to fail, thereby allowing you to proactively minimize the possibility of backup jobs to fail. Make sure you fix any issues that are identified by these pre-checks before backing up your data.
See the following screenshot for sample pre-checks:
The following tables list the pre-checks that the agent performs before backing up the database:
Pre-check | Description | Action to take if the pre-check fails |
Client connection status | Verifies if all the configured instances are up and running. | Make sure the client is in the connected state. |
RAC node instance state and credentials | Verifies whether the RAC instances are up and running and that you can connect to those instances using the provided wallet aliases. | Make sure that the RAC instances are in the Open state and provide the correct wallet alias to connect to those instances. |
Agent version of RAC nodes | Verifies if all the RAC instances have the same agent version. | Upgrade the RAC instances to the same agent version. |
Additionally, before backup, the agent also checks which other available instance can be made primary in case the primary instance goes down. If any of the secondary instances goes down, an alert is generated and the backup continues on the other available instances. For more information about the primary node, see About primary node.
Restore pre-checks
The Phoenix agent runs a few checks before restoring RAC clusters. These pre-checks are done at different stages of restore such as SP Files Restore, Control File Restore and database restore and recovery.
After each stage, the agent checks the status of the instance(s) and only the instances that are available after the control file restore are used for the database restore and recovery.
The restore job fails if any of the instance goes down during recovery.
See the following screenshot for sample pre-checks:
The following tables lists the pre-checks that the agent performs before restoring the database:
Pre-check | Description | Action to take if the pre-check fails |
Client connection status | Verifies if all the configured instances are up and running. | Make sure the client is in the connected state. |
Agent version of RAC nodes | Verifies if all the RAC instances have the same agent version. | Upgrade the RAC instances to the same agent version. |
About primary node
The primary node is the first node that is discovered on the RAC database and is selected for assigning credentials. However, you can select a different node as a primary node while performing authentication. Additionally, you must also select a primary node for backup set configuration. If no node is selected as the primary node during backup set configuration, then the primary node for authentication is selected as primary node for backup set configuration. The primary node receives all job events. If the primary node goes down, the backup or restore is continued on the next available node. If all nodes in the cluster are down, the job fails.