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. If not, you can specify values for fields such as Oracle Home, Oracle Base, custom SP file parameters, and restore location from the Console. In this case, these values overwrite the values mentioned in the original SP file, while retaining all other values.
You can perform an automated restore of a standalone database to a standalone database.
You cannot perform an automated redirected restore of a standby database to a standalone database. To perform a redirected restore of a standby database to a standalone database, you must download the database files and recover them manually.
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. |