CommVault®'s Simpana® Suite Maximizes Oracle Capabilities to Eliminate Multiplexing Backups

As corporate databases continue to demand more availability and performance, similar evolutions in operations have occurred, specifically in the emergence of pairs or groups of clustered servers that met these demands. These evolutions have opened the door for the introduction of Oracle RAC (Real Application Clusters) so that database applications could run concurrently on multiple servers and take advantage of the additional processing power without creating database corruptions or inconsistencies.

Despite these advances, support for these new Oracle features is not so clearly evidenced in backup software designed to support Oracle. Two major deficiencies found in backup software is its heavy reliance upon multiplexing to backup Oracle databases and its inability to use more than one node in an Oracle RAC Environment to backup the Oracle database.

Recently I had the opportunity to discuss these specific challenges that backup and recovery software is facing with CommVault's Database Practice Manager, Audrey DeNovio, and how the CommVault® Simpana® product deals with them.

Ms. DeNovio says that in customer environments, when it comes to backing up and recovering Oracle databases, it always comes down to performance. Many companies still backup their large Oracle databases (500 GB+) to tape because so much disk is required for these backups. This puts backup software under the gun to stream data to a tape drive fast enough to complete the database backup within the application backup window.

To accomplish this, most backup software resorts to combining, or multiplexing, the backup streams in order to keep the data flow consistent and fast enough to satisfy these requirements. Using multiplexing, backup software would combine the data streams of 2, 3 or more backup streams from different Oracle backups into one. On the tape, the data from the various data streams is then interleaved.

The downside of this is that recovery times are increased by about the same multiple as the number of data streams that the backup software combines. To get to the data for one Oracle client, the backup software would need to sequentially read through all of the data for all the clients interleaved together on the same tape. So in a case where three backup streams are multiplexed into one data stream, recovery times are multiplied by about a factor of three.

To address this, CommVault took an important step in differentiating how CommVault Simpana protects Oracle databases from other backup and software products. Though the Simpana suite also supports multiplexing, the underlying Simpana architecture works more efficiently to handle data and avoid the need to multiplex at all - and still keep the tape devices spinning as fast as possible. The secret sauce in this is the architecture of the Simpana Media Agent and its efficiency in managing data from RMAN to the tape device. Using a single backup data stream, Simpana can recover data from tape as fast as it can back it up.

Yet how CommVault Simpana integrates with Oracle's RMAN APIs goes beyond just calling RMAN's APIs; it also automates the generation and management of RMAN scripts as well as takes advantage of processing of situations where clustered servers are present. What and how CommVault Simpana software does this will be examined in part 2 of this series.