NetApp SnapShot Technology

A few years ago I was introduced to the NetApp storage technology and it’s backup, clone, DR capabilities and etc. To be honest at the beginning I didn’t feel very confident on how would that work with Oracle internals and particularities like SCN, archived logs and others.

After several testing and trying different scenarios I had my first database in production using NetApp and just to add a bit of complexity it was a RAC database.

Well, It actually works very well. The FlexClone capability is awesome to replicate production data for testing and other purposes. SnapShot for local backup are amazing fast and SnapMirror and SnapValt for DR are just what I need.

NetApp has now SnapValidator which is what was missing for block corruption check.

Below is some information about SnapShots from NetApp man pages.

The snap family of commands provides a means to create and manage snapshots in each volume.
A snapshot is a read-only copy of the entire file system, as of the time the snapshot was created. The filer uses a copy-on-write technique to create snapshots very quickly without consuming any disk space. Only as blocks in the active file system are modified and written to new locations on disk does the snapshot begin to consume extra space.

Snapshots are exported to all CIFS or NFS clients. They can be accessed from each directory in the file system. From any directory, a user can access the set of snapshots from a hidden sub-directory that appears to a CIFS client as ~snapshot and to an NFS client as .snapshot. These hidden sub-directories are special in that they can be accessed from every directory, but they only show up in directory listings at an NFS mount point or at the root of CIFS share.

Each volume on the filer can have up to 31 snapshots at one time. Because of the copy-on-write technique used to update disk blocks, deleting a snapshot will generally not free as much space as its size would seem to indicate. Blocks in the snapshot may be shared with other snapshots, or with the active file system, and thus may be unavailable for reuse even after the snapshot is deleted.

The snap commands are persistent across reboots. Do not include snap commands in the /etc/rc. If you include a snap command in the /etc/rc file, the same snap command you enter through the command line interface does not persist across a reboot and is overridden by the one in the /etc/rc file.

Automatic snapshots
Automatic snapshots can be scheduled to occur weekly, daily, or hourly. Weekly snapshots are named weekly.N, where N is “0” for the most recent snapshot, “1” for the next most recent, and so on. Daily snapshots are named daily.N and hourly snapshots hourly.N. Whenever a new snapshot of a particular type is created and the number of existing snapshots of that type exceeds the limit specified by the sched option described below, then the oldest snapshot is deleted and the existing ones are renamed. If, for example, you specified that a maximum of 8 hourly snapshots were to be saved using the sched command, then on the hour, hourly.7 would be deleted, hourly.0 would be renamed to hourly.1, and so on.

Command Options:

snap list [ vol_name ]
snap create vol_name name
snap delete vol_name name
snap rename vol_name from to
snap reserve [ vol_name [ percent ] ]
snap restore [ -f ] [ -t vol | file ] [ -s snapshot_name ] [ -r restore_as_path ] vol_name | restore_from_path
snap sched [ vol_name [ weeks [ days [ hours[@list] ] ] ] ]

Source from this post: NetApp man pages


NetApp Storage Management Tools for Oracle

Snapshot and FlexClone

Several of the capabilities of NetApp storage contribute to the ease of Oracle data management in NFS environments. NetApp Snapshot copies are space-efficient, point-in-time copies that can be created in a matter of seconds. To create an Oracle backup, you only need to put the database in hot backup mode for a few seconds while a Snapshot copy is being created. The impact to operations is usually negligible, so most DBAs schedule multiple Snapshot copies throughout the day as a safety net. You can retain up to 255 Snapshot copies of each storage volume and restore individual files from previous Snapshot copies or revert to a previous copy if a problem occurs.

Typically, IT shops using Oracle keep a number of Snapshot copies on primary storage to meet immediate needs. Snapshot copies can also be copied to secondary storage using NetApp SnapVault®, mirrored to a remote disaster recovery site using SnapMirror®, backed up to tape, or any combination of these options—whatever is necessary to meet data protection requirements. Because these operations occur on the storage system, there is no impact to running Oracle applications.

NetApp FlexClone® is another option that has proven to be highly useful in Oracle and other database environments. FlexClone allows you to create a writeable clone of any data volume. New disk space is consumed only as the original volume and the clone deviate from each other. This means that you can easily clone production data for test and development, data mining, or other purposes without the typical 2X storage requirement. As with Snapshot, you can create up to 255 FlexClone volumes of a single volume. (A recent Tech OnTap case study described the use of FlexClone to streamline Oracle application development and test.)

NetApp has also created a number of value-added software tools specifically for Oracle environments. 

SnapManager for Oracle

SnapManager® for Oracle is a management tool that simplifies the management of Oracle backup and recovery. It works across all storage protocols and integrates closely with Oracle ASM and RMAN. SnapManager for Oracle makes it easy to schedule the creation of consistent Snapshot copies and FlexClone volumes, enabling operations that previously required complicated scripts to be accomplished with a few clicks or scheduled for regular execution.

SnapValidator for Oracle

In rare fault conditions, data can get corrupted on the data path between server and storage. Oracle keeps a checksum on each block so that this corruption is detected, but in many cases it may be months before data is actually reread and checked, resulting in the need to recover from a very old backup. To address this issue, SnapValidator® for Oracle complies with the Oracle hardware assisted resilient data (HARD) initiative to verify the checksum and block offset every time a block is written. When a problem is detected the write is failed, forcing the server to repeat the write so that no restore is required.This feature works particularly well with NFS. Traditional host file systems cannot support HARD validation due primarily to the mixture of database blocks and file system metadata in writes to the storage system. Under Oracle 9i, HARD validation is practical only for raw disk and NFS; Oracle 10g extended that capability to Oracle ASM.

SnapLock Integration with Oracle

Oracle includes partitioning and transportable tablespace capabilities that make it possible to relocate subsets of your data to different storage. SnapLock® integration makes it possible to relocate content and messages from Oracle to write once, read many (WORM) volumes. This ensures that the data cannot be modified, helping to meet the requirements of Sarbanes-Oxley (SOX), HIPAA, and other regulatory guidelines. This feature is particularly advantageous with NFS because of the finer level of granularity that NFS provides; you can choose to use SnapLock on a particular file or sets of files. In a SAN environment, you would have to use SnapLock on an entire LUN.