Engineering White Paper

Using SnapView for Business Applications

Accelerating Business Processes

Abstract
This white paper describes the SnapView product and how it can be used to accelerate business processes.
Basic concepts for SnapView are discussed, as well as various potential implementations for customers.

Published 12/3/2004
 12/3/2004

Copyright 2004 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.

Part number H1432

Using SnapView for Business Applications

Accelerating Business Processes 2
 12/3/2004

Table of Contents

Executive Summary............................................................................................ 4
Intended Audience.............................................................................................. 4
Introduction ......................................................................................................... 4
SnapView Terminology ................................................................................................................ 4
Business Operations Supported by SnapView ................................................ 5
Backup and Recovery Operations ............................................................................................... 5
Report Generation ....................................................................................................................... 5
Data Warehouse/Decision Support System Population .............................................................. 6
Application Testing and Upgrades ............................................................................................... 6
User Training................................................................................................................................ 6
BCVs Compared with Snapshots ...................................................................... 7
Data Access ................................................................................................................................. 7
Resource Requirements .............................................................................................................. 8
Performance Considerations ....................................................................................................... 8
BCV Synchronization Effect on Source I/O.............................................................................. 8
Snap Session Effect on Source I/O.......................................................................................... 9
Use of ATA Drives.................................................................................................................... 9
SnapView Implementation ................................................................................. 9
Managing Replicas ...................................................................................................................... 9
Number of Replicas ................................................................................................................... 10
Data Recovery ........................................................................................................................... 10
Conclusion ........................................................................................................ 11
Appendix ........................................................................................................... 12
BCV Performance ...................................................................................................................... 12
Snapshot Performance .............................................................................................................. 14
Performance Conclusions.......................................................................................................... 14

Using SnapView for Business Applications

Accelerating Business Processes 3
 12/3/2004

Executive Summary
This paper describes how EMC SnapView replicas can be used to help accelerate business processes.
Specific business application uses are discussed, illustrating the benefit of being able to perform various
business tasks concurrently. Differences between business continuance volumes (BCVs) and snapshots are
discussed so that users can understand the tradeoffs of each feature, and can thus determine which feature
may best suit their business need.

Intended Audience
The intended audience for this paper is members of the EMC field community who interact with customers
and need to understand how SnapView can assist with business processes. Customers are also invited to
read this paper, to get a first-hand understanding of the benefits of using SnapView in their environments.

Introduction
SnapView is an optional software package for the EMC CLARiiON storage system1. Using SnapView,
users can create secondary replicas of data to support secondary tasks in their environment. For instance,
users can create a replica of their data to be used in backup operations, while their production data remains
online. In this way, SnapView replicas provide concurrent data access, providing for greater flexibility and
productivity in customer environments.
SnapView provides two types of replicas: business continuance volumes (BCVs) and snapshots.
SnapView BCVs are full copies of the original production data. That is, if the original production data is
250 GB, the BCV must also be 250 GB. SnapView snapshots implement a pointer-and-copy-based design,
where pointers are directed to the original production data until a write request comes in to change that
data. At that point, the original data is copied in a reserved area, and accordingly, the pointers to that data
are redirected to the new location to preserve the point-in-time view of the data. In this way, only a
fraction of the space of the original source data is required to enable snapshots; that is, snapshot capacity is
proportional to write I/O volume. BCVs and snapshots can be presented to servers as separately
addressable volumes for both reads and writes and thus provide concurrent data access. For more
information on SnapView functionality and operations, refer to the white paper SnapView Snapshots and
Sessions.

SnapView Terminology
The following SnapView terms are provided to help clarify the components and features of SnapView.
BCV The LUN that is a separate disk copy of the source LUN. BCVs must be the same size as the
source LUN, but can be a different RAID and disk type. Fracturing a BCV is the process of breaking off
the BCV from the source so that it can be presented to a secondary server. To update the contents of the
BCV, the user must take it offline from the secondary server and then reconnect it to the source (by
choosing to synchronize it).
SnapView Session The point-in-time reference of a source LUN. Note that the session is not visible to
a server until a snapshot is activated to it.
SnapView Snapshot The virtual device that is activated to a session and presented to a server to enable
visibility into that session. Active snapshots are fully read- and write-capable. Once the snapshot is
deactivated, however, all writes via the snapshot will be deleted.
Source LUN The LUN containing production data of which you want to make a replica.

1
SnapView is supported on all CLARiiON models, CX300 and higher. Also, SnapView is supported on the
AX100. (The only CLARiiON platform on which SnapView is not supported is the CX200.)

Using SnapView for Business Applications

Accelerating Business Processes 4
 12/3/2004

SnapView allows users to create up to eight BCVs of each source logical unit (LUN), and likewise, up to
eight snapshots of each source. Furthermore, users can create snapshots of BCVs; since the BCV is serving
as the snapshot source in this case, users can create up to eight snapshots of each BCV. Taken to its
maximum, users can create up to 8 BCVs per source and can create up to 8 snapshots of each BCV, which
calculates to 8 BCVs and 64 snapshots. In addition, users could have an additional 8 snapshots directly off
the source for a total of 72 snapshots of the source (plus the 8 BCVs).

Business Operations Supported by SnapView

SnapView enables users to perform the various tasks on a given data set as required in a typical business
environmentwithout having to compromise data access. Users can use SnapView replicas to support the
secondary tasks in the environment, while keeping the production data online and available to users. Some
of these secondary tasks include:
Backup and recovery operations
Report generation
Data warehouse / decision support system population
Application testing and upgrades
User training

Backup and Recovery Operations

One of the most common uses of SnapView replicas is in support of backup and recovery operations.
Users can create a SnapView replica and present the replica to a backup server to run backup operations on
a regular basis. When creating a replica for presentation to a secondary server, users should ensure that the
SnapView replica has a consistent point-in-time reference. With a consistent point-in-time replica, users
can free themselves from the race to sunrise challenge since there will no longer be the pressure
associated with running backups on production data, and thus having to complete the backup in a limited
window. With SnapView replicas, users can schedule backups to occur when convenient for them, and to
take as long as needed to complete.
Furthermore, users can leverage cost-effective Advanced Technology-Attached (ATA) drives as backup
targets and implement backup-to-disk strategies to further benefit their backup strategies. Since ATA
drives provide higher hardware reliability than tapeplus RAID protection not offered by traditional
tapeusing ATA drives for backup targets increases the speed and reliability of backup operations.
Implementing backup-to-disk strategies gives users an even greater benefit in the event that recovery
becomes necessary. Performing recovery from disk yields an even greater time savings over recovery from
tape since recovery operations often require finding the correct tape, loading it, and so on. Recovery from
disk, on the other hand, avoids those extra steps, thus increasing the performance benefits afforded by
implementing backup/recovery operations on disk.

Report Generation
As with running backup operations on SnapView replicas, users can also run reports on SnapView replicas.
Just as with backup operations, reports are typically generated when organizations can afford to take down
the production application. With SnapView replicas, reports can be run whenever needed, on data points
that are relevant, facilitating report generation based on relevance, rather than schedule availability.

Using SnapView for Business Applications

Accelerating Business Processes 5
 12/3/2004

Data Warehouse/Decision Support System Population

The same issues of data relevance versus schedule availability apply to population of data warehouses and
decision support systems. Similar to backups and reports, data warehousing and decision support systems
are traditionally populated when schedules permit rather than according to when data is most relevant.
SnapView replicas allow users to set those schedules according to the needs of the application rather than
when the production data can be taken offline.

Application Testing and Upgrades

SnapView replicas also provide an easier means of application testing. Users can run tests against replicas
of the production data set without affecting users use of the production data. Once sufficient testing has
been completed, users can then upgrade the applications using the production data. Alternatively, users
may opt to promote the test replica to become the production data LUN. Additionally, given the ability to
have Snap sessions on BCVs, it would be possible to have various iterations of data sets in various states of
testing. Instead of the BCV, these Snap sessions could be brought online. If data corruption (or other
adverse effect of testing) should occur, the Snap session could be discarded, thus leaving the unaltered
BCV in its original, usable state. This would allow ongoing testing with the same base replica, thus
minimizing effort in creating the test resources. Running the Snap sessions on the BCVs also minimizes
impact to the source LUN. Where performance is less of an issue, users could likewise run the Snap
sessions directly on the production data set.

User Training
In many environments, employees need to use a particular data set for training or practice, where they can
make modifications and changes as theyre using the data set; yet at the end of the training period, it would
be beneficial to reset the data to its original state. SnapView replicas allow the creation of these
training data sets. In some instances, users have created SnapView sessions at the start of the training
period and activated snapshots to those sessions so that the employees can use these virtual LUNs for
their training. At the end of the training period, the session can simply be stopped and then re-created at
the beginning of the next training period, thus allowing users to reset their training environment in a
matter of moments.
Where the data set is production data, and avoiding performance impact on that production data is critical,
users often opt to first create a BCV of the production data, and then run the Snap sessions against the
BCV. This way, the BCV absorbs the performance impact of the Snap sessions. Furthermore, the BCV
preserves the consistent gold copy of the data since its contents will remain unchanged until the user elects
to update its contents via a resynchronization.

Using SnapView for Business Applications

Accelerating Business Processes 6
 12/3/2004

Production Host

Training

Training 1
Replica 2
Replica 3
Replica 4
Production Replica 5
Information Replica 6
Replica 7
Tape Replica 8
Backup Replica 1

Replica 2
Production
Report Information
Generation
Replica 3

Decision
Support Tools

Figure 1. Using SnapView Replicas for Business Applications

BCVs Compared with Snapshots

When using SnapView, users must determine which replica type best suits their environment. The
following considerations will help users determine where BCVs or snapshots are more appropriate
solutions for their environment.

Data Access
Users can access BCVs or snapshots from a secondary server. BCVs can be accessed once they are
fractured from their source, and snapshots can be accessed once theyve been associated with (activated to)
a Snap session. A distinction between BCVs and snapshots, however, is how soon after creation the replica
can be accessed. Because snapshots function on a pointer-and-copy mechanism, the processing to start a
Snap session is minimal and the Snap session data is available virtually instantaneously. BCVs on the
other hand, being full-image copies, must have sufficient time for the initial copy (referred to as
synchronization by the software) to occur before they can be used for the first time. This paper does not
provide in-depth performance information, but for the purpose of comparison with starting Snap sessions as
described earlier, LUN synchronizations on a CX700 can run as quickly as 75 MB/s for a single BCV.
Once the initial synchronization has been performed, subsequent updates (resynchronizations) will be
incremental. The rate of data transfer will be comparable, but the amount needing to be transferred will
only be that data which changed on the source while the BCV was fractured.
In consideration of data availability, it should be noted that creating the snapshot (or, more specifically,
when starting the session to which the snapshot will be activated) or fracturing the BCV from the source, is
what defines the point-in-time characteristic of the replica. As such, the application writing to the source
volume must have logical consistency. Typically this is done by using the online quiesce capability if the
application has that capability. If not, the application must be stopped (and host buffers flushed to disk)
while starting the session or fracturing the BCV, and then restarted once the session has been started or the
BCV fractured.

Using SnapView for Business Applications

Accelerating Business Processes 7
 12/3/2004

Finally, on the note of access to replicas, it should be noted that general EMC recommendation is that users
avoid accessing replicas from the production server (or, likewise, that users not access replicas of the same
source from the same server). This recommendation stems from the fact that unless drive signatures are
modified correctly, data corruption may occur. The only exception to this restriction is if users are using
EMC PowerVolume (available with PowerPath 4.x), and/or a member of the EMC Replication
Manager family.

Resource Requirements
Since BCVs are full image copies, they require the same amount of usable disk space as the source volume.
BCVs do not have to be the same RAID type or drive type as their source, however. Consequently, users
may opt to put production data on RAID 1/0 drives for maximum protection, whereas they may opt to put
BCVs on RAID 5 drives to decrease the relative drive cost for BCVs. Furthermore, users may opt to put
BCVs on ATA drives to for additional cost savings. In this way, users can leverage the flexibility of
CLARiiON to provide tiered storage and protection in their environment.
The pointer-and-copy-based design for snapshots minimizes the amount of space needed to support these
replicas. Since only the data that is changed during the snapshot session must be accommodatedthat is,
copied to the reserved LUN2 the reserved LUN needs only to be large enough to hold that changed data.
In other words, instead of requiring another LUN that is the same size as the source LUN (as BCVs do),
snapshots require only a fraction of additional space. How much space is required will vary between
implementations, but depends on variables such as the rate of change of the source LUN data, how many
session(s) will run, and for how long. A conservative size would be 20 to 30 percent of the source LUN for
a single session, and then increasing that figure by 10 to 20 percent for each additional session. Although
these estimates are only general guidelines, they should nevertheless demonstrate how snapshots will
typically require significantly less disk capacity than BCVs. Also, as with BCVs, users may opt to put the
reserved LUNs on ATA drives for greater cost savings.

Performance Considerations
Users may find that the difference between BCVs and snapshots in terms of performance may help clarify
which replica is right for their environment.

BCV Synchronization Effect on Source I/O

One significant benefit that BCVs offer over snapshots is that they tend to provide better performance of
the source volume. This difference is due to the fact that BCVs typically exist on different drives than the
source volume (EMC recommends this), and thus reads and writes to the source hit different spindles than
reads and writes to the BCV. The only time that BCVs will impact source performance is when the BCV is
being synchronized. After initial creation, BCVs only require incremental resynchronization (that is, only
the changes since the last synchronization). (Refer to Figures 3 and 4 in the Appendix, for detailed
performance information regarding BCVs.)
To offset this impact, users are advised to strategically select when they resynchronize their BCV so as to
minimize the impact to source volume performance. Additionally, users can select the synchronization rate
that best suits their environment. The high synchronization rate devotes a high percentage of the
CLARiiON CPU to completing the synchronization as fast as possible, whereas the low synchronization
rate allows many other operations to occur during the synchronization. This slows down the
synchronization, but also minimizes the impact of the synchronization. (Medium is the default, and the rate
can be changed while a synchronization is in progress.)

2
The private LUNs contain original data to maintain the point-in-time view of the session. Reserved LUNs
are assigned on a per-source-LUN basis, such that source LUNs have a one-to-many relationship to their
reserved LUNs. The design of reserved LUNs allows for additional reserved LUNs to be assigned to
sources when needed (provided that extra reserved LUNs are available in the reserved LUN pool).

Using SnapView for Business Applications

Accelerating Business Processes 8
 12/3/2004

Snap Session Effect on Source I/O

The pointer-and-copy design of snapshots, while conserving disk space, typically affects source volume
performance. This is due in part to the fact that, for data that has not yet changed on the source volume,
reads to the snapshot are hitting the same spindles as reads to the source volume. Additionally, when write
requests to the source generate the copy of the original data to the reserved LUN, CPU processing must be
directed toward handling the copy operation, thus decreasing the CPU processing cycles available to handle
I/O to the source. (Refer to Figure 5 in the Appendix for detailed performance information regarding
snapshots.)

Use of ATA Drives

The performance of ATA drives, in general, will depend on the available write cache. As long as the write
cache can absorb the writes to the ATA drives, there will be no noticeable performance difference between
writes to Fibre Channel drives and writes to ATA drives. Once the write cache becomes full, however, this
difference will become noticeable.
When using ATA drives for BCVs, users should keep in mind that while synchronizing the BCV, if the
write cache cannot keep up with the writes to the BCV, the synchronization operation will take longer
when performed on ATA drives as opposed to Fibre Channel drives. Additionally, once the BCV is
synchronizedand until it is fracturedall writes to the source LUN will be simultaneously written to the
BCV. In this case, if the write cache becomes full, the writes to the BCV will be processed at the slower
ATA processing rate and thus impact server response time. (Refer to Figures 3 and 4 in the Appendix for
detailed performance information regarding BCVs on ATA.) To minimize this server impact and also to
ensure a point-in-time replica is available for recoveryusers are encouraged to fracture the BCV as soon
as it has been synchronized.
Likewise, some users may opt to use ATA drives for SnapView reserved LUNs. When using ATA drives
for reserved LUNs, performance testing showed that unless there are several sessions running on a given
source, the difference between using Fibre Channel and ATA drives for the reserved LUNs is minimal.
Thus, using ATA drives for reserved LUNs may provide users an additional cost savingswithout a
significant performance impactin allocating storage space for their SnapView replica. (Refer to Figure 5
in the Appendix for detailed performance information regarding using ATA drives for reserved LUNs.)

SnapView Implementation
Managing Replicas
SnapView tasks can be managed via Navisphere Manager graphical user interface (GUI) or Navisphere
command line interface (CLI)3. In some cases, users may find the Navisphere Manager interface easier for
initial configuration of SnapView objects and resources (such as first creating the source-to-BCV
relationship). Subsequently, users will likely find the CLI more appropriate for ongoing management of
replicas (such as managing replicas with backup jobs).
Additionally, the Replication Manager family of products helps users integrate their use of SnapView
replicas with server applications such as Microsoft Exchange, Microsoft SQL, and Oracle. Replication
Manager also allows users to coordinate replication operations with backup and recovery operations,
allowing for greater flexibility and, at the same time, greater simplicity. For more information on
Replication Manager products, refer to the white paper Introduction to Replication Manager Technology.
White papers discussing application-specific considerations with Replication Manager are also available.

3
admsnap is a server-based utility that facilitates management of SnapView objects at the server level, such
as bringing snapshots online.

Using SnapView for Business Applications

Accelerating Business Processes 9
 12/3/2004

Number of Replicas
As noted earlier, SnapView allows users to have up to eight snapshots and/or eight BCVs per source.
Table 1 provides a more complete listing of the allowed replicas per source and per storage system. For the
most up-to-date SnapView limits information, refer to the most recent version of the CLARiiON Open
Systems Configuration Guide.

Table 1. SnapView Replicas per Platform

SnapView BCV Limits CX700/600 CX500/400 CX300 AX100
BCVs per source LUN 8 8 8 0
BCVs per storage system 100 50 50 0
SnapView Snapshot Limits CX700/600 CX500/400 CX300
Sessions per source LUN 8 8 8 1
Snapshots per source LUN 8 8 8 1
Snapshots per storage system 300 150 100 4
Reserved LUNs per storage system 100 50 25 N/A

Data Recovery
In addition to providing point-in-time views of data for concurrent access, SnapView point-in-time replicas
provide users a way to recover data in the event of a data corruption on the source LUN. The data from
BCVs or Snap sessions can be used to restore the contents of a source LUN virtually instantaneously to the
point in time associated with that replica.
These restore operations function independently of any of the other SnapView replicas that may be defined
on a source LUN. Therefore, it is completely nondestructive to the source LUNs other replicas. In other
words, if a user has any given mix of BCVs and SnapView sessions, the data relative to each replica is not
affected by the restore operation.
As shown in Figure 2, a restore operation is started using the Tuesday replica, while the other sessions
continue to operate without interruption.

Source LUN instantly appears to

have Tuesday view of data
Source
LUN
Monday [Saturday
view] Production
view Server

Tuesday Friday
X
view ... view

Backup Tuesday Replica

Server selected for restore

Figure 2. Choosing Among Replicas for Restore Operation

If the issue on the source LUN is hardware-related rather than software-related, SnapView BCVs offer
another level of protection. Since the BCV is defined on separate drives from the source LUN, the BCV
continues to be available even if the source LUN is not. In the unlikely event that a source LUN might
experience a multiple-drive failure, the BCV would remain accessible. In this event, users may opt to put
the BCV into production if the source volume is deemed unrecoverable (or needed more quickly than it can
be recovered). Should this be necessary, users should keep in mind that the BCV will have a point-in-time

Using SnapView for Business Applications

Accelerating Business Processes 10
 12/3/2004

reference that is likely different from the source; so any source data that has not yet been updated to the
BCV would be lost.

Conclusion
SnapView BCVs provide parallel data access facility with low impact to production data access. This
capability significantly reduces the time production environments would normally have to be offline for
backups or decision-support-type operations. This accelerates business processes and increases
productivity.
With the option of snapshots, users can have immediate access to replicas (which require a fraction of the
source LUN capacity),such as for training purposes or, in some cases, backup operations. On the other
hand, users may opt to use independent full copies of data that provide an additional level of protection
with better performance, such as for backup operations, or running reports, or data warehousing.
In addition to providing for concurrent access to data, SnapView provides the ability to instantly restore
source data in the event of a data corruption. Any SnapView replica (snapshot or BCV) can be used to
perform the restore operation.
SnapView is part of EMCs industry-leading replication family.. EMCs replication products are designed
to provide users the highest levels of flexibility combined with functionality. SnapViews dual-feature
capabilities have benefited customers in all industries by providing users the tools to fit their specific
business application needs.

Using SnapView for Business Applications

Accelerating Business Processes 11
 12/3/2004

Appendix
The charts in this appendix provide performance information for BCVs and snapshots. The information is
intended to provide a conceptual understanding of the differences among various performance parameters,
rather than any specific sizing or performance estimates. For specific sizing and performance estimates,
users should consult their EMC account team.

BCV Performance
As noted earlier, users can select among high, medium, and low sync rates. In some situations, users might
select the high synchronization rate so that they can synchronize their BCV as quickly as possible; whereas
in other cases, users might select the low or medium synchronization rate to free up SP resources to
perform other tasks while the synchronization takes place. The tradeoff is between how quickly the BCV
needs to be synchronized, and what other tasks are taking place during the synchronization.
Figure 3 shows the bandwidth at each synchronization rate. ATA performance is shown as well.

FC
High Sync Rate
MB/Sec

ATA
High Sync Rate

FC& ATA
Medium Sync Rate
FC & ATA
Low Sync Rate
1 2 3 4
Number of Target LUNs

Figure 3. Bandwidth during BCV Synchronization

For both the low and medium sync rates, the ATA drives and Fibre Channel drives achieved the same
bandwidth figures. This is because the SP is essentially throttling the writes to the drives; so the ATA is
able to keep up with the Fibre Channel drives. At the high synchronization rate, where the SP allows
greater bandwidth in order to sync the BCV as quickly as possible, the difference between BCVs created on
Fibre Channel drives as compared to ATA drives becomes more noticeable.
In addition to considering the achievable bandwidth at each sync rate, it is important (and in many cases,
more important) to consider the impact of the sync operations on the source LUN. Figure 4 shows the
effect on source I/O during various BCV states, with BCV LUNs on both Fibre Channel and ATA drives.

Using SnapView for Business Applications

Accelerating Business Processes 12
 12/3/2004

Fibre Fibre ATA Fibre Fibre

Transactions per Minute

ATA

ATA

Baseline Fractured In-Sync Re-Sync

BCV Operations

Figure 4. OLTP Transactions per Minute during Initial BCV Synchronization

As illustrated in Figure 4, there is no impact on the source LUN when the BCV is fractured for either Fibre
Channel or ATA drives, which is the performance benefit of using BCVs. From the performance
standpoint, this is why users want to ensure that the BCV is fractured as soon as it is resynchronized.
(From a data protection standpoint, it is also important to fracture the BCV as soon as possible to ensure the
known good point-in-time condition of the data.)
When the BCV is in sync, however, there is a noticeable impact on the server where the BCV is on an ATA
drive. This is because once synchronized and until fractured, the server writes to the source LUN are
simultaneously written to the BCV. If the BCV is bound on ATA drives and the write cache becomes full,
the transaction rate will be reduced to ATA performance rates.
Finally, the impact on the server due to synchronization operations must also be considered. These figures
are based on synchronizations performed at the high sync rate. The graph demonstrates only a slight
decrease in transactions per minute for BCVs on Fibre Channel. The difference is more pronounced for
BCVs on ATAagain because once the write cache fills up, the performance difference between Fibre
Channel and ATA becomes more noticeable.
Users can counter-balance the server impact with the selected sync rate. That is, although the high sync rate
has a greater impact on OLTP TPM, it allows the user to copy a significant amount of data at a time, thus
reducing the amount of time spent in the synchronization operation. At low sync rate, on the other hand,
the bandwidth is less, thus extending the amount of time spent in the synchronization operation. As noted
earlier in the paper, users can also minimize the performance impact by scheduling BCV synchronizations
during off-peak hours.

Using SnapView for Business Applications

Accelerating Business Processes 13
 12/3/2004

Snapshot Performance
As with BCVs, users must consider the impact of snapshots and Snap sessions on the source LUN. Figure
5 compares the effect on OLTP response time with multiple Snap sessions running on a source.
Additionally, the results compare the performance of reserved LUNs bound on Fibre Channel drives with
those bound on ATA drives.

ATA ATA

ATA
Average Response Time (ms)

Fibre
ATA Fibre
ATA
Fibre ATA
Fibre
ATA ATA Fibre 719
Fibre Fibre
Fibre

1 2 3 4 5 6 7 8
Number of Sessions

Figure 5. Response Time Comparison of Reserved LUNs on FC and ATA drives

Figure 5 clearly demonstrates that there is an effect on the source LUN when the first Snap session is
started; starting additional Snap sessions, however, adds only incremental performance impact. Thus, for
users leveraging the multiple point-in-time-view feature of Snap sessions, the benefits are clearminor
added performance impact for multiple views.
Additionally as shown in this graph, the difference between Reserved LUNs on Fibre Channel drives, and
those on ATA drives is negligible until the user scales to four sessions (on a single source LUN).

Performance Conclusions
To conclude, SnapView BCVs and snapshots essentially offer users a tradeoff between space capacity and
performance. Likewise, users can select between Fibre Channel and ATA drives, again depending on the
price-to-performance balance that is appropriate for the data that is under consideration. This performance
data is provided for the purpose of helping users make educated decisions about the replication options that
best suit their environment.

Using SnapView for Business Applications

Accelerating Business Processes 14