This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
I previously posted about the importance of volume snapshots and Azure Backup’s private preview for Oracle a number of months back and now it’s generally available!
Having a volume snapshot solution native to Azure for Oracle was an important option for Oracle to Azure in Infrastructure as a Service (IaaS.) For many of our high IO storage solutions, the vendor includes a volume snapshot solution with the storage, but with managed disk from Azure, we were often left to use RMAN, (Oracle’s Recovery Manager) which for smaller databases, (commonly under 1TB in size) is an option, but for larger databases, becomes IO and time inhibitive.
Due to this, the Azure Backup product team and the Oracle CAE team banded together to design, code and finalize a solution that provides volume snapshots for an Oracle database running on managed disk or Azure NetApp Files, (ANF) in any Azure VM. As with other snapshot solutions, this doesn’t work for Ultra Disk, but as we recommend using Ultra for redo logs, (it’s too often limited in features and cost prohibitive to put datafiles in Ultra) It’s easy to limit the use of Ultra Disk to RMAN for backing up the redo logs and then use these subsequent archive logs, stored on a secondary storage, such as Azure shared files standard share mounted to the VM to provide the Point in Time recovery after a volume snapshot has been recovered. Azure shared files is recommended over other storage options due to the backup design, ensuring that they can easily be recovered if needed from an automated storage backup.
Azure Backup Volume Snapshots for Oracle provides a recovery solution option for Oracle to secondary or primary VMs to restore the snapshot, then apply the archive logs via RMAN, post the restoration. This removes the heavy IO consumption of nightly full or incremental backups of the database and only changes from the archive logs will need to use RMAN.
The process for the scripted process will perform the following:
- Locate the backupdba OS group on the VM
- Create an azbackup OS account on the VM
- Setup an Azure Files share to use with the archive logs
- Create the ops$azbackup database account inside the Oracle database
- The backup script will redirect the archive logs to the Azure File share created in step #3
- Set the parameter for the ARCHIVE_LAG_TARGET in the database to be backed up
Once this is completed, then the initial backup is performed and an update needs to be made in the /etc/azure/workload.conf configuration file.
At this same time, an application tier backup job to be consistent with the database tier should be performed for recovery synchronization.
If you’re interested in using Azure Backup Volume Snapshots for Oracle, check out the Pre and post scripts, which can be found in the Github repository here: