Enterprise Workloads Editions: β Business | β Enterprise | β Elite
Overview
To recover a database to a different server, an administrator would download the required database files and manually recover them on the destination server.
This was a costly operation in terms of storage, especially for databases on cloud virtual machines.
Now you can restore your database automatically to any server other than the source server. The restoration of a database to an alternate server is also known as database cloning or redirected restore. You can perform redirected restores by using the backed up recovery points directly from the cloud.
What are the benefits of this feature?
You can perform an automated restore of your Oracle database to an alternate server so that you can:
Create a copy of your production database for development or testing
Recover your production databases in case of a disaster
Perform periodic backup validations of your database
Migrate database from one machine or storage to another, or to Cloud.
Key considerations
Consider the following points before performing an automated restore of database to an alternate server:
You can perform redirected restores on agent version 6.1.0 or later.
To restore the database to an alternate server, make sure the DB user is the same on the source and destination servers.
By default, the database is restored to a File System.
You can restore a standalone database to an alternate server using the ASM location. For this, you must set custom spfile parameters on the Restore wizard on the console.For more information, see Restore an Oracle database from a recovery point.
If you select the Restore SP File check box, make sure that the source and the target server are identical in terms of the directory structure, memory configuration, and so on.
You can perform an automated restore of a standalone database to a standalone database.
You can perform an automated restore of a standby database to a standalone database as the primary database.
You can perform a redirected restore of a RAC database to a standalone database. Automated restore from RAC database to RAC database is not supported.
You can perform redirected restores using both Recovery point and Point-in-time restore methods.
If the database with the same name as that of the source exists on the restore location, it will be overwritten by the restored database. For more information, see the Source Database Check precheck in Restore prechecks.
π Note
β For automated restore to an alternate server, Druva first restores the database to an alternate server with the source database name. Once the database is successfully recovered and opened, Druva changes its name to the target database name.
Use cases
The following table describes the different use cases supported for cloning a database to an alternate server. Perform the actions mentioned in the Recommended action column for successful restores.
The following use cases are applicable to both, Recovery point and Point-in-time restore.
β Important
If the database with the same name as that of the source exists on the restore location, it will be overwritten by the restored database.
Scenario:Multiple restores to the alternate server with
|
|
|
|
Use Case | Conditions | Recommended action | Result |
First restore |
|
| The database is cloned and started. |
Subsequent restores |
| Before restoring the database shut down or drop the database cloned in the previous restore. | The database is cloned with the provided name and started. |
Scenario: Multiple restores to alternate server with
|
|
|
|
Use Case | Conditions | Recommended action | Result |
First restore |
| None | The database is cloned with the name provided and started. |
Subsequent restores |
| None | Databases are cloned with the names provided and started.
π Note
|
Scenario: Multiple restores to alternate server with
|
|
|
|
Use Case | Conditions | Recommended action | Result |
First restore |
| None | The database is cloned with the name provided and started. |
Subsequent restores |
| None | Databases are cloned with the names provided and started.
π Note
|
Sceanrio: Multiple restores to alternate server with
|
|
|
|
Use Case | Conditions | Recommended action | Result |
First restore |
| None | The database is restored and started on the File system. |
Subsequent restores |
| None | The database is restored and started on the File system.
π Note
|
Scenario: Multiple Restore to alternate server with
|
|
|
|
Use Case | Conditions | Recommended action | Result |
First restore |
| None | The database is cloned with the name provided and started. |
Subsequent restores |
| None | The database is restored at the provided location and started. |
Scenario: Multiple Restore to alternate server with
|
|
|
|
Use Case | Conditions | Recommended action | Result |
First restore |
| None | The database is cloned and started. |
Subsequent restores |
| None | The database is cloned and started. |
Scenario: Multiple Restore to alternate server with
|
|
|
|
Use Case | Conditions | Recommended action | Result |
First restore |
| None | The database is cloned and started. |
Subsequent restores |
| None | The database is cloned and started. |
Restore prechecks
The Phoenix agent runs a few checks before restoring a database. These checks look for issues that can cause your restore job to fail before the restore has started. You must fix any identified issues before restoring your database. The following sections describe the restore pre-checks and remedial actions you must take in case of pre-check failures.
Pre-check | Description | Action to take if the pre-check fails |
Client connection status Check | Verifies if the client is in the connected state. | Make sure the client is in the connected state. |
Oracle Home Check | Verifies if the provided Oracle Home is valid. | Make sure you provide a valid Oracle Home. |
Oracle Base Check | Verifies if the provided Oracle Base is valid. | Make sure you provide a valid Oracle Base. |
Source Database Check | Verifies if a database with the same name as that of the source already exists on the destination server. | Make sure that you move the existing database that exists on the destination server to another location and then perform the restore. |
OS Version Check | Verifies if the OS version of the destination server is compatible with the source OS version. | Make sure that the OS version of the destination server is compatible with the source OS version. |
Oracle Database Version Check | Verifies if the Oracle version of the destination server is compatible with the source OS version. | Make sure that the OS version of the destination server is compatible with the source OS version. |
Storage Space Availability | Verifies if sufficient space is available on the destination server for performing restore. | Make sure that sufficient space is available on the destination server for performing restore. |
Restore Location Check | Verifies if the specified restore location exists on the destination server and the oracle user has the required permissions to perform restore on that location. | Make sure that the specified restore location exists on the destination server and the oracle user has the required permissions to perform restore on that location. |
Memory Availability Check | Verifies if the required memory is available on the destination server. | Make sure that the required memory is available on the destination server. |
Restored database name check | Verifies if a database with the same name exists at the selected location. | Make sure that you provide a different name to the database while restoring it to an alternate server. Else the existing database will be overwritten with the restored database. |
SPFile Parameters Check | Verifies if the provided SPFile parameters are valid. | Make sure that you provide valid SPFile parameters and their values in the
In case of multiple parameters, make sure you specify each parameter on a new line. |