Database Solutions EngineeringDisk-to-Disk-to-Tape (D2D2T) There are pros and cons of using either Disk-to-Tape or Disk-to-Disk method as the sole strategy for data protection. Disk

Backup and Recovery of Oracle Databases with Dell EqualLogic PS Series iSCSI Storage Arrays 1

Backup and Recovery of

Oracle® Database on

Dell™

EqualLogic™

PS Series

iSCSI Storage A Dell Technical White Paper

Database Solutions

Engineering

By Wendy Chen and Darren Miller Dell Product Group

March 2009


THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND. © Copyright 2009 Dell, Inc. All rights reserved. Reproduction in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell. Intel and Xeon are registered trademarks of Intel Corporation in the U.S. and other countries; Windows, and Windows Server are either trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries; Oracle is a registered trademark of Oracle Corporation and/or its affiliates.


ABSTRACT .................................................................................................................................................. 5

INTRODUCTION ........................................................................................................................................ 5

DELL SOLUTIONS FOR ORACLE DATABASE ................................................................................................ 5

BACKUP AND RECOVERY STRATEGIES ........................................................................................... 6

DISK-TO-TAPE (D2T) ................................................................................................................................. 6 DISK-TO-DISK (D2D) ................................................................................................................................. 6 DISK-TO-DISK-TO-TAPE (D2D2T) ............................................................................................................. 6

ORACLE BACKUP AND RECOVERY SOLUTIONS ............................................................................ 6

RECOVERY MANAGER (RMAN)................................................................................................................. 6 FLASH RECOVERY AREA ............................................................................................................................ 7 RMAN VS. USER-MANAGED BACKUP ........................................................................................................ 7

DELL EQUALLOGIC SNAPSHOTTM

TECHNOLOGY ........................................................................ 8

OVERVIEW.................................................................................................................................................. 8 USAGE OF EQUALLOGIC SNAPSHOT WITH ORACLE DATABASES ................................................................ 8

Backup .................................................................................................................................................. 8 Recovery................................................................................................................................................ 9

D2D2T ORACLE BACKUP USING EQUALLOGIC SNAPSHOT ....................................................... 9

TEST CONFIGURATION ................................................................................................................................ 9 PRE-REQUISITES ......................................................................................................................................... 9 CREATING SNAPSHOT ................................................................................................................................10 ACCESSING THE SNAPSHOT VOLUMES FROM BACKUP SERVER .................................................................11 MOUNTING ASM INSTANCE ON BACKUP SERVER .....................................................................................11 MOUNTING DATABASE INSTANCE ON BACKUP SERVER ............................................................................12 BACKING UP DATABASE FILES FROM SNAPSHOT DATABASE ....................................................................13 BACKING UP ARCHIVED REDO LOG FILES AND CONTROL FILES FROM PRIMARY DATABASE ...................13 PERFORMANCE IMPACT OF SNAPSHOT .......................................................................................................14

CONCLUSION ............................................................................................................................................17

FIGURES .....................................................................................................................................................18

REFERENCES ............................................................................................................................................18

CONTENTS



Abstract Backup and Recovery is one of the most essential aspects of Oracle database administration. Businesses need to back up important data to protect themselves against various types of failures. During backup, copies of the Oracle data are made so that these copies may be used to restore the original in the event of a data loss or disaster. With staggering growth rate of database sizes in recent years, and need for 24x7 availability of database applications, many businesses are re-examining their backup and recovery strategies in order to meet service level agreements (SLAs). To address this challenge, this white paper describes a snapshot-based Oracle database backup and recovery solution using Dell EqualLogic™ PS Series iSCSI storage which can improve the backup and recovery time and help the IT administrator meet SLAs.

Introduction The Dell EqualLogic PS Series iSCSI storage arrays provide primary and secondary storage capacity to a wide variety of applications with enterprise-class performance and low-cost of ownership. The PS Series storage arrays are the ideal choices to deploy highly reliable and sustainable Oracle databases. By delivering the benefits of consolidated networked storage in a self-managing iSCSI Storage Area Network (SAN), the PS Series storage is easy to use and affordable. Build on a patented peer storage architecture where all arrays in a storage pool are designed to work together to provide disk capacity and evenly distribute the load, the PS Series SAN offers high performance, reliability, scalability, intelligent automation, simplified deployment, and comprehensive data protection. The PS Series storage arrays include advanced software to provide snapshot, replication, and other features with no additional cost. These features allow Oracle data to be easily and readily replicated for data protection and business continuity. This white paper is intended to provide a set of best practices and procedures on the backup and recovery of Oracle 10g and 11g database using Dell EqualLogic PS Series iSCSI storage-based replication technologies. This white paper documents the Dell recommended approach for implementing such a solution.

Dell Solutions for Oracle Database Dell Solutions for Oracle Database are designed to accelerate deployment, simplify operations, and cost-effectively scale as your needs grow over time. In addition to providing server and storage hardware, Dell solutions for Oracle include:

Dell Configurations for Oracle – in-depth testing of Oracle configurations for high-demand solutions; documentation and tools that help simplify deployment

Integrated Solution Management – standards-based management of Dell Solutions for Oracle that can lower operational costs through integrated hardware and software deployment, monitoring, and updating

Oracle Licensing – multiple licensing options that can simplify customer purchase

Dell Enterprise Support and Infrastructure Services for Oracle – including offerings for the planning, deployment and maintenance of Dell Solutions for Oracle Database

For more information concerning Dell Solutions for Oracle Database, please visit www.dell.com/oracle.

http://www.dell.com/oracle


Backup and Recovery Strategies

Disk-to-Tape (D2T) Backup-to-tape and restore-from-tape are the traditional approach to data recovery. Historically, tape drives have been the most commonly used backup media. In an enterprise environment, data is typically backed up to centralized and shared tape libraries on a LAN or SAN. Tape drives are affordable and transportable. However, tape imposes performance limits to both backup and recovery operations due to the reason that tape uses a sequential method to read and write data.

Disk-to-Disk (D2D) With rapidly falling disk prices and availability of high capacity disk drives, many businesses now use disks as the storage media for their backup purposes. Benefitting from the random access nature of disk drives, the performance of backup and recovery operations can be improved through backup-to-disk and restore-from-disk.

Disk-to-Disk-to-Tape (D2D2T) There are pros and cons of using either Disk-to-Tape or Disk-to-Disk method as the sole strategy for data protection. Disk backup addresses the performance challenges facing the tape backup solution. However, unlike tapes, disks are not easily transportable and face difficulties in long term archival and off-site media storage for disaster recovery. As a result disk backups typically complement rather than replace tape backups. The disk-to-disk-to-tape (D2D2T) backup procedure combines Disk-to-Disk and Disk-to-Tape and leverages the strengths of both disks and tapes. In a Disk-to-Disk-to-Tape solution, data is initially copied to disk media which serves as a staging area for short term data storage. Then data is copied again from the disk staging area to tape media for long term data retention. The Disk-to-Disk-to-Tape solution benefits from the fast Disk-to-Disk backup performance, while fulfilling the requirements of retaining data for long term archiving.

Oracle Backup and Recovery Solutions

Recovery Manager (RMAN) The Recovery Manager (RMAN) utility manages the Oracle database backup and recovery. RMAN allows the backup of database files, control files, and archived redo logs to either disk or to tape. RMAN stores the RMAN activities in the database control file. Optionally, a recovery catalog, which resides in a secondary database known as the catalog database, can be used to record RMAN activities against target databases. The use of a recovery catalog is recommended for enterprise environment. Moreover, in a situation where all control file copies are lost, RMAN can re-create control files from the information contained in the recovery catalog. Oracle database can run in two modes: ARCHIVELOG mode or NOARCHIVELOG mode. In ARCHIVELOG mode, a used online redo log group must be copied to one or more archive destinations before it can be reused. Archiving the redo log preserves all transactions stored in that log, so that they can be used in recovery operations later. In NOARCHIVELOG mode, the online redo log groups are simply overwritten when the log is reused. All information about transactions recorded in that redo group is lost.


