EMC Backup and Recovery for Oracle Database 11g Without ... · PDF fileOracle metalink note ... Oracle Database version 9.2.0.1 and later releases on a variety of operating system

EMC Backup and Recovery for

Oracle Database 11g Without Hot Backup Mode using DNFS and

Automatic Storage Management on Fibre Channel

A Detailed Review

EMC Information Infrastructure Solutions

Abstract

This white paper demonstrates that the EMC snapshot technologies — SnapView™ on EMC® CLARiiON® CX4-480 and SnapSure™ on Celerra® NS-480 — work well without putting the database into hot backup mode. Also, a performance comparison is made between backup with and without hot backup mode.

November 2010

EMC Backup and Recovery for Oracle Database 11g without Hot Backup Mode using DNFS and

Automatic Storage Management on Fibre Channel—A Detailed Review 2

Copyright © 2010 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com

All other trademarks used herein are the property of their respective owners.

Part number: H8055

EMC Backup and Recovery for Oracle Database 11g without Hot Backup Mode using DNFS and Automatic Storage Management on Fibre Channel—A Detailed Review

3

Table of Contents

Executive summary ........................................................................................................................... 5 Business case ............................................................................................................................... 5 Solution overview .......................................................................................................................... 5 Key results ..................................................................................................................................... 6

Introduction ....................................................................................................................................... 7 Purpose ......................................................................................................................................... 7 Scope ............................................................................................................................................ 7 Audience ....................................................................................................................................... 7 Terminology ................................................................................................................................... 7

Technology overview ........................................................................................................................ 9 Introduction .................................................................................................................................... 9 EMC CLARiiON storage array ...................................................................................................... 9 EMC Celerra unified storage platform ........................................................................................... 9 EMC Replication Manager .......................................................................................................... 10 EMC SnapSure ........................................................................................................................... 11 EMC SnapView ........................................................................................................................... 11 Disk drives ................................................................................................................................... 12 Oracle software stack .................................................................................................................. 13

Configuration ................................................................................................................................... 14 Overview ..................................................................................................................................... 14 Environment profile ..................................................................................................................... 14 Physical environment .................................................................................................................. 14 Storage layout ............................................................................................................................. 15 Network architecture ................................................................................................................... 17 Hardware resources .................................................................................................................... 17 Software resources ..................................................................................................................... 17

Test and validation .......................................................................................................................... 19 Introduction .................................................................................................................................. 19 Storage-based replication (hot backup mode) of Oracle single-instance database on CX4-480 ................................................................................................................................. 19 Storage-based replication (without hot backup mode) of Oracle single-instance database on CX4-480 ................................................................................................................................. 22 Storage-based replication of Oracle single-instance .................................................................. 25 database on CX4-480 conclusion ............................................................................................... 25 Storage-based replication (hot backup mode) of Oracle single-instance database on NS-480 . 26 Storage-based replication (without hot backup mode) of Oracle single-instance database on NS-480 ........................................................................................................................................ 29 Storage-based replication of Oracle single-instance database on NS-480 conclusion .............. 33

Conclusion ...................................................................................................................................... 34 Summary ..................................................................................................................................... 34



Key points .................................................................................................................................... 34 Next steps ................................................................................................................................... 35

References ...................................................................................................................................... 36 White papers ............................................................................................................................... 36 Oracle metalink note ................................................................................................................... 36 Oracle online document .............................................................................................................. 36


5

Executive summary

Business case Many customers use EMC snapshot technologies for Oracle database backup, restore,

and recovery operations. Moreover, the customers use these snapshot technologies (including Celerra® SnapSure™ checkpoint and CLARiiON® SnapView™) for creating test/dev environments, and for offloading backup operations from the production database servers. This effectively relieves the database servers from the CPU and memory-consuming operations of the backup operation.

Until recently, Oracle required putting the associated data files or database into backup mode in order to provide a consistent and recoverable backup image. The overhead of transitioning a database in and out of backup mode is:

• Additional redo data is logged while the database is in backup mode.

• A complete database checkpoint is required before entering backup mode.

• More operational steps and complexity are required during the backup operation.

Recently, Oracle announced its support for the use of third-party snapshot technologies (for example, those technologies provided by EMC) to create consistent images without hot backup mode and then to use these images in backup, restore, recovery, testing operations, and so on. This support assumes that the following prerequisites are met:

• The third-party snapshot technology is integrated with Oracle's recommended restore and recovery operations.

• The database image is crash-consistent at the point of the snapshot.

• Write ordering is preserved for each file within a snapshot.

EMC snapshot technologies fully meet the above three prerequisites.

Solution overview

This white paper documents the following backup and recovery operations of a 1 TB Oracle Database 11g (single instance) OLTP database running on the EMC®

CLARiiON CX4-480 and Celerra NS-480 platforms:

• Storage-based replication and recovery (hot backup).

• Storage-based replication and recovery (no hot backup).

In both cases, EMC snapshot technology is used to create an Oracle backup image. In the first case, hot backup mode is employed. In the second case, it is not.

Although this white paper focuses on Oracle 11g single-instance database with an OLTP workload on Enterprise Linux Red Hat 5.5, the principles stand true for any other architecture that facilitates EMC snapshot technologies. That is, it works for Oracle Database version 9.2.0.1 and later releases on a variety of operating system with any kind of workload, and not only for single-instance configuration, but also for Real Application Cluster (RAC) configuration.



Key results This white paper demonstrates the following benefits of the solution:

• The performance impact of the snapshot operation in terms of I/O requests per second (IOPS) and transactions per second (TPS) when the database is not in hot backup mode, compared with when the database is in backup mode.

• The multi-purpose utility of EMC snapshots for minimizing the impact of the backup to the production database. This means reduced backup time and reduced impact to the database node.

• The speed with which the snapshot can be used to recover the production database from unforeseen database corruption or loss. This also demonstrates that a snapshot of the database that is taken without hot backup mode is recoverable using media recovery in the same manner as a snapshot that is taken when the database is in backup mode.


7

Introduction

Purpose The purposes of this solution are to:

• Demonstrate the use of EMC CLARiiON SnapView to enable the logical storage backup, restore, and recovery of an Oracle 11g database (under ASM configuration) without putting the database into hot backup mode.

• Demonstrate the use of EMC Celerra SnapSure to enable the logical storage backup, restore, and recovery of an Oracle 11g database (under DNFS configuration) without putting the database into hot backup mode.

• Demonstrate the advantages in terms of performance and ease of use of storage- based snapshots for database backup, restore, and recovery. These advantages are demonstrated using snapshots that were taken without hot backup mode, compared with snapshots taken with the database in hot backup mode.

Scope The scope of this white paper covers the following topics:

• Storage-based replication and recovery by using EMC value-added software and hardware while putting the Oracle database in hot backup mode.

• Storage-based replication and recovery by using EMC value-added software and hardware without putting the Oracle database in hot backup mode.

Audience The intended audience for the white paper is:

• Internal EMC personnel

• EMC partners

• Customers

Terminology The terms used in this white paper are defined in Table 1.

Table 1. Terms and definitions

Term Definition

Direct NFS (DNFS) A feature of Oracle Database 11g in which the NFS client is embedded in the Oracle Database 11g kernel.

Automatic Storage Management (ASM)

Oracle ASM is a volume manager and a file system for Oracle database files. It supports single-instance Oracle database and Oracle RAC configuration.

Storage-based replication, restore and recovery

A solution component that provides backup and recovery functionality through the storage layer using specialized software and hardware.



Storage-based replication and recovery makes the following benefits: • Offload the database server’s CPUs from the

I/O and processing requirements of the backup, restore, and recovery operations.

• Superior Mean Time to Recovery (MTTR) through the use of logical storage layer replication (commonly referred to as snapshots).

Hot backup mode Hot backup mode is initiated when the ALTER TABLESPACE … BEGIN BACKUP or the ALTER DATABASE BEGIN BACKUP command is issued before taking an online backup. The tablespace is taken out of backup mode when the ALTER TABLESPACE ... END BACKUP command or the ALTER DATABASE END BACKUP command is issued.

Previously, these commands were required when a user-managed backup of datafiles of an online tablespace was made. In backup mode, updates to the database create more than the usual amount of redo. Each time a block in the buffer is modified, the cache becomes dirty. An image of the changed block must be written to the redo log file, in addition to recording the changes to the data.


9

Technology overview

Introduction This section provides an overview of the technologies that are used in this solution:

• EMC CLARiiON storage array

• EMC Celerra unified storage platform

• EMC Replication Manager

• EMC SnapSure

• EMC SnapView

• Disk drives

• Oracle software stack

EMC CLARiiON storage array

EMC CLARiiON storage array products offer a flexible architecture and multiprotocol connectivity. This enables the connectivity over IP/Ethernet, iSCSI, and Fibre Channel (FC) storage area network (SAN) environments.

The CLARiiON CX4-480 provides high-capacity networked storage for demanding online transaction processing (OLTP) workloads and large-scale e-mail environments. With CLARiiON CX4-480, customers can:

• Scale seamlessly up to 471 TB of storage capacity and consolidate twice the workload in one array, compared with any other storage provider.

• Use proven CLARiiON five 9s availability and innovative technologies—Fully Automated Storage Tiering (FAST), FAST Cache, Flash drives, compression, 64-bit operating system, and multi-core processors.

• Enjoy UltraFlex™ technology for dual-protocol, online-expandable connectivity options, and future technology integration.

The SAN connectivity protocols provided by the CLARiiON are described in Table 2.

Table 2. SAN connectivity protocols

Protocol Provided by

iSCSI EMC CLARiiON storage processors

FC EMC CLARiiON storage processors

EMC Celerra unified storage platform

EMC Celerra unified storage platform products offer a flexible architecture and multi-protocol connectivity. This enables connectivity over IP/Ethernet, iSCSI, and FC SAN environments.

Celerra NS-480 is a unified storage system that brings advanced failover and FAST



to multiprotocol environments. With Celerra NS-480, customers can:

• Connect to multiple storage networks through network-attached storage (NAS), iSCSI, FC SAN, and Celerra Multi-Path File System (MPFS). MPFS improves performance over traditional NAS.

• Move beyond direct-attached storage with an integrated CLARiiON CX4 that scales up to 480 disks.

• Simplify common administrative tasks with EMC Unisphere™ for greater efficiency with file system deduplication, FAST Cache, Virtual Provisioning™, and Celerra Automated Volume Management.

The key features provided by Celerra are described in Table 3.

Table 3. Celerra key features

Feature Provided by

NAS Network File System (NFS) and Common Internet File System (CIFS) protocol

iSCSI storage Celerra Data Mover

FC storage FC through the back-end EMC CLARiiON storage array

EMC Replication Manager

EMC Replication Manager manages EMC point-in-time replication technologies through a centralized management console. Replication Manager coordinates the entire data replication process—from discovery and configuration to the management of multiple application consistent disk-based replicas. It auto-discovers the replication environment and enables streamlined management by scheduling, recording, and cataloging replica information including auto-expiration.

Customers can use Replication Manager to:

• Create replicas using a variety of technologies to suit the requirements, either on-demand or based on schedules and policies that your customer define.

• Simplify replica management with application consistency.

EMC Replication Manager consists of the following components:

• Replication Manager Server—Stores all information about users, hosts, replicas, and ongoing operations.

• Replication Manager Console—Provides a graphical user interface and command line interface for users to control replication manager’s functions.

• Replication Manager Agent—Interacts with the application and storage layers to create, mount, restore, or expire replicas of mission-critical data.


11

EMC SnapSure SnapSure creates a logical point-in-time image (checkpoint) of a file system that reflects the state of the file system when the checkpoint is created. SnapSure can maintain a maximum of 96 read-only checkpoints and 16 writeable checkpoints per file system while allowing applications continue to access real-time data from that file system.

How SnapSure works SnapSure uses a copy-on-first-modify principle. A file system consists of blocks. When a block within the file system is modified, a copy that contains the block's original contents is saved to a separate volume called the SavVol. Subsequent changes made to the same block in the file system are not copied into the SavVol. The original block from the file system in the SavVol and the unchanged blocks remaining in the file system are read by SnapSure, according to a bitmap and blockmap data-tracking structure. The unchanged blocks in the file system together with the blocks saved in the SavVol provide a complete point-in-time image, which is called a checkpoint.

Figure 1 shows a comparison between RMAN and SnapSure in the time taken to back up and restore on the same database.

Figure 1. The comparison of RMAN and SnapSure in backup and restore

EMC SnapView

SnapView is a storage-system-based software application that enables you to create a copy of a LUN by using either clones or snapshots. A clone is an actual copy of a LUN and takes time to create, depending on the size of the source LUN. A snapshot is a virtual point-in-time copy of a LUN and takes only seconds to create.

How SnapView snapshot works A snapshot is a virtual LUN that allows a secondary server to view a point-in-time copy of a source LUN. The point in time can be determined when starting a SnapView session. The session keeps track of the source LUN's data at a particular point in time. During a session, the production server can still write to the source LUN and modify data. When this happens, the software stores a copy of the original point-in-time data on a reserved LUN in the storage processor’s reserved LUN pool. This operation is referred to as copy-on-first-write because it occurs only when a

0

2000

4000

6000

8000

10000

12000

14000

RMAN backup SnapSure backup

RMAN restore SnapSure restore

10440

724

13320

16

Tim

e(in

sec

ond)

Operations



data chunk is first modified on the source LUN. As the session continues and additional I/O modifies other data on the source LUN, the amount of data stored in the reserved LUN pool grows.

Figure 2 shows a comparison between RMAN and SnapView in the time taken to backup and restore on the same database.

Figure 2. The comparison of RMAN and SnapView in backup and restore

Disk drives

The general recommendations for mechanical disk drives are as follows:

• Drives with higher revolutions per minute (rpm) provide higher overall random-access throughput and shorter response time than drives with lower rpm. For optimum performance, higher-rpm drives are recommended for datafiles, tempfiles, and online redo log files.

• Because of significantly better performance, FC disks are always recommended for storing datafiles, tempfiles, and online redo log files. Enterprise Flash Drives (EFDs) can be used as well for these objects, other than online redo log files (for which EFDs are never recommended). EFDs can provide significant performance advantages over mechanical disks.

• SATA II drives have slower response and rotational speed, and moderate performance with random I/O. However, they are less expensive than the FC disks for the same or similar capacity.

• SATA II drives are usually the best option for storing archived redo logs and the flashback recovery area. In the event of high performance requirements for backup and recovery, FC disks can also be used for this purpose.

0

1000

2000

3000

4000

5000

6000

7000

RMAN backup SnapView backup

RMAN restore SnapView restore

6240

240

4140

79

Tim

e(in

sec

)

Operations


13

Oracle software stack

The Oracle software stack covered by this solution consists of:

• For Oracle ASM configuration

− Oracle Database 11g R2 Enterprise Edition (11.2.0.1)

− Oracle Grid Infrastructure 11g R2 Enterprise Edition (11.2.0.1)

• For Oracle DNFS configuration

− Oracle Database 11g R2 Enterprise Edition (11.2.0.1) with DNFS enabled



Configuration

Overview In the Oracle ASM configuration, all database objects, including datafiles, tempfiles,

control files, online redo log files, and archive log files, are stored on ASM disk groups that reside on SAN storage directly on CLARiiON CX4-480.

In the Oracle DNFS configuration, all database objects are stored on an NFS mount. Datafiles, tempfiles, control files, online redo log files, and archive log files are accessed using the DNFS client. This NFS mount point is accessed using Celerra NS-480.

Environment profile

The white paper was validated with the following environment profile in Table 4. Table 4. Environment profile

Profile Quantity/Type/Size Database size 1 TB

Database profile OLTP

Network connectivity 1 GbE 4 Gb FC

Network protocol NFS over IP using an Oracle DNFS client SAN over FC

User scaling To maximum stable load

Physical environment

Figure 3 and Figure 4 illustrate the overall physical architecture of the environment.

Figure 3. Oracle single-instance database on CLARiiON CX4-480 using ASM architecture diagram


15

Figure 4. Oracle single-instance database on Celerra NS-480 using DNFS architecture diagram

Storage layout Table 5 lists the Oracle file system allocation in the CLARiiON case.

Table 5. Oracle files system allocation on CLARiiON

What Where File system mount point

Oracle datafiles

FC disks

+DATA Oracle tempfiles

Oracle control files Oracle online redo log files

+LOG1 +LOG2

Oracle archived log SATA II +ARCH

• Oracle datafiles, tempfiles, online redo log files, control files, and archived log files are accessed using ASM.

• Four ASM disk groups are used: one disk group on FC disks for datafiles and tempfiles, two disk groups on FC disks for online redo log files and control files, and one disk group on SATA disks for archived log files.

• The online redo log files and control files are multiplexed in two ASM disk groups (+LOG1,+LOG2).

Table 6 lists the Oracle file system allocation in the Celerra case.

Table 6. Oracle files system allocation on Celerra

What File-system File-system type

Oracle datafiles

/datafs RAID-protected NFS file system on FC disks

Oracle tempfiles

Oracle control files

Oracle online redo log files

Oracle archived log /archfs RAID-protected NFS file system on SATA disks



• Oracle datafiles, tempfiles, online redo log files, control files, and archived log files are accessed using DNFS.

• Oracle datafile, tempfiles, control files, and online redo log files are placed in a single NFS file system stored using FC disks. Archived log files are placed on another single NFS file system using SATA disks.

Disk layout

Figure 5 illustrates the disk layout of the environment.

Figure 5. Disk layout


17

Network architecture

The network connectivity for the solution is as follows:

• FC provides network connectivity for ASM on SAN.

• TCP/IP provides network connectivity for DNFS.

• Storage networks consist of dedicated network switches and virtual local area networks (VLANs). Jumbo frames are enabled on these networks.

Hardware resources

Table 7 shows the hardware resources used in this solution.

Table 7. Hardware resource

Equipment Quantity Configuration

Celerra NS-480 (including an EMC CLARiiON CX4-480 back-end storage array)

1 2 Data Movers 1 GbE network connections per Data Mover 2 FC shelves (30 FC 300 GB 15k rpm disks) 1 SATA shelf (10 SATA 1 TB 7200 rpm disks) 1 Control Station 2 storage processors

Database server (Oracle 11g R2 server)

1 2 2.66 GHz Xeon 4 quad-core processors 48 GB of RAM 146 GB 15k internal SCSI disk 2 additional Intel PRO/1000 PT quad-port GbE Ethernet NICs

Software resources

Table 8 shows the software used in this solution.

Table 8. Software resource

Equipment Version

Celerra DART 5.6.47-11

CLARiiON FLARE® 04.29.000.5.003

EMC PowerPath® 5.3 SP1

EMC Replication Manager 5.3

Oracle Database 11g Release 2 Enterprise Edition

11.2.0.1.0

Oracle Enterprise Linux/Redhat Linux 5.5



Oracle Grid Infrastructure 11g Release 2 Enterprise Edition

11.2.0.1.0

Quest Benchmark Factory for Databases 5.8.0


19

Test and validation

Introduction The testing goal was to characterize the end-to-end solution and the response of the

component subsystem under a reasonable load, representing the market for Oracle Database 11g on Red Hat Enterprise Linux 5 with CLARiiON CX4-480 (ASM on SAN connected via FC) and Celerra NS-480 (DNFS connected through IP).

Storage-based replication (hot backup mode) of Oracle single-instance database on CX4-480

The storage-based replication (hot backup mode) of the Oracle single-instance database on the CLARiiON CX4-480 storage array was to validate that the Oracle 11g database configuration is compatible with CLARiiON SnapView using Replication Manager. The backup tests were both performance and functional tests. The impacts on the database IOPS and TPS were recorded when the SnapView snapshot was initiated from the Replication Manager. The database was put into hot backup mode before taking the snapshot, and was taken out of hot backup mode after the snapshot was completed. The restore was both a performance and functionality test as well. The amount of time that was required to perform the SnapView restore and the database recovery was tuned and measured.

Test procedures The following procedures were used to validate the storage-based replication in the hot backup mode solution component.

Step Action

1 Configure Replication Manager.

2 Register the production hosts, mount hosts, and storage in Replication Manager.

3 Create the application set in Replication Manager for the database to be replicated.

4 Create a job with hot backup mode setting in the Replication Manager console to take the SnapView snapshot.

5 Start the Benchmark Factory test with a user load ranging from 1,000 to 6,500.

6 When the user load reaches an iteration of 3,000, take a SnapView snapshot for the database by running the job in the Replication Manager console.

7 Monitor the performance impact on the production database.

8 When the Benchmark Factory test is complete, capture the results.

9 Shut down the database.

10 Destroy the database by deleting one of the datafiles.

11 Restore the database using Replication Manager.

12 Recover the database.

13 Capture the time taken to restore and recover the database respectively.



Test results The storage-based replication (in hot backup mode) using SnapView was performed while the OLTP load was running on the database. When the database was put into hot backup mode at user load 3,000 to take the SnapView snapshot, there was some increase in the response time and some decrease in the transaction throughput due to the additional overhead incurred by putting the database into hot backup mode. The TPS versus user load was almost linear but there were some impacts on the production database as shown in Figure 6.

Figure 6. TPS/Response time in hot backup mode using SnapView

The diagrams from the Oracle Database Control show that there were noticeable impacts on the I/O subsystem when taking the snapshot for the database in hot backup mode, and a surge in the number average active sessions was observed when the snapshot was taken.

Synchronous single block reads latency is shown in Figure 7.

Figure 7. Synchronous single block reads latency in hot backup mode using SnapView

As shown in the picture, the synchronous single block reads latency surged suddenly and peaked at 120 milliseconds (ms). High latencies are typically caused by a high I/O request load, and excessively high CPU load can also cause the latencies to increase.

I/O megabytes per second and I/O requests per second are shown in Figure 8 and Figure 9, respectively.


21

Figure 8. MBPS and IOPS by I/O function in hot backup mode using SnapView

As an incremental database checkpoint was incurred by putting the database into hot backup mode, the Database Writer (DBWR) process had to flush the database buffer cache, and this operation caused excessive I/O, as shown in Figure 8 and Figure 9.

Figure 9. MBPS and IOPS by I/O type in hot backup mode using SnapView

The average active sessions are shown in Figure 10.

Figure 10. Average active sessions in hot backup mode using SnapView



Because the I/O subsystem was overloaded when putting the database into hot backup mode, the number of average active sessions in the database surged suddenly and peaked at 90, and most of them were waiting for user I/O. The more active sessions at any given point in time, the more CPU and memory resources were consumed, thus the performance of the database server degraded.

Storage-based replication, restore, and recovery of an Oracle single-instance database on a CX4-480 in hot backup mode summary Table 9 provides a summary of the storage-based replication and restore test. Table 9. Storage-based replication, restore, and recovery summary in hot backup mode using SnapView

Test run duration 5 hours and 18 minutes

User load range 1,000 to 6,500 with intervals of 100

Profile UC490SAN

Driver Oracle

Start time of test 9/17/2010 09:56

End time of test 9/17/2010 15:14

Snapshot create time 9/17/2010 12:07:30

Begin hot backup time 9/17/2010 12:04:54

End hot backup time 9/17/2010 12:07:31

Total time for restore operation 1 minute and 8 seconds

Total time for recovery 1 hour and 14 minutes

Storage-based replication (without hot backup mode) of Oracle single-instance database on CX4-480

The storage-based replication (without hot backup mode) of an Oracle single-instance database on a CX4-480 storage array was to demonstrate that the Oracle 11g database configuration is compatible with CLARiiON SnapView using Replication Manager. The backup tests were both performance and functional tests. The impacts on the database IOPS and TPS were recorded when the SnapView snapshot was initiated from the Replication Manager.

Note The snapshot was taken without putting the database into hot backup mode. The restore was also a performance and functionality test. The amount of time that was required to perform the SnapView restore and the database recovery was measured.

Test procedures The following procedures were used to validate the storage-based replication without the hot backup mode solution component.


23

Step Action




4 Create a job without hot backup mode setting in the Replication Manager console to take the SnapView snapshot.


6 When the user load reaches an iteration of 3,000, take a SnapView snapshot of the database by running the job in the Replication Manager console.







Test results The storage-based replication (without hot backup mode) using SnapView was performed while the OLTP load was running on the database. At the iteration with a user load of 3,000, a SnapView snapshot was taken of the database. There was a minimal increase in response time and almost no decrease in transaction throughput, but this performance degradation is relatively small in comparison with the performance degradation when backing up the database that is in hot backup mode.

Figure 11. TPS/Response time without hot backup mode using SnapView



The diagrams from the Oracle Database Control show that there is a little impact on the I/O subsystem when the snapshot was taken for the database, and the number of average active sessions increased a little. Synchronous single block reads latency is shown in Figure 12.

Figure 12. Synchronous single block reads latency without hot backup mode using SnapView

As shown in Figure 12, the synchronous single block reads latency increased when snapshot was taken, but the latency did not exceed 60 ms.

I/O megabytes per second and I/O requests per second are shown in Figure 13 and Figure 14.

Figure 13. MBPS and IOPS by I/O function without hot backup mode using SnapView

The I/O operations of database did not show much change before and after the snapshot was taken.

Figure 14. MBPS and IOPS by I/O type without hot backup mode using SnapView


25

Figure 13 and Figure 14 also show there was no big difference before and after the snapshot was taken. Average active sessions are shown in Figure 15.

Figure 15. Average active sessions without hot backup mode using SnapView

As shown in Figure 15, the number of average active sessions increased and peaked at 30, but decreased gradually after the snapshot was taken.

Storage-based replication, restore, and recovery of an Oracle single-instance database on a CX4-480 without hot backup mode summary Table 10 provides a summary of the storage-based replication and restore test without hot backup mode using SnapView. Table 10. Storage-based replication, restore, and recovery summary without hot backup mode using SnapView

Test run duration 3 hours and 12 minutes

User load range 1,000 to 6,500 with interval of 100

Profile UC490SAN

Driver Oracle


End time of test 9/19/2010 16:19


Total time for restore operation 1 minute and 12 seconds

Total time for recovery 1 hour and 17 minutes

Storage-based replication of Oracle single-instance database on CX4-480 conclusion

EMC SnapView works well with Oracle Database 11g on CLARiiON CX4 in backup, restore, and recovery, both with and without the database in hot backup mode. More importantly, when taking snapshot for the database that is not in hot backup mode, the approximate statistics of performance advantage are displayed as below:

• The number of average active sessions decreased by 60%.

• The MBPS decreases by 80%; the IOPS decreased by 50%.

• The synchronous single block reads latency decreased 50%.

This means that less CPU and memory resources on the database server were



consumed and less loaded on the I/O subsystem, when compared with taking a snapshot for the database in hot backup mode.

Storage-based replication (hot backup mode) of Oracle single-instance database on NS-480

The storage-based replication (hot backup mode) of an Oracle single-instance database on a Celerra NS-480 storage array was to demonstrate that the Oracle 11g database configuration is compatible with Celerra SnapSure using Replication Manager. The backup tests were both performance and functional tests. The impacts on the database IOPS and TPS were recorded when the SnapSure checkpoint was initiated from the Replication Manager. The database was put into hot backup mode before creating the checkpoint, and was taken out of hot backup mode after the checkpoint was completed. The restore was also a performance and functionality test, as the amount of time required to perform the SnapSure restore and the database recovery was measured for further comparison.

Test procedures The following procedures were used to validate the storage-based replication under the hot backup mode solution component.

Step Action




4 Create a job with the hot backup mode setting in the Replication Manager console to create the SnapSure checkpoint.


6 When the user load reaches an iteration of 3,000, create a SnapSure checkpoint for the database by running the job in the Replication Manager console.




10 Back up the database control files and online redo log files with the OS command cp.

11 Destroy the database by deleting one of the data files.


13 Restore the database control files and online redo log files with the backup made in step 10.



27


Test results The storage-based replication (in hot backup mode) using SnapSure was performed while the OLTP load was running on the database. At the iteration with user load 3,000, a SnapSure checkpoint was created for the database. There was a significant increase in response time and a significant decrease in transaction throughput due to the additional overhead incurred by putting the database into hot backup mode. There are noticeable inflexion points in the curves of TPS versus user load and response time versus user load. There was a big impact on the database, as shown in Figure 16.

Figure 16. TPS/Response time in hot backup mode using SnapSure

The diagrams from the Oracle Database Control show that there was a big impact on the I/O subsystem when taking the snapshot for the database in hot backup mode. Moreover, the number of average active sessions surged dramatically. Synchronous single block reads latency is shown in Figure 17.

Figure 17. Synchronous single block reads latency in hot backup mode using SnapSure




Figure 18. MBPS and IOPS by I/O function in hot backup mode using SnapSure

Figure 19. MBPS and IOPS by I/O type in hot backup mode using SnapSure

From Figure 17, Figure 18, and Figure 19, the synchronous single block reads surged suddenly and peaked at 32,000ms, and most of the I/O operation was small write, which was issued by the DBWR process for flushing the buffer cache during database incremental checkpoint.


29

Average active sessions are shown in Figure 20.

Figure 20. Average active sessions in hot backup mode using SnapSure

Since the I/O subsystem experienced a high workload, and the number of average active sessions surged dramatically and peaked at 1,800, most of the sessions were waiting for the events “checkpoint completed’ and “log file sync” at that time.

Storage-based replication, restore, and recovery of an Oracle single-instance database on an NS-480 under hot backup mode summary Table 11 provides a summary of the storage-based replication and restore test. Table 11. Storage-based replication, restore, and recovery summary in hot backup mode using SnapSure

Test run duration 2 hours 38 minutes


Profile UC490NAS

Driver Oracle


End time of test 10/03/2010 23:48


Begin hot backup time 10/02/2010 22:18:27

End hot backup time 10/02/2010 22:28:20

Total time for restore operation 4 minutes 22 seconds

Total time for recovery 48 minutes

Storage-based replication (without hot backup mode) of Oracle single-instance database on NS-480

The storage-based replication (without hot backup mode) of the Oracle single-instance database on an NS-480 storage array was to validate that the Oracle 11g database configuration is compatible with Celerra SnapSure using Replication Manager. The backup tests were both performance and functional tests. The impacts on the database IOPS and TPS were recorded when the SnapSure checkpoint was initiated from the Replication Manager.

Note This checkpoint was created without putting the database into hot backup mode. The restore was also a performance and functionality test. The amount of time that was required to perform the SnapSure restore and



database recovery was measured.

Test procedures The following procedures were used to validate the storage-based replication in the hot backup mode solution component.

Step Action




4 Create a job without the hot backup mode setting in the Replication Manager console to create the SnapSure checkpoint.


6 When the user load reaches an iteration of 3,000, create a SnapSure checkpoint for the database by running the job in the Replication Manager console.


8 When the Benchmark Factory test completes, capture the results.


10 Back up the database control files and online redo log files with the OS command cp.

11 Destroy the database by deleting one of the data files.


13 Restore the database control files and online redo log files with the backup made in step 10.



Test results The storage-based replication (without hot backup mode) using SnapSure was performed while the OLTP load was running on the database. At the iteration with a user load of 3,000, a SnapSure checkpoint was created for the database. There was a minimal increase in response time and a minimal decrease in transaction throughput, but this performance degradation is relatively small, when compared with creating the checkpoint for the database in hot backup mode, as shown in Figure 21.


31

Figure 21. TPS/Response time without hot backup mode using SnapSure

The diagrams from the Oracle Database Console show that there were impacts on the I/O subsystem when taking the snapshot for the database that is not in hot backup mode, and the number of average active sessions increased to a minimum extent.

Synchronous single block reads latency is shown in Figure 22.

Figure 22. Synchronous single block reads latency without hot backup mode using SnapSure

As shown in Figure 22, the synchronous single block reads latency showed almost no changes.


Figure 23. MBPS and IOPS by I/O function without hot backup mode using SnapSure



Figure 24. MBPS and IOPS by I/O type without hot backup mode using SnapSure

Figure 23 and Figure 24 also show that there was no big impact on the I/O subsystem when creating the checkpoint.

Average active sessions are shown in Figure 25.

Figure 25. Average active sessions without hot backup mode using SnapSure

As shown in Figure 25, the number of average active sessions increased a little, and most of the sessions were waiting for the event “log file sync”.

Storage-based replication, restore, and recovery of an Oracle single-instance database on an NS-480 without hot backup mode summary The following table provides a summary of the storage-based replication and restore test. Table 12. Storage-based replication, restore, and recovery summary without hot backup mode using SnapSure

Test run duration 2 hours 32 minutes


Profile UC490NAS

Driver Oracle


33


End time of test 10/04/2010 11:24


Total time for restore operation 4 minutes 47 seconds

Total time for recovery 45 minutes

Storage-based replication of Oracle single-instance database on NS-480 conclusion

EMC SnapSure works well with Oracle Database 11g on Celerra NS-480 in backup, restore, and recovery, both with and without putting the database into hot backup mode. More importantly, when creating a checkpoint for the database that is not in hot backup mode, the approximate statistics of performance advantage are displayed as below:

• The synchronous single block reads latency decreased by 99.8%.

• The MBPS decreases by 30%; the IOPS decreased by 38%.

• The number of average active sessions decreased by 94%.

It means that less CPU and memory resources were consumed, and I/O subsystem was less loaded, when compared with creating the checkpoint for the database in hot backup mode.



Conclusion

Summary This white paper demonstrates that when using storage-based snapshots to take

image copies of Oracle databases on an EMC CLARiiON storage array or EMC Celerra unified storage platform, putting the database into hot backup mode is no longer required. Thus, this offers some relief for the database server in terms of CPU, I/O, and memory consumption.

Key points

The key points that this solution addresses are listed in the table.

Table 13. Key points of the solution Key point Solution objective

Improved performance When replicating the database while putting the database into hot backup mode, any updates to the data files create more than the usual amount of redo. This is because each change causes Oracle to write the entire block rather than just change the data to the redo log, thus putting substantial overhead on the database server and the underlying I/O subsystem. The recover process also takes longer to complete due to additional redo data. Oracle now supports taking a storage-based image copy of the database by using EMC snapshot technologies (CLARiiON SnapView and Celerra SnapSure, for example) without putting the database into hot backup mode. This substantially frees the database server and the I/O subsystem from the additional overhead. Consequently, it greatly minimizes the impact on the business processing.

Reduced complexity of backup and recovery

EMC Replication Manager eliminates the requirement for the customer to write scripts or to manually perform replication tasks. These tasks can be fully automated and managed by Replication Manager. More importantly, since putting the database into hot backup mode is no longer needed, no additional step should be taken when replicating the database. A snapshot can be taken directly by EMC CLARiiON SnapView and EMC Celerra SnapSure for the Oracle database, which greatly simplifies the replication operation.

Reduced total cost of ownership

This solution reduces the load on the database server CPU by using EMC Replication Manager and EMC SnapView and SnapSure to carry out a storage-based replication of an Oracle 11g database while offloading all the performance impacts of the backup operation from the database server and underlying I/O subsystem. And both the backup and restore times are dramatically minimized, which means more time and


35

memory are saved.

Robust performance and scaling

The performance testing is carried out through EMC utilities and industry-standard OLTP benchmark without exotic tunings that are not compliant with the best practices. In addition, read-world configurations are used to ensure that the configuration on the application is predictable and reliable.

Facilitated testing and developing task

A test/dev database must be populated with data from the production database. Moreover, when the testing personnel need to address an emergency issue, production data must be replicated onto the testing server. If the amount of data in the database is very large, this migration can be a time-consuming task. Chances are that this emergency issue cannot be addressed in time and thus this caused more loss. With EMC snapshot technologies, a snapshot can be taken of the production database within minutes and can be used to seed a test/dev environment while keeping the production up and running. This greatly improves the efficiency of the migration operation.

Next steps To learn more about this and other solutions, contact an EMC representative or visit:

www.emc.com.

http://www.emc.com/�



References

White papers For additional information, see the white papers listed below:

• EMC Backup and Recovery for Oracle Database 11g SAN Performance Enabled by EMC CLARiiON CX4-120 Using the Fibre Channel Protocol and Oracle Automatic Storage Management (ASM)

• EMC Backup and Recovery for Oracle Database 11g Enabled by EMC Celerra NS-120 using DNFS

Oracle metalink note

Supported Backup, Restore, and Recovery Operations using Third Party Snapshot Technologies [ID 604683.1]

Oracle online document

• Oracle Database Backup and Recovery User’s Guide 11g Release 2 (11.2).

• Oracle Enterprise Manager Oracle Database and Database-Related Metric Reference Manual 11g Release 1 (11.1.0.1)

Documents

EMC Backup and Recovery for Oracle Database 11g Without ... · PDF fileOracle metalink note ... Oracle Database version 9.2.0.1 and later releases on a variety of operating system