In a previous blog, we covered how Druva’s Oracle solution can enable long-term retention to cut storage costs by as much as 20 percent. In this blog, we’ll cover how Druva’s Oracle direct-to-cloud (DTC) technology delivers versatile restore capabilities. First, one of the best features of the DTC product is that it allows the easy install, configuration, and automation of Oracle backups. Once this phase is complete, a plethora of recovery scenarios are then available to the customer. Because the DTC product leverages RMAN for its recovery capabilities, the variety of possibilities are only bounded by the capabilities of the RMAN binary — which is highly configurable for a variety of restore and or recovery scenarios. DTC marries the skills of a seasoned Oracle DBA with RMAN backup sets, leveraging a mixture of full and incremental backups and simplifying recovery. The DBA need only perform a few point-and-click operations in the GUI of the Druva console, and RMAN does the rest.
This functionality allows the DBA to creatively and granularly create customized RMAN restore scripts to perform the operation at any given time. Typically, DBAs will use RMAN backups of their production databases to clone copies for development and test servers. This allows an organization to test or develop with production data, and receive greater insight into its specific data or subsets. The end result is a real-world test of their new code with the appropriate data. Simultaneously, when the DBA leverages these RMAN backups for cloning purposes, they are also testing the integrity of their backup and recovery strategy. The initial point-and-click operations are quickly executed from the Druva console by simply choosing the database to clone.
In the configured database menu simply choose the appropriate database:
In this case, the chosen database to clone is dev18c2. The chosen modality is a snapshot restore of the RMAN backup sets. The DBA has two choices, either a point-in-time methodology or a snapshot restore of the database files in proprietary Druva and RMAN format. The DBA simply clicks the restore button in the upper right-hand corner, and once the database is selected, checks the box for the appropriate restore format to launch the job.
The restore job is then capable of tracking in the jobs menu of the console.
The selected restore of a snapshot is highly configurable. The DBA may place the snapshots on any disk destination as the alternate node host. In this case, the datafile subdirectory near where the files are actually restored is chosen as a suitable destination with enough space to hold the snapshots.
First, the alternate node host is chosen. In this case, all that is required is that the server has the agent for Druva installed and running on the host, and that the host is registered with the Druva console.
In our example, the oracle3d3c host is chosen for cloning/testing as there is no database running on this host.
A path for the files is required by the restore location and the console allows the DBA to explore the filesystem of the entire server.
Here, we navigate to the /u02/oradata/DEV18C2/datafile destination in the console for the placement of our RMAN backup set snapshot in proprietary Druva format. The files are owned by the root super user, but the Oracle Unix super user is able to read these files and use them during the restore operation.
We then click the OK button to launch a job and restore the snapshot to the server.
When the job run is complete and the console informs the DBA that the restore was successful, a new directory is created on the server wherein the snapshot data will reside.
As the restore is complete, the DBA may navigate to that directory to see the proprietary data.
Once in the subdirectory, any Unix list commands will display the files. The DBA may navigate to the directory where the job-restored data resides using a path referencing the date and data — once again in Druva proprietary format.
Files with a CF extension relate to a control file, and SPF extensions reference server-side parameter files. Other files are pointers to tablespace datafiles in Druva proprietary format.
In our use case, we alter the db_recovery_file_dest to a null string. This disables implicit crosschecks of the fast recovery area via RMAN so restore operations bypass this step. This only takes a moment, and the parameter is dynamic so changing it back simply requires a one-time command-line argument in SQLPLUS.
We had also shut down the previously-cloned database in preparation for the restore operation, as well as removing tablespace datafiles to provide space in the filesystem disk destination.
We will now execute the operation as the Oracle Unix super user connected to the target via RMAN.
The DTC product leverages the RMAN backups from the Druva Cloud in the AWS EC2 environment and downloads the data to the alternate node host. It then uses this same data to perform the database restore and recovery.
The process runs to completion with the database having its DBID set and restored into place with recovery. This database is then opened read-write with a resetlogs operation. It is the resetlogs operation that echoes back the statement processed output.
The database tablespace datafiles are restored into place before recovery is initiated via RMAN.
This quick walkthrough demonstrates how quickly DTC restores and recovery can take place. It is important to point out that all databases in our example are using block change tracking (BCT) and a mixture of full and/or incremental backups, along with archive log backups.
Druva’s Oracle DTC product creates a recovery chain allowing DBAs to easily clone databases with current production backups. This gives the skilled DBA great latitude to perform any type of recovery and/or restore operation with alacrity, ease of use, and a wide variety of options. Other products on the market only afford point-and-click restore operations — providing only one or two options as opposed to the entire gamut of RMAN recovery and restore available to those with Druva.
Visit Druva’s Oracle page to further explore how your IT team can improve Oracle data protection with cloud backup-as-a-service. And stay tuned for the next installment in our Oracle blog series as we continue our look into DTC restore and recovery use cases.