Oracle Pre-Provisioning

Businesses that rely heavily on data and require 100% uptime must have a contingency plan should they encounter a failure in production.

Businesses that rely heavily on data and require 100% uptime must have a contingency plan should they encounter a failure in production. Contingency plans typically include some form of regular backups which are a perfect response to data loss as long as the backups are valid.

Restoring and validating backups can be an expensive and lengthy procedure and is often performed infrequently or not at all. Taking regular backups without validating them is akin to flying a jet with an untested parachute. 99.99% of the time the chute is unnecessary but the 0.01% of the time that you need it you want to be 100% certain it works.

The new Oracle pre-provisioning feature introduced in Delphix 3.2 is built atop well used Oracle backup primitives and validates snapshots each time they are taken. This in turn validates any other backup strategy built upon the same primitives. Since the source database is live when the Delphix Engine takes a snapshot, the backup image of the database is not self-consistent.

If the backup began at 10:00 and finished at 10:30 some blocks in the snapshot may be as they appeared at 10:00 while others may be as they appeared at 10:15 or 10:30. To resolve this inconsistency the snapshot must undergo Oracle media recovery and requires the transaction logs associated with the backup interval.

This is true of any RMAN backup strategy. Recovery is applied when a snapshot is provisioned and any corruption in the logs renders the snapshot and any analogous backups unusable. Also, this can significantly lengthen the time it takes to create a VDB (proportional to the changes on the dSource during the backup interval).

Pre-provisioning shortens provision time and detects log corruption early by performing the recovery step immediately after a new snapshot has been taken. In order to recover a snapshot pre-provisioning requires a host with an Oracle installation that is compatible with the dSource. This machine is known as the staging host.

Any host added to the Delphix Engine can be designated as staging which adds the host to an internal pool of repositories on the Delphix Engine. When pre-provisioning is enabled, the Delphix Engine will search the pool of staging repositories for a machine with a compatible Oracle installation after every dSource snapshot.

If a compatible host exists Delphix will mount the datafiles on the staging source over NFS, start up an Oracle instance that is identical to the dSource, and perform media recovery. After recovery completes Delphix takes a snapshot of the consistent database, shuts down the instance, and unmounts the filesystems from the host.

Snapshots that have been through this pre-processing step do not require recovery during provisioning are marked as consistent in the CLI and tagged with the "Quick Provision" text in the GUI. Provisioning from these snapshots can be faster than provisioning from inconsistent snapshots and any corruptions in the transaction logs are detected when the snapshot is taken instead of when it is used.

If the resources are available enabling pre-provisioning is a win. It decreases provision time and validates snapshots immediately which adds confidence to existing backup strategies.