Recreating an Unrecoverable Database Deployment From a Backup to Cloud Storage

For a database deployment on Oracle Database Classic Cloud Service that hosts a single-instance database or a Data Guard configuration of single-instance databases, you can use the mrec media recovery utility to recreate the deployment if it cannot be restored and recovered using the orec command. This situation could occur if you've deleted critical configuration files or data files (such as the database redo log files, for example), or if something else has happened that caused the deployment to be lost.

The mrec utility restores the database deployment to the point of the last backup. This is equivalent to restoring the database and configuration from an external tape device. The mrec utility should be considered a last resource and used only when a database deployment cannot be restored in any other way.

Before You Begin

To recreate a deployment using the mrec utility, the following condition must be met:

A backup of the original deployment, including configuration files, must exist in cloud storage. The recreated deployment will be restored up to the latest backup available in cloud storage (data files and configuration files). If such a backup doesn’t exist, you can't use mrec to restore the deployment.

You must also know the following:

The settings used to create the original deployment.
The credentials and URL of the Oracle Storage Cloud Service instance to which the original deployment is backed up.
The database system identifier (SID) associated with the original deployment.

Procedure

Perform the following steps to recreate a database deployment using mrec. If you are recreating a deployment hosting a Data Guard configuration, perform steps on the compute node hosting the primary database unless you are directed otherwise.

Use the Create Instance wizard to create a new database deployment of the same type as the original deployment. See Creating a Customized Database Deployment. The backup of the original deployment will be restored to this new deployment.
Make sure you specify the following:
- The same Oracle Database version and software edition as the original deployment.
- On the Instance Details page, the same settings as the original deployment. At a minimum, the compute shape, storage capacity, database SID, Data Guard configuration, and backup and recovery configuration settings must be identical to those of the original deployment. If the compute node associated with the original deployment still exists, a different deployment name can be used.
Reduce the newly created database deployment to a minimal configuration:
1. Connect as the opc user to the compute node associated with the newly created database deployment.
  
  For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH).
2. Start a root-user command shell:
```
$ sudo -s
#
```
3. Run the deinstall script:
```
# /var/opt/oracle/misc/deinstall.pl -dbname=dbname
...
INFO : PLEASE REBOOT the VM before re-running ocde/dbsetup.sh
```
4. Reboot the compute node:
```
# reboot
...
The system is going down for reboot NOW!
```
5. Close your connection to compute node if it is not automatically closed due to the reboot.
If you are recreating a Data Guard configuration, repeat the preceding step on the compute node hosting the standby database.
Prepare the newly created deployment so mrec can be used:
1. After giving the compute node associated with the newly created deployment time to reboot, connect to it as the opc user.
2. Start a root-user command shell:
```
$ sudo -s
#
```
3. Edit (or create, if necessary) the file /var/opt/oracle/ocde/sm_params.cfg, giving it the following content:
```
adminPassword=password
cloudStorageContainer=backup-container
cloudStorageUser=storage-username
cloudStoragePwd=storage-password
```
  Where:
  - password is the administrator password specified when the new database deployment was created.
  - backup-container is the fully qualified name of the storage container where backups are stored. For example, https://exampledomain.storage.oraclecloud.com/v1/Storage-exampledomain/dbcsbackups. Do not enclose this value in quotation marks.
  - storage-username is the user name of the Oracle Cloud user to use when accessing the storage container.
  - storage-password is the password of the user specified in cloudStorageUser.
  Note:
  
  As a security measure, this file will be deleted when you run the ocde script later.
4. Update the timestamp on the sm_params.lk file:
```
# touch /var/opt/oracle/ocde/sm_params.lk
```
5. Run the ocde script to execute the prep and sda assistants:
```
# /var/opt/oracle/ocde/ocde -alist='prep sda' -firstrun
Starting OCDE
...
#### Completed OCDE Successfully ####
```
  This configuration will take some time to complete.
6. Keep this connection open for later use.
If you are recreating a Data Guard configuration, repeat the preceding step on the compute node hosting the standby database. Close the connection to the compute node that hosts the standby database after the last step completes.
Create a new oss.cfg configuration file with the exact same parameters and values as those in the oss.cfg file of the original deployment:
1. Connect to the original deployment as opc user and start a root-user command shell. If the original deployment is a Data Guard configuration, connect to the compute node hosting the primary database.
2. View the contents of the original deployment’s oss.cfg file:
```
# cat /home/oracle/bkup/SID/oss.cfg
```
  (On older database deployments the file is located at /home/oracle/bkup/oss.cfg.)
  
  Copy the parameters in the file. The same parameters and values must be used in the oss.cfg file for the new deployment.
  
  If you can’t access the oss.cfg file for the original deployment, these are the parameters you’ll need to specify:
```
oss_tid=storage-service-identity-domain
oss_sname=storage-service-name
oss_user=storage-service-admin-user-name
oss_passwd=storage-service-admin-user-password
oss_url=storage-service-container-URL
oss_auth_url=storage-service-authentication-URL
```
  For example:
```
oss_tid=usoracle04791
oss_sname=dbaasoss
oss_user=admin-user-name
oss_passwd=admin-user-password
oss_url="https://storage.us2.oraclecloud.com/v1/dbaasoss-usoracle04791/mycontainer"
oss_auth_url="https://storage.us2.oraclecloud.com/auth/v1.0"
```
3. Switch back to your connection to the new deployment. If the deployment hosts a Data Guard configuration, switch back to the connection to the compute node hosting the primary database.
4. Create an oss.cfg file that contains the parameters used in the oss.cfg file of the original deployment:
```
# cd /var/opt/oracle/mrec
# vim oss.cfg
```
5. Change ownership of the new oss.cfg file from the root user to the oracle user. Also change permissions:
```
# chown oracle:oinstall oss.cfg
# chmod 0600 oss.cfg
```
While still in the root-user command shell connection to the new deployment, run the mrec utility:
```
# cd /var/opt/oracle/mrec
# ./mrec -oss_cfgfile ./oss.cfg
-old_hostname hostname-of-node-to-restore -sid SID-of-instance-to-restore
```
where:
- hostname-of-node-to-restore is the simple name of the compute node to restore (doesn't need to be fully qualified). For example, prod01.
- SID-of-instance-to-restore is the database system identifier (SID) of the database instance to restore. For example, orcl.
The mrec utility pulls files over from the original deployment, installs the module used for cloud backups, and attempts recovery. Information about progress and status is displayed in the terminal window as the utility runs. If recovery is successful, you’ll see a message indicating that the deployment has been recovered and is in an open state. The amount of time this takes depends on the size of the deployment that you’re recovering.
If you are recreating a database deployment hosting a Data Guard configuration, you need to close and open each PDB.
1. Switch to the oracle user:
```
# su - oracle
$
```
2. Invoke SQL*Plus.
```
$ sqlplus '/ as sysdba'
```
3. Alter your session to connect to each PDB, and then close and reopen each PDB.
```
SQL> ALTER SESSION SET CONTAINER = pdb-name;
SQL> ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE;
SQL> ALTER PLUGGABLE DATABASE OPEN;
```
4. Log out of SQL*Plus.
```
SQL> exit;
```
5. Return to being the root user.
```
$ exit
#
```
If you are recreating a database deployment hosting a Data Guard configuration, perform this step to recreate the standby database.
```
$ export HOSTNAME=`hostname -s`
$ /var/opt/oracle/ocde/assistants/dg/dgcc -out /var/opt/oracle/ocde/res/dg_mrec.out
```
Close your connection to the compute node.