CommVault® Simpana® Software Automates the Generation of Oracle RMAN Scripts; Part 2 of 2

| | Comments (0)

In the first entry in this two-part series, I took a look at how CommVault® Simpana® suite gives administrators the option to use Oracle RMAN scripts in lieu of multiplexing for Oracle® backups that perform as fast as multiplexing without the same drawbacks in recovery. In this second part I continue my discussion with CommVault's Database Practice Manager, Audrey DeNovio, as we examine how Simpana software simplifies the management of Oracle RMAN scripts.

Using Oracle's Recovery Manager (RMAN) to perform database backups is not a new concept as other backup software products support the execution of RMAN scripts. The inherent problem with simply executing RMAN scripts is that this puts the onus on Oracle DBAs to write and test the RMAN scripts prior to the backup software executing them.

Ms. DeNovio tells me that it is not uncommon for enterprise companies to have one or more Oracle DBAs dedicated to creating and managing RMAN scripts. Part of the reason this turns into a time consuming task is that as Oracle releases new versions of its database, the RMAN scripts need to be modified to include the new and improved RMAN features.

To take advantage of these APIs, the Oracle DBAs need to first understand what new features the new version of Oracle RMAN includes, how these are applicable to their environment, adapt their existing RMAN scripts to use them, test them and then implement them. This education and testing process can also result in slowing down needed Oracle upgrades as Oracle DBAs first need to write and test these new scripts with the new version of the Oracle database before it can be upgraded.

CommVault Simpana software automates the generation of Oracle RMAN scripts. It detects the version of the Oracle database in use, it generates the appropriate RMAN scripts needed to support it. In so doing, it minimizes or eliminates the need for Oracle DBAs to write and manage these scripts themselves.

Despite its ability to do this, CommVault still encounters a healthy dose of skepticism from DBAs who are considering using this feature. The fact that CommVault Simpana software generates Oracle RMAN scripts that are used to protect mission critical databases only adds to their skepticism. In these circumstances where CommVault first needs to convince the DBAs, Oracle DBAs can still write their own scripts or use scripts they have already created since the CommVault Simpana software provides a means to schedule and manage these scripts.

That does not mean CommVault has not gained some converts. I spoke to one user who had recently switched from another backup software product to CommVault Simpana software. The major reasons his company decided to switch to Simpana software for its Oracle backups were: It could support existing RMAN scripts; It could automate the generation of new scripts; and, It improved backup success rates. The management and automation of the RMAN scripts saved his company's DBAs precious hours every week in management while using RMAN in lieu of multiplexing increased their weekly success rate from the high 80's to 99%.

Ms. DeNovio describes the inclusion of RMAN APIs within Oracle as creating a level playing field between backup software vendors. RMAN minimizes or eliminates the need for DBAs to rely upon proprietary backup techniques while providing them with both faster backup and recovery capabilities. What RMAN does not provide is a simple method to generate and manage scripts. Since CommVault Simpana software now takes on this task, it provides CommVault with a distinct advantage in Oracle database protection against which all other enterprise backup software platforms should now be measured.

Leave a comment

Entry Sponsorship

This entry is sponsored by CommVault® Systems

About CommVault® Systems Blog

    CommVault® is determined to develop a better paradigm to manage data. A paradigm that would not attempt merely to "integrate" disparate solutions, but would spawn solutions designed to work together from a single, infinitely-adaptable code. A paradigm that would not merely address current data management needs, but that would anticipate and meet needs yet to come. The paradigm would be more accessible, adaptable, flexible and powerful than any data management solution to date. That paradigm is defined as Solving Forward.