Running database in NOARCHIVELOG mode imposes severe limitations on backup and recovery strategy. Backup operations cannot be performed on an online database with NOARCHIVELOG mode. Oracle database must be shut down cleanly before taking a backup in NOARCHIVELOG mode. This is also called an offline backup and it is generally unacceptable in today’s 24x7 global environment. On the other hand, ARCHIVELOG mode enables online backup and has more flexible recovery options such as point-in-time recovery. Therefore, running database in ARCHIVELOG mode is preferable to running NOARCHIVELOG mode.

Flash Recovery Area The Flash Recovery Area is a disk-based recovery area that can be used to store Oracle recovery files including full or incremental datafile backups, control file backups, archived redo logs, block change tracking files and flashback logs. Oracle automatically deletes these files within the Flash Recovery Area when they are superseded or archived to offline storage devices. One of the important purposes of Flash Recovery Area is to store the flashback logs used by Oracle Flashback Technology. In Oracle 10g and 11g, Flashback Technology offers the following capabilities to provide fast and easy recovery to undo errors.

Flashback Database: rewinds an Oracle database to a previous point in time.

Flashback Table: restores the state of one or more tables to a previous point in time.

Flashback Drop: restores dropped tables, indexes, constraints, triggers, etc.

Flashback Query: recovers deleted or changed data.

Flashback Versions Query: retrieves the different versions of rows in a given table in a time interval.

Flashback Transaction: reverses the effects of erroneous transactions.

RMAN vs. User-Managed backup

There are two methods for creating Oracle database backups: RMAN based backup solution and user-managed backup solution. The user-managed backup and recovery refers to the use of mechanisms outside of RMAN such as storage technologies, operating systems file copies or third-party utilities. Both RMAN backup solution and user-managed backup solution are supported by Oracle and are fully documented.

The user-managed backup can be performed with either an offline database or an online database. In order to provide 24x7 database accesses to support global business, IT organizations can no longer afford any database downtime for backup operations. To address this demand, Oracle provides a feature called hot backup mode which allows making user-managed backup copies of an Oracle database while it is open. Database needs to be put in hot backup mode prior to the backup operation, and taken out of hot backup mode after the backup operation. Oracle requires database configured in ARCHIVELOG mode in order to perform hot backup. The Oracle backup solution introduced in the paper is a hybrid user-managed and RMAN managed D2D2T backup solution. Using this solution, Oracle data is first backed up to disk via the user-managed hot backup method with Dell EqualLogic snapshot technology. Then the snapshot volumes are mounted as an Oracle database instance on a remote backup server, and Oracle data is again backed up to tape via the RMAN managed backup method.


Dell EqualLogic SnapshotTM

Technology

Overview The Dell EqualLogic PS Series storage array includes built-in software to support storage level, hardware snapshots at no additional cost. PS Series snapshots are space efficient as they capture the contents of a source volume at a specific point in time using pointers to the source volume data. Reserve space is used to hold the differences or deltas between the original source volume data and the snapshot data for any subsequent writes. The snapshot copy is created instantly, usually in a few seconds, with minimal impact to the source volumes. Snapshots can be used for recovery as well as backup purposes. Like source volumes, snapshots appear on the network as iSCSI targets and can be set online and accessed by hosts with iSCSI initiators. As with source volumes, host access to snapshots is controlled through access control records. PS Series arrays allow up to 512 snapshots per source volume, which is sufficient space to allow snapshots taken at 30-minute intervals to be maintained for over 10 days. Since, snapshots are pointer based copies of source volumes they can protect source volumes against logical corruption of the database or human errors. However, snapshots cannot protect source volumes from hardware failures at the storage level. Therefore, it is a best practice to create a permanent physical copy of the snapshots by periodically backing up snapshot images to tape.

Usage of EqualLogic Snapshot with Oracle Databases

Backup The PS Series snapshot allows to quickly backup and restore large Oracle databases online with minimum performance impact. Snapshot is capable of making an instantaneous point-in-time copy of an Oracle database. Thus it reduces the backup window to virtually zero. An Oracle database typically spans multiple volumes, and if snapshot is taken on each volume individually, the contents of one volume might not be content-consistent with other volumes. The EqualLogic snapshot collection feature can help address this issue. A collection is a set of volumes grouped together for snapshot that represent content-consistent data at a particular point in time. Collection allows creating a snapshot of 2 or more volumes at the same time by placing them in the same collection. EqualLogic snapshot complements the Oracle Flash Recovery Area. Like the Oracle Flash Recovery Area, snapshot is another disk-based backup solution and it enables instant Oracle database backup and quick recovery. On the other hand, Oracle Flash Recovery Area allows recovery not just at the database level, but at a more granular level given its capability to roll back individual tables, dropped objects, transactions and table rows. The high level steps of creating a snapshot of an Oracle 10g or 11g database can be:

1. Put database in hot backup mode via SQL command. SQL> alter database begin backup;

2. Create snapshot of all database volumes as in a collection. 3. End database host backup mode via SQL command:

SQL> alter database end backup; 4. Archive the online redo logs so that the redo required for recovery will be available.

SQL> alter system archive log current;


Recovery

During the restore process, reconstructing the contents of an Oracle database typically involves two phases:

Restore: the point-in-time copy of the database image is first retrieved from a snapshot backup.

Recover: the transactions since the snapshot backup that are recorded in the archived redo logs and online redo logs are applied to the database to bring it to a desired point with transaction-consistent state.

On EqualLogic PS Series iSCSI Storage Snapshots can be taken frequently given the small performance hit. Therefore there are less redo logs to apply during the database recovery and it shortens the downtime in the event that data needs to be recovered from a backup.

D2D2T Oracle Backup using EqualLogic Snapshot

Test Configuration Dell engineers tested and validated a Disk-to-Disk-to-Tape Oracle backup solution with the EqualLogic Snapshot. An architecture overview of the solution is shown in the following Figure 1.

Figure 1 - Architectural Overview of Oracle 10g or 11g D2D2T Backup with Dell EqualLogic PS

Series iSCSI Storage

The architecture is comprised of the following components:

Dell PowerEdge servers running Microsoft Windows Server 2003 R2 with SP2 and Oracle 11g R1 Real Application Cluster (RAC) database version 11.1.0.6 or Oracle 10g R2 RAC database version 10.2.0.3.

Redundant Dell Gigabit Ethernet switches for Oracle cluster interconnect network

Server-storage interconnect using redundant Dell PowerConnect™ Gigabit Ethernet switches

Three Dell EqualLogic PS Series iSCSI storage arrays where the physical data resides.

Dell PowerEdge server as backup server running Microsoft Windows Server 2008

Dell PowerVault ML6000 tape library

A centralized RMAN Recovery Catalog database to record RMAN activities

Pre-requisites


The backup server attaches to the tape library. Media management software is installed on the backup server to interface with the tape devices and to transmit data for read and write. Prior to the first backup of an Oracle database via Dell EqualLogic snapshot, the following tasks need to be performed.

Install Oracle software, which is the same version as the Oracle software on the database server, on the backup server. The backup server also needs to have the same Operating System installed as on the database server. The Oracle database as well as the ASM instance will be mounted as a single instance database on the backup server.

Install iSCSI interfaces, such as standard NIC cards or iSCSI HBA’s, on the backup server. Physical connections should be established for the backup server to access snapshots stored in the EqualLogic storage systems. The EqualLogic volume Access Control List should grant backup server access to its snapshots.

Copy the database configuration files to the backup server in appropriate locations. These configuration files include the ASM instance init.ora initialization parameter file, the ASM instance password file, the database instance init.ora initialization parameter file, and the database instance password file. If the primary Oracle database is a RAC clustered database, any RAC related initialization parameters should be removed from both ASM and database init.ora files, because the database will be mounted as a single instance database on the backup server.

If the backup server runs on Windows Operating Systems, create an ASM instance service and a database instance service using the ORADIM utility.

Register the primary Oracle database in the RMAN recovery catalog prior to the first backup operation.

Do not configure auto backup controlfile, which is the default setting. The controlfile of the database, which is mounted from the snapshots on the database server, will be converted to a backup controlfile which will be described in the succeeding sections. If auto backup controlfile is configured, RMAN backup will raise an error as Oracle cannot back up a backup controlfile.

Creating Snapshot This section provides a detailed illustration of the snapshot creation process for the Oracle RAC database shown in Figure 1. The example Perl script in this section initializes the backup process by performing the following steps:

1. Take the database into hot backup mode. 2. Create a snapshot of all database volumes as in a collection. 3. Take the database out of hot backup mode. 4. Archive the current online redo logs.


# cr_oracle_snapshot.pl # This script take a snapshot of Oracle database volume collection while database is in hot # backup mode. # Usage: perl cr_oracle_snapshot.pl

use Net::Telnet (); use DBI; $GROUP='10.16.7.100'; # IP address of EqualLogic group $ACCNT='grpadmin'; # EqualLogic CLI login user name $PASSWD='Oracle'; # EqualLogic CLI login password $COLLECTION='eqracwt-collection'; # Volume collection name $SNAPNAME='test'; # Volume collection snapshot name $DESCRIPTION='testing'; # Volume collection snapshot description $TNSALIAS='eqracwt1'; # Primary database TNS alias $USERNAME='system'; # Primary database user name $PASSWORD='oracle'; # Primary database password $SQL1=qq{ alter database begin backup }; # SQL statement to begin hot backup mode $SQL2=qq{ alter database end backup }; # SQL statement to end hot backup mode $SQL3=qq{ alter system archive log current }; # SQL statement to end hot backup mode # connect to primary database, put database in hot backup mode, and disconnect database session $dbh = DBI->connect('dbi:Oracle:'.$TNSALIAS, $USERNAME, $PASSWORD, ) || die "Database connection not made: $DBI::errstr"; $dbh->do($SQL1); $dbh->disconnect; # connect to EqualLogic CLI and take snapshot of volume collection $t = new Net::Telnet (Timeout => 10); $t->open($GROUP); $t->login($ACCNT, $PASSWD); @lines = $t->cmd("snapcol create $COLLECTION $SNAPNAME description $DESCRIPTION"); print @lines; # connect to primary database, end database hot backup mode, archive current redo log, and disconnect database session $dbh = DBI->connect('dbi:Oracle:'.$TNSALIAS, $USERNAME, $PASSWORD, ) || die "Database connection not made: $DBI::errstr"; $dbh->do($SQL2); $dbh->do($SQL3); $dbh->disconnect;

Accessing the Snapshot Volumes from Backup Server Backup server’s access to snapshot volumes should be configured via the iSCSI software initiator in the case that the standard NIC interfaces are used. If hardware iSCSI HBA’s are used, use the appropriate tools to configure host access to snapshot volumes.

Mounting ASM Instance on Backup Server

As described in the “Pre-requisites” section above, the ASM instance init.ora initialization parameter file and the ASM instance password file should be copied to the appropriate locations on the backup server. Any RAC related initialization parameters should be removed from the init.ora file, because the ASM instance will be mounted as a single instance ASM database. The sample steps below starts up an ASM instance on backup server running with Windows Operating Systems.


1. Set the ORACLE_SID environment variable to +ASM. set ORACLE_SID=+ASM

2. Set the ORACLE_HOME environment variable to the location of ORACLE_HOME.

set ORACLE_HOME=[path of ORACLE_HOME]

3. Log into the ASM instance via SQL*Plus, and startup the ASM instance.

sqlplus / as sysdba SQL> startup;

4. Verify all ASM diskgroups are mounted using SQL command. All diskgroups should return “MOUNTED” status in the following query.

SQL> select name, status from v$asm_instance;

Mounting Database Instance on Backup Server Similar to the ASM instance, the database instance init.ora initialization parameter file and the database instance password file should be copied to the appropriate locations on the backup server. Any RAC related initialization parameters should be removed from the init.ora file, because the database instance will be mounted as a single instance database.

1. Set the ORACLE_SID environment variable to the SID of database instance. set ORACLE_SID=[SID of database instance]

2. Set the ORACLE_HOME environment variable to the location of ORACLE_HOME.

set ORACLE_HOME=[path of ORACLE_HOME]

3. Log into the database instance via SQL*Plus, and start up mount the database instance.

sqlplus / as sysdba SQL> startup mount;

The snapshot volumes contain copies of controlfiles which are current controlfiles. As documented in Oracle MetaLink document ID # 302615.1 on instructions of RMAN backup with snapshot technologies, we do not want the copy of the controlfile from snapshot volumes to be capable of full resync with the recovery catalog. When snapshot copy of the database instance is initially mounted on the backup server, the status of its controlfile is CURRENT. MetaLink note # 302615.1 provides the following procedures to convert this controlfile to a type BACKUP.

4. The type of the controlfile on the snapshot volumes is initially CURRENT. This SQL query confirms it.

SQL> select controlfile_type from v$database;

5. Run the following SQL statement to convert the controlfile type to BACKUP.

SQL> recover database using backup controlfile until cancel; Enter cancel at the prompt.


6. Shutdown database.

SQL> shutdown;

7. Start up mount the database instance.

SQL> startup mount;

8. Confirm the type of the controlfile is converted to BACKUP.

SQL> select controlfile_type from v$database;

Backing Up Database Files from Snapshot Database The database files can be easily backed up from the snapshot database. The sample RMAN script below connects to the snapshot and the RMAN catalog, and issues a level 0 full database backup. The media management software used in this example is Symantec Backup Exec. Similar to the traditional RMAN backups, full database backup should be scheduled at the regular basis, e.g., on a daily basis. rman.exe target / catalog <username>/<password>@<RMAN catalog TNS alias>

RUN { ALLOCATE CHANNEL ch0 TYPE 'SBT_TAPE'; BACKUP INCREMENTAL LEVEL=0 FORMAT 'BE_U'DATABASE; RELEASE CHANNEL ch0; }

Backing Up Archived Redo Log Files and Control Files from Primary Database As discussed earlier, the controlfiles on the snapshot database have converted to backup controlfiles. Therefore, the controlfiles should be backed up from the primary database, along with the archived redo log files. The sample RMAN script below connects to the primary database and the RMAN catalog database, and backs up all archived redo logs and the controlfile. Similar to the traditional RMAN backups, archived redo log backup should be executed at a more frequent schedule such as every 2 hours. To ensure the archived log destination is not filled up, the RMAN script removes the archived redo logs once they are backed up. rman.exe target / catalog <username>/<password>@<RMAN catalog TNS alias>

RUN { ALLOCATE CHANNEL ch0 TYPE 'SBT_TAPE'; BACKUP FORMAT 'BE_U'ARCHIVELOG ALL FORCE NOT BACKED UP DELETE INPUT; BACKUP CURRENT CONTROLFILE FORMAT 'BE_U'; RELEASE CHANNEL ch0; }


Performance Impact of Snapshot Dell engineers conducted lab testing to study the performance impact of the PS Series snapshot on an Oracle database. The Quest Benchmark Factory TPC-C tool was utilized to stress the database by simulating real database application workload using industry standard TPC-C benchmark. Figure 2 illustrates the effect of snapshots on disk response times during a TPC-C run performed at 2000 user load for 30 minutes. During this run, 4 snapshots were taken at regular intervals. As shown in the graph, there is an initial increase in disk response times as soon as a snapshot is taken. However, the disk response times return to the baseline very quickly (within one minute), indicating that subsequent disk activity will not experience the response time latency associated due to snapshots. Please also note that the effect on disk response times is similar even when multiple snapshots of the source volumes are active at the same time. Throughout the entire test run, the disk response times stay well within the acceptable range. During another TPC-C run of approximately 3 hours, while increasing user load at regular intervals (every four minutes), eight snapshots of Oracle database source volumes were taken each at user load 500, 1000, 1500, 2000, 2500, 2800, 3100, and 3400. The impact of these snapshots on application performance is shown with red dots in Figure 3 and Figure 4.

Figure 2 Impact of Dell EqualLogic Snapshots on Disk Response Times during Quest Benchmark

Factory TPC-C test Figure 3 shows the Transaction per Second (TPS) of the TPC-C run as user load increases. As shown in this graph, multiple PS Series snapshots of the source database volumes have no measurable impact on TPS performance during this run.

Dis

k R

esp

on

se t

ime

Elapsed time (minute)

Inpact of Snapshots on Disk Response Time


Figure 3 - Performance Impact of Dell EqualLogic Snapshot on TPS during Quest Benchmark

Factory TPC-C test

Figure 4 shows the Average Transaction Response Time in second as user load increases from 100 users to 3500 users in this TPC-C run. As illustrated by the trend of blue dots in Figure 4, the average transaction response time increases with user load. However, as shown by the red dots in the graph, for those user loads when snapshots of the source Oracle volumes are taken, the transaction response times go up for a brief period (approximately one minute) but return to the normal trend.


Figure 4 - Performance Impact of Dell EqualLogic Snapshot on Average Transaction Response Time

during Quest Benchmark Factory TPC-C test

This study demonstrated that the PS Series snapshot imposes very minimal performance hit on an Oracle database under stress. The PS Series snapshot can be taken at a frequent interval without any measurable impact on the production application performance. Consequently, in the event of a recovery, a small number of archived redo logs need to be applied which reduce the mean time to recovery (MTTR).

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2

0 500 1000 1500 2000 2500 3000 3500 4000

Ave

rage

Txn

Re

spo

nse

Tim

e (

sec)

User Load

Performance Impact of Snapshots on TPCC Response Time


Conclusion With high data growth rates and 24x7 uptime requirements of database applications, backup and recovery of large Oracle databases has become a challenging task. This paper describes an Oracle data protection solution that utilizes the Dell EqualLogic PS Series iSCSI storage snapshot technology to provide quick backup and recovery with very little performance impact on production application. This paper also provides best practices and detailed instructions on how to implement this solution. To learn more about Dell Oracle solutions, please visit www.dell.com/oracle or contact your Dell representative for up to date information on Dell servers, storage and services for Oracle solutions.

http://www.dell.com/oracle


Figures Figure 1 - Architectural Overview of Oracle 10g or 11g D2D2T Backup with Dell EqualLogic PS Series iSCSI Storage ....................................................................................................................... 9 Figure 2 Impact of Dell EqualLogic Snapshots on Disk Response Times during Quest Benchmark Factory TPC-C test ........................................................................................................................ 14 Figure 3 - Performance Impact of Dell EqualLogic Snapshot on TPS during Quest Benchmark Factory TPC-C test ........................................................................................................................ 15 Figure 4 - Performance Impact of Dell EqualLogic Snapshot on Average Transaction Response Time during Quest Benchmark Factory TPC-C test ...................................................................... 16

References 1. “PS Series Groups Backup and Recovery Overview”, a Dell EqualLogic white paper.

http://www.equallogic.com/psp/PDF/tr1004-backup-and-recovery-overview.pdf

2. “Backup and Recovery Basics”, 10g Release 2 (10.2), B14192-03. http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192.pdf

3. “Backup and Recovery Advanced User’s Guide”,10g Release 2 (10.2), B14191-03. http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191.pdf

4. “RMAN and split mirror disk backups”, Oracle MetaLink document ID # 302615.1. http://metalink.oracle.com

5. PS Series Technical Resource Library http://www.equallogic.com/resourcecenter/default.aspx?id=6581

http://www.equallogic.com/psp/PDF/tr1004-backup-and-recovery-overview.pdf

http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192.pdf

http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191.pdf

http://metalink.oracle.com/

http://www.equallogic.com/resourcecenter/default.aspx?id=6581

Documents

Database Solutions EngineeringDisk-to-Disk-to-Tape (D2D2T) There are pros and cons of using either Disk-to-Tape or Disk-to-Disk method as the sole strategy for data protection. Disk