12c: Database Backups Using ACFS Snapshots

Starting with Oracle Grid Infrastructure 12c (12.1), Oracle Cloud File system (ASM Cluster File System in cluster environment ) supports database files (database version 11.2.0.4 and up) in addition to general purpose files so that entire Oracle databases can be stored inside Oracle Cloud FS and can leverage the Advanced Data Services such as snapshots, tagging and auditing although replication and

Starting with Oracle Grid Infrastructure 12c (12.1), Oracle Cloud File system (ASM Cluster File System in cluster environment ) supports database files (database version 11.2.0.4 and up) in addition to general purpose files so that entire Oracle databases can be stored inside Oracle Cloud FS and can leverage the Advanced Data Services such as snapshots, tagging and auditing although replication and encryption are not supported in conjunction with datafiles.

The ability to perform snapshots of ACFS file system is a very powerful feature. An Oracle ACFS Snapshot is a read-write or read-only, space efficient, point-in-time copy of a file system which is immediately available for use after it is created and is always online while the file system is mounted.

The snapshot copy is initially sparse as it merely references the storage allocation information maintained by the source file system. A snapshot utilizes a Copy-On-Write (COW) technology and maintains point in time view of the file system. Whenever an extent is modified by the user, the current extent is copied to the snapshot before modifying the source file extent. When a recovery is required, only the changed blocks are replaced by their “before images” stored in the snapshot.

For a database having its files stored on Oracle Cloud file system, Oracle ACFS Snapshots may serve as point-in-time backups of the database which can be used for online recovery of database files.

Moreover, with Oracle Database 12c, Cloud FS supports Snaps-of-Snaps feature so that snapshots of existing snapshot of the same ACFS file system may be created. Any combination of read-only and read-write snapshots is supported i.e. a read-write snapshot can be based on an existing read-only snapshot, and a read-only snapshot can be based on an existing read-write snapshot. Each ACFS file system can support a total of 63 snapshots, including Snaps-of-Snaps.

In this article, I will demonstrate the use of new Snaps-of-Snaps feature to quickly revert to the snapshot copy of a database that uses cloud FS to store all its files. Currently I am working in Oracle Database 12.1.0.2 cluster environment.

Overview of Steps:

  • Create a Cloud file system
  • Using DBCA, create a database named cfsdb, with all of its files stored on the cloud file system
  • Check that HR user and its schema exist in cfsdb database
  • Create a read-only snapshot of the cloud FS
  • Drop HR user from database cfsdb
  • Use snaps-of-snaps feature to restore HR user and its schema objects from the snapshot created earlier

Create a Cloud file system

  1. Create mountpoint

  1. Modify the DATA diskgroup to ensure that all the new ADVM features in release 12.1 are enabled.

  1. Create a volume VOL1 in the DATA diskgroup having a size of 5G.

  1. Examine the new volume and take note of the volume device associated with it.

  1. Make a cloud file system on the newly-created volume VOL1 using the volume device identified in step 4.

  1. Mount the ACFS on the mount point created earlier.

  1. Create a new cloud file system resource using the volume device identified above and the mount point created earlier.

  1. Start the new cloud file system.

  1. Confirm that the new file system is mounted.

  1. Modify the access privileges for the new cloud file system to enable access by any user.

  1. Modify the newly created cloud FS to enable full control by members of OS group dba which corresponds to SYSDBA privilege on database instance.

Create a database cfsdb with all its files on the cloud file system

  1. Using DBCA, create a new database “cfsdb”, with all its files on cloud file system and verify its configuration and status.

  1. Verify that controlfiles, redo logfiles and datafiles are created on cloud file system.

Check that HR user and its schema exist in database cfsdb

Create a read-only snapshot of the cloud File System

  1. Verify that the snapshot created above exists and is a read-only snapshot.

Drop HR user from database cfsdb

Use snaps-of-snaps feature to restore HR user and its schema objects from the snapshot created earlier

  1. List the database files and multiplexed control file in the snapshot ro_dbsnap which was taken when HR user existed in the database

  1. Stop database CFSDB

  1. List current database files and multiplexed control file belonging to cfsdb on cloud file system in which HR schema is missing.

  1. Remove the current copy of all the database files and multiplexed control file of database cfsdb

At this stage, we can recover the database to the point in time when HR schema existed by copying the snapshot copies of all the database files into the original locations and restarting the database.

However, we will employ snaps-of-snaps, a 12c new feature, to create a read write snapshot based on the read only snapshot taken earlier and implement a quicker and more flexible solution which would obviate the need to copy the database files.

Let’s see how…

  1. Create a new read write snapshot called rw_dbsnap based on the first read-only snapshot ro_dbsnap

  1. Verify that now we have two snapshots of the file system

  1. Create a link that exposes the writable snapshot database files and multiplexed control file in their original locations.

  1. Verify that database files and multiplexed control file residing inside the writable snapshot rw_dbsnap are exposed in their original locations using the links that we just created.

  1. Restart the cfsdb database.

  1. Check that HR user and objects owned by it have been restored.

At this point, the database is available for full read and write operations. Thus, using snaps-of-snaps feature, we have been able to revert to an earlier point in time without copying database files from the read only snapshot ro_dbsnap.

Extending this functionality further, we can take read only snapshots of the database at various points in time while the database is in use. These snapshots will serve as point in time backups of the database. We can revert to an earlier point in time time by simply taking a read write snapshot of the relevant read-only snapshot and exposing the database files inside the read write snapshot in the original location.

Conclusion

Starting with Oracle Grid Infrastructure 12c (12.1), ACFS supports database files in cluster environment so that entire Oracle databases can be stored inside a cloud file system, although replication and encryption are not supported in conjunction with datafiles. Oracle ACFS Snapshots may serve as the point-in-time backup of the database to be used for online recovery of database files. Using the 12c new snaps-of-snaps feature, we can create read write snapshot based on the read only snapshot and recover the database to an earlier point in time without copying the database files. Here, It is worth mentioning that snapshot is not a replacement for RMAN.