Alvin Richards
Database and Grid Architect, Network Appliance

Alvin Richards joined NetApp in 2004 after over 16 years at Oracle. His wealth of database knowledge and experience has allowed him to serve as the leader of a virtual startup organization within NetApp focused on developing applications that allow databases to take full advantage of NetApp technologies. Among other roles, Alvin has served as the development manager, engineering lead, architect, and evangelist for SnapManager® for Oracle®.

---

The below article was originally published in the October 2006 edition of the Tech OnTap newsletter. To receive the newsletter monthly and enjoy other great benefits, sign up today.

Backup and recovery for Oracle Databases is often a complex task, especially in Fibre Channel SAN environments, where there's a whole storage fabric to deal with.

Our primary design goal with SnapManager for Oracle (SMO) was to create a framework that would empower DBAs so that they could easily manage backup and other common storage-related tasks independently from storage or host admin teams. SMO accomplishes this by integrating closely with Oracle tools, including RMAN, RAC, and ASM, to merge the core value of NetApp technology with the task flows that DBAs routinely perform.

As part of my role at NetApp, I frequently meet with customers to explain the inner workings of this application. This article draws on those experiences to explain how SMO decreases capacity requirements for Oracle backups and clones and accelerates backup and data restoration processes, especially in customer environments that are using Oracle Automatic Storage Management (ASM).

Making Oracle Data Management More Efficient

SMO allows DBAs to manage their own data while offloading data management work from Oracle servers to NetApp storage. From a central management system a DBA can, for instance, look at the state of all Oracle backups across multiple databases even if they are running on different servers and operating systems. From the standpoint of a storage administrator, SMO enables the DBA to perform common tasks of backup, restore, and clone without the needing the assistance of the storage administrator.

An SMO repository—similar in principle to an RMAN catalog—stores all the data that SMO needs. Profiles stored in this repository provide the credentials to complete Oracle operations, including:

• Oracle username and passwords (DES encrypted)
• Host and O/S account for each database instance
• RMAN repository connection info
• ASM connection info

With this information securely stored in the repository, a DBA can initiate operations without having to worry about accounts, passwords, and so on. Through the SMO interface, a DBA can execute backups, restores, and clones that leverage proven NetApp technology to achieve extreme time and space efficiency.

Here's how we accomplish this:

Snapshot™ Backup
Integrating Oracle backup capabilities with NetApp Snapshot copies greatly reduces the time it takes to perform a consistent backup. Because NetApp Snapshot copies only preserve changed blocks, they are extremely space efficient. SMO can optionally register the backup with RMAN to ensure not only that RMAN can take advantage of Snapshot backups, but also that the DBA still preserves the unique value of RMAN. This can be important for block-level recovery. Restores can be initiated from RMAN or SMO.

For flexibility, SMO provides the option of either full or partial backups.

• A full backup puts all tablespaces into "hot backup" mode at once, creates Snapshot copies of the associated volumes, returns the tablespaces to normal operation, and then performs a log switch, archives the logs, and makes a Snapshot copy of the archived logs. Full backups use the least Snapshot copies to get the job done, but may keep tablespaces in "backup mode" for a longer period.
• A partial backup does essentially the same thing, but iterates through the tablespaces one at a time. This ensures that each tablespace is in "backup mode" for the shortest possible time, but uses more Snapshot copies since a volume may be used by more than one tablespace.

The option you choose depends on the operating conditions of the application and business processes the DBA is supporting. Having the whole database in backup mode can be bad for a busy database since CPU utilization on the Oracle server increases 10 to 15%, and there is increased I/O since Oracle will write full blocks rather than partial blocks to the logs while in hot backup mode.

A key feature of SMO is that it maps the database contents (data files, archive logs, and so on) each time a backup is created. This means that if you add another data file or tablespace, change the archive log location, and so on, SMO will automatically take this into account each time a backup is performed. No longer do you have to worry whether you have updated your backup script to include that new tablespace or data file.

Restore
In a typical database restore scenario, you have to try one or more backups to get the database back to the exact point in time you require. If you're restoring from tape and you have to check multiple backups, it can take a very long time. SMO allows you to restore very quickly from data stored on disk, so you can quickly choose the backup you need and get up and running much faster.

The SMO restore algorithm uses NetApp Single File SnapRestore® (SFSR) capability to restore the requested parts of the database. If you're using NFS, the number of SFSRs that must be performed is equal to the number of files required to restore the database, and the SFSR operations are carried out in parallel to improve the performance. For an FC or IP SAN, SMO performs an SFSR on each LUN rather than each file, which greatly reduces the number of objects that need to be restored. If the LUN cannot be restored in its entirety, because the LUN contains files that are not pertinent to the database, SMO ensures that just the required files are restored in place into the LUN.

Cloning
One of the common tasks that DBAs ask for is to copy a gold master of a production database for development, testing, or training. DBAs typically spend a lot of time provisioning storage or getting storage provisioned and then copying the data. Using NetApp FlexClone™ technology, SMO can create an instantaneous copy of the database without using any additional physical space (until changes are made to the clone or original). Normally, if you copy a 500GB database, you're going to need 1TB of storage in total right away. FlexClone makes the whole process much more time and space efficient because instead of storing a new physical copy, FlexClone simply stores the changed blocks.

Tight Integration with ASM

One of the key advantages of SMO that differentiates it from any other vendor's management tools is its extremely close integration with Oracle Automatic Storage Management (ASM). ASM is designed to simplify the deployment of Oracle Databases by replacing external volume managers and file systems with Oracle virtualization technology. ASM provides mirror and striping and data load balancing. By understanding the data layout within ASM, SMO delivers the same high level of backup, restore, and cloning capabilities to sites using ASM.

NetApp had three main challenges to solve when it came to integrating SMO with ASM:

• Make consistent Snapshot copies of ASM disk groups even when they span volumes and storage systems
• Provide ability to restore a single file within an ASM disk group
• Clone ASM disk groups

Consistency Groups
ASM has the ability to put disk groups on different volumes or even different storage systems for performance and scalability. In order for SMO to be able to create a consistent backup of a database that spans volumes or storage systems, it has to ensure that all Snapshot copies take place at a single point in time. Consistency groups, introduced in Data ONTAP® 7.2, make this possible.

Partial File SnapRestore
NetApp maps each ASM disk group as an individual LUN or file within the WAFL® (Write Anywhere File Layout) file system. WAFL is a storage virtualization technology that is a part of Data ONTAP. Since an ASM disk group can contain files from more than one database, it's obviously not sufficient in many cases to simply restore the entire disk group.

This challenge was solved using a new NetApp technology that was created for use with SMO: partial file SnapRestore (PFSR). PFSR allows SMO to restore a range of blocks from a Snapshot copy that represents a single Oracle file. This is possible because SMO understands the way Oracle lays out data in ASM. The following diagram shows how the semantic knowledge of the ASM file system allows SMO to restore just the blocks that present the red file using PFSR. The process is extremely efficient and takes place within the NetApp storage system. In laboratory tests, a table with 10 million rows can be restored in 10 seconds versus the two to three minutes required using native RMAN capabilities.



Disk Group Cloning
A general problem associated with block-oriented storage is that LUNs are typically stamped with a unique identifier. If you copy a LUN and introduce it back to the same host, the host will complain because it can't have two LUNs with the same identifier. The same situation holds with ASM. NetApp understands the ASM label and integrates with ASM to create a unique new label for disk groups cloned with FlexClone. This makes it possible for SMO to create a clone of an ASM disk group that can be introduced back to the same host, which allows database clones or backup verifications to be performed on the same host.

More Time for Value-Added Tasks

The key to the success of SMO is the close integration between NetApp and Oracle. Because SMO thoroughly understands Oracle data, the application can coordinate activities to ensure that backups are consistent and integrated with the RMAN catalog. During the development process, we invested a huge amount of our engineering effort to ensuring that we had the right methodologies to deal with possible failure scenarios so that we never leave a database in an unusable state. Even when you introduce ASM virtualization into the mix, NetApp understands the technology and does the right thing to give DBAs the capabilities they need and the results they expect.

With SMO, a DBA can get the basic and time-consuming tasks done quickly and space efficiently, freeing time to focus on high-value tasks such as tuning and capacity planning. The combination of SMO, core NetApp technology, and Oracle ensures that you can do more with less, more quickly.

on October 25, 2006 Alvin spoke at Oracle OpenWorld in San Francisco.

The information in this article is useful to me. 1 2 3 4 5 Strongly Disagree Strongly Agree What other types of information would you like to see included in this article? Additional comments:   Thanks!