Crash consistent backups and database cloning with Virtual Volumes
In the first part of this series we provided a high level view of the benefits of using Virtual Volumes enabled storage for database operations. In the second part of this series we examined in more detail how Virtual Volumes can improve the backup and recovery capabilities for business critical databases, specifically Oracle.
The backups for Oracle can be Database consistent or Crash consistent. In this part we will look at Crash consistent backup and recovery and also how database cloning is simplified by the use of VVol.
The setup of the infrastructure is the same as discussed in the second part of this series. Please refer to setup section for details of the infrastructure and the database configuration.
Database Crash Consistent Recovery and cloning use case Scenarios:
Crash Database Backup & Recovery using VVol Snapshots:
Crash Consistent Backup:
A crash consistent backup is the backup of a point-in-time image of an Oracle database that is equivalent to a database crash induced by a power outage, other failures or a shutdown abort.
This is the most common backup method used for storage based backups and is fully supported by Oracle as long as the following conditions are met.
From the “Supported Backup, Restore and Recovery Operations using Third Party Snapshot Technologies (Doc ID 604683.1)”:
The third party vendor needs to guarantee and held accountable that their snapshots conform to all the following requirements:
- Integrated with Oracle’s recommended restore and recovery operations above
- Database crash consistent at the point of the snapshot
- Write ordering is preserved for each file within a snapshot
There’s a fair bit of confusion around licensing SQL that is virtualized and I have been getting questions from customers about this for a long time now. The confusion comes from a few statements in the Microsoft SQL Server 2014 Virtualization Licensing Guide guide which states:
“For customers using Intel’s hyper-threading technology to split a single, physical core into two separate threads of power, there are some additional factors that should be kept in mind when licensing individual VMs using the Per Core Model”
This states that there are special considerations for licensing virtualized SQL servers on a per-core model when Hyper-threading is enabled on the hypervisor host.
What is the per core model, you ask?
The per core model is when licensing the virtual CPUs of a virtual SQL server rather than the physical CPUs on the hyper-visor server. As stated in the doc: “Per Core Licensing Model: Purchase a core license for each virtual core (or virtual processor/virtual CPU/virtual thread) allocated to the VM, subject to a four core license minimum per VM).” Continue reading
Virtual Volumes for Database Backup and Recovery
In the first part of this series we provided a high level view of the benefits of using Virtual Volumes enabled storage for database operations. In this post, we will examine in more detail how Virtual Volumes can improve the backup and recovery capabilities for business critical databases, specifically Oracle.
The backups for Oracle can be Database consistent or Crash consistent. In this part we will look at Database consistent backup and recovery.
The solution requires VVol enabled storage. We leveraged SANBLaze VirtuaLun as the backend storage for the backup and recovery exercise. We used the VirtuaLun 7.3 emulator from SANBlaze. This emulator is VVol enabled and is one of the first VVol certified storage solutions available.
Figure 1: SANBlaze Array for VVol Testing
Oracle Database Server:
A Single Instance Oracle 12c Database with Grid Infrastructure with database name VVOL12C was setup in a VMware Virtual Machine named ORACLE-VVOL. The Oracle database was hosted on a 2 vCPU and 8GB RAM VM running Oracle Enterprise Linux 6.6 with space allocated on a SANBlaze LUN. Continue reading