Download STORAGE TIERING FOR DB2 FOR LINUX, UNIX, AND WINDOWS (LUW) WITH

White Paper
STORAGE TIERING FOR DB2 FOR LINUX,
UNIX, AND WINDOWS (LUW) WITH
EMC SYMMETRIX VMAX AND ENGINUITY 5875
Using Enhanced Virtual LUN Technology, FAST, and FAST VP
in DB2 LUW environments
Abstract
As the need for information continues to grow, businesses are
forced to address an ever-increasing demand for storage while
keeping costs to a minimum. One way to achieve this is by
effectively using Enterprise Flash Drives, Fibre Channel drives,
and SATA drives to provide high-performance storage for
mission-critical applications and cost-effective storage for noncritical operations. Matching business needs with drive types is
known as “tiering,” and this paper describes how storage tiering
and EMC® Symmetrix® VMAX™ can be used in a DB2 LUW
environment.
January 2011
Copyright © 2009, 2010, 2011 EMC Corporation. All Rights
Reserved.
EMC believes the information in this publication is accurate 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 h6732.2
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
2
Table of Contents
Executive summary.................................................................................................. 5
Audience ............................................................................................................................ 6
Introduction ............................................................................................................ 6
The evolution of storage tiering ................................................................................ 8
Symmetrix product and features overview ................................................................ 9
Symmetrix VMAX ................................................................................................................ 9
Symmetrix Auto-provisioning Groups................................................................................ 10
Symmetrix Management Console (SMC) ........................................................................... 11
Symmetrix Enterprise Flash Drives .................................................................................... 12
Symmetrix Enhanced Virtual LUN (VLUN) Technology........................................................ 13
Enhanced VLUN migration ................................................................................................ 13
Fully Automated Storage Tiering (FAST) ............................................................................. 14
How FAST is configured ................................................................................................ 15
FAST algorithms ........................................................................................................... 15
Device movement ......................................................................................................... 16
Virtual Provisioning .......................................................................................................... 16
Fully Automated Storage Tiering with Virtual Pools (FAST VP) ............................................ 17
How FAST VP is configured ........................................................................................... 18
FAST VP algorithms....................................................................................................... 19
Data movement ............................................................................................................ 19
Limitations and restrictions .......................................................................................... 20
DB2 9.7 for Linux, UNIX, and Windows ................................................................... 20
Servers, instances, and databases ................................................................................... 20
Objects that make up a DB2 database environment ......................................................... 21
A closer look at table spaces ............................................................................................ 23
Raw devices versus files ............................................................................................... 25
Table space types......................................................................................................... 26
The system catalog table space .................................................................................... 27
Creating additional table spaces .................................................................................. 27
Modifying existing table spaces ................................................................................... 27
Automatic storage databases ........................................................................................... 28
Using the snapshot monitor to identify “hot” logical volumes .......................................... 28
Working with Enhanced Virtual LUN Technology and DB2 LUW databases ............... 30
Manual storage tiering mechanics .................................................................................... 30
Manual storage tiering examples ...................................................................................... 30
Scenario and results..................................................................................................... 31
Summary ...................................................................................................................... 37
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
3
Working with FAST and DB2 LUW databases ........................................................... 37
FAST considerations for DB2 LUW databases using automatic storage ............................. 38
FAST storage tiering mechanics ........................................................................................ 38
FAST storage tiering examples .......................................................................................... 38
Scenario and results..................................................................................................... 38
FAST setup for database DB-3 management ................................................................. 42
Summary ...................................................................................................................... 46
Conclusion ............................................................................................................ 47
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
4
Executive summary
EMC® Symmetrix® VMAX™ is the newest addition to the Symmetrix product line. Built
on the strategy of simple, intelligent, modular storage, it incorporates a new scalable
Virtual Matrix™ interconnect design that allows the storage array to seamlessly grow
from an entry-level configuration into a 2 petabyte storage system. Symmetrix VMAX
provides improved performance and scalability for demanding enterprise storage
environments while maintaining support for EMC’s broad portfolio of platform
software offerings.
EMC Symmetrix VMAX delivers enhanced capability and flexibility for deploying DB2
for Linux, UNIX, and Windows (LUW) databases throughout the entire range of
business operations, from test and development to mission-critical applications.
Typically, each database has its own performance and reliability requirements and to
support a wide range of needs, while delivering optimum performance at minimum
cost, Symmetrix VMAX arrays support multiple drive technologies including Enterprise
Flash Drives (EFD), Fibre Channel (FC) drives – both 10k rpm and 15k rpm – and 7200
rpm Serial ATA (SATA) drives. In addition, various RAID protection mechanisms are
available, and each can affect the performance, availability, and economic impact of
a given DB2 LUW database.
Since customers are under increasing pressure to improve performance as well as
their return on investment (ROI) for storage technologies, ensuring that data is placed
on the most effective storage type (that is, the combination of drive type and RAID
protection scheme) is a key requirement. Due to the nature of the applications that
they serve, database systems typically direct the most significant workloads to a
relatively small subset of the data stored in a database; the bulk of the data is usually
accessed much less frequently. This can lead to an imbalance of I/O load across the
LUNs used by the database – the LUNs containing the most frequently accessed
subset of data will have a much higher utilization than the LUNs containing the rest of
the database. (This phenomenon is referred to as “LUN access skewing” or simply
“skewing.”) Therefore, by placing these LUNs on the appropriate storage resource,
performance can often be increased, the total number of physical drives required can
be reduced, and the total cost of ownership (TCO) and ROI for most database
deployments can be improved.
As companies increase deployment of multiple drive and protection types in their
high-end storage arrays, storage administrators (and in some cases, database
administrators) are presented with the challenge of selecting the correct storage
configuration for each application being deployed. Usually, a single storage type is
selected for all of the data in a given database, effectively placing both active and idle
data portions on fast FC drives. This approach can be expensive and inefficient since
data that is infrequently accessed will reside on expensive, high-performance drives.
Alternatively, making use of high-density, low-cost SATA drives for less active data, FC
drives for medium active data, and EFDs for very active data, allows efficient use of
storage system resources and reduces the overall cost and number of drives needed.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
5
This, in turn, helps to reduce energy requirements and floor space needs, allowing the
business to grow more rapidly.
Audience
This white paper is intended for DB2 LUW database administrators, storage
administrators, storage architects, customers, and EMC field personnel who want to
understand storage tiering as it relates to DB2 LUW databases stored on a Symmetrix
VMAX running Enginuity™ version 5875.
Introduction
To achieve a “tiered” storage approach with DB2 LUW databases, it is possible to use
Symmetrix Enhanced Virtual LUN Technology to move devices between drive types
(EFD, FC, and SATA) and RAID protection schemes seamlessly inside a Symmetrix
VMAX array. Symmetrix Virtual LUN or VLUN technology doesn’t require application
downtime and because it preserves device IDs, there is no need to change file system
mount points, volume manager settings, or database file locations after a device has
been moved. Symmetrix Virtual LUN technology also preserves any TimeFinder® or
SRDF® business continuity aspects, even as the data migration takes place.
The manual and often time-consuming approach to storage tiering can be automated
using Fully Automated Storage Tiering or FAST. FAST automates the identification of
data volumes for the purposes of relocating application data across different
performance/capacity tiers within an array. Based on policy guidance and the actual
workload profile (measured over time), the FAST controller will recommend or
automatically execute the movement of managed devices between the storage types.
VLUN and FAST are complementary technologies. With VLUN, device movement is
initiated by the user and then executed seamlessly in the storage array; with FAST, a
device movement plan is automatically recommended (and optionally executed
seamlessly) by the FAST controller. FAST, also known as standard FAST, operates on
standard, non-thin, Symmetrix devices and data movement is performed at the full
volume level. Fully Automated Storage Tiering with Virtual Pools (FAST VP) operates
on Virtual Provisioning™ thin devices. As such, data movements executed can be
performed at the sub-LUN level, and a single thin device may have extents allocated
across multiple thin pools within the array. Because FAST and FAST VP support
different device types – standard and thin, respectively – they both can operate
simultaneously within a single array. Aside from some shared configuration
parameters, the management and operation of each can be considered separately.
As described earlier, almost any application generates data access skewing. In other
words, some portions of data are heavily accessed, some are accessed to a lesser
degree, and often some portions are hardly accessed at all and are maintained only
for legacy or regulations or for lack of a good Information Lifecycle Management (ILM)
or partitioning strategy. Because database administrators (DBAs) tend to plan for the
worst peak workloads, they usually place almost all of a database’s data onto a
single storage type that is based on fast FC (10k or 15k rpm) drives. While placing an
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
6
entire database onto a single type of storage resource makes storage management
easier, it is also very wasteful when using a high-end storage array such as a
Symmetrix VMAX since data access skewing is not taken into account. Another factor
that is usually not taken into account is the fact that different databases typically
have different I/O workload profiles – some heavy and some light, some sequential
and some random, and so on. By placing each database into its own set of file
systems, or other volume manager disk groups, it makes it easier to place the right
data on the right storage type. This approach also helps when using local and remote
storage replication techniques and with general performance monitoring since it
provides better granularity. As described earlier, such efficient data placement
reduces overall cost, energy consumption, and storage footprint while at the same
time increases database performance.
Data access skewing can exist between individual databases and within a single
database. For example by capturing a DB2 snapshot of table space and buffer pool
activity, it is easy to identify which table spaces are heavily utilized and alternatively
which table spaces are hardly utilized at all. And in large database environments,
users can provide optimized access to data by taking advantage of range partitioned
tables and DB2’s Database Partitioning Feature (DPF). In such databases, active
partitions can reside on fast storage types (EFD and FC) to improve performance while
inactive partitions can reside on SATA drives to reduce cost. At a minimum EMC
recommends that database data be separated from log files (so when TimeFinder is
used for offload backups and restores transaction logs are not overwritten) and
temporary table space data when remote replication like SRDF is used (no need to
replicate temporary data since it is not needed for database recovery).
This white paper provides an in-depth discussion on using Symmetrix VMAX
Enhanced Virtual LUN (VLUN), Fully Automated Storage Tiering (FAST), and Fully
Automated Storage Tiering with Virtual Pools (FAST VP) technologies with DB2 LUW
databases. To keep things simple, this paper focuses on skewing between
databases. The examples presented represent three distinct databases running OLTPtype workloads (~70/30 random read/write ratio) where Database 1 (DB-1) has a very
low workload and is in fact a target for storage cost reduction, Database 2 (DB-2) has
a medium workload and is somewhat important, and Database 3 (DB-3) is a very
visible, mission-critical database that executes the largest workload. These examples
are used to show how to identify when the workloads are on the wrong storage type,
as well as how to use each of the technologies available to migrate them to their right
storage type while achieving the business goals of cost reduction or improved
performance.
The Solutions Enabler Command Line Interface (SYMCLI) or the Symmetrix
Management Console (SMC) graphical user interface (GUI) can be used to manage
either technology (VLUN, FAST, or FAST VP). However, when discussing VLUN
migrations, the focus of this paper will be on SYMCLI and when discussing FAST the
focus will be on SMC as it is assumed that manual-initiated data migrations are often
called from scripts and automation tools are more easily managed using a GUI. Other
management tools that can help with VLUN, FAST, and FAST VP management and
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
7
monitoring are EMC Ionix™ ControlCenter®, Symmetrix Performance Analyzer (SPA),
and others. Their use is not covered in this paper.
The evolution of storage tiering
From a business perspective, “storage tiering” generally means that policies coupled
with storage resources having distinct performance, availability, and other
characteristics are used to meet the service level objective (SLO) for a given
application. (By SLO we mean a targeted I/O service goal, that is, performance for an
application.) This remains the case with Fully Automated Storage Tiering (FAST).
For administrators, the definition of Storage Tiering is evolving. Initially, different
storage platforms met different SLOs. For example:
Gold Tier – Symmetrix; Silver Tier – CLARiiON®; Bronze Tier – Tape
More recently, storage tiering meant that multiple SLOs are achievable in the same
array:
Gold Tier – 15k, FC RAID 1; Silver Tier – 10k, FC RAID 5; Bronze Tier – 7.2k, SATA,
RAID 6
FAST changes the categories further. Because multiple storage types can support the
same application, “tier” is not used to describe a category of storage in the context of
FAST. Rather, with EMC, the following new terms are used:
Storage group – logical grouping of volumes (often by application) for common
management
Storage class – combination of storage types and FAST policies to meet servicelevel objectives for storage groups
FAST policies - policies that manage data placement and movement across
storage types to achieve service levels for one or more storage groups
Storage type – a shared storage resource with common technologies, namely
drive type and RAID scheme
For example, users might establish a Gold Storage Class as follows:
Service level objective
Storage class
FAST policy
Storage type
Read/write response time
objective
Gold
10%
15k rpm RAID 1
40%
10k rpm RAID 5
50%
7.2k rpm SATA RAID 6
Figure 1 provides a quick summary of the relationship between storage types, FAST
policies, and storage groups.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
8
Figure 1. FAST relationships
Throughout the rest of this paper, storage type at times will be referred to as
Symmetrix tier, in order to map clearly to specific commands in tools such as SMC.
"FAST policies" and "storage groups" will remain the same.
Symmetrix product and features overview
The following sections provide a brief summary of EMC Symmetrix technologies that
must be understood in order to use a storage tiering strategy with DB2 LUW
databases.
Symmetrix VMAX
Symmetrix VMAX, the newest member of the Symmetrix family, is a revolutionary new
storage system that is purpose-built to meet virtual data center requirements. Based
on the Virtual Matrix Architecture™ and new Enginuity capabilities, Symmetrix VMAX
scales performance and capacity to unprecedented levels, delivers nondisruptive
operations, and greatly simplifies and automates the management and protection of
information.
Symmetrix VMAX arrays extend the scalability of previous generations of Symmetrix
DMX™ technology, by providing a superior level of scalability and support for a broad
new range of drive technologies. The Symmetrix VMAX design is based on individual
high-availability engines with redundant CPU, memory, and connectivity on two
directors for fault tolerance. Each VMAX Engine controls eight redundant Fibre
Channel loops that support up to either 240 or 360 drives depending upon the
configuration. Furthermore, VMAX Engines connect to and scale out linearly through
the Virtual Matrix Architecture, which allows resources to be shared within and across
multiple engines. To meet growth requirements, additional VMAX Engines can be
added nondisruptively for efficient and dynamic scaling of capacity and performance
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
9
that is available to any application on demand. A basic overview of Symmetrix VMAX
specifications is shown in Figure 2.
 1 to 8 redundant VMAX Engines
 Up to 2.1 PB usable capacity
 Up to 128 FC FE ports
 Up to 64 FICON FE ports
 Up to 64 GigE/iSCSI FE ports
 Up to 1 TB global memory (512 GB usable)
 48 to 2,400 drives
 Enterprise Flash Drives 200/400 GB
 FC drives 146/300/450 GB 15k rpm
 FC drives 300/450/600 GB 10k rpm
 SATA drives 1 TB 7.2k rpm
Figure 2. Symmetrix VMAX hardware scalability
The Symmetrix VMAX system also maintains customer expectations for high-end
storage in terms of availability. High-end availability is more than just redundancy; it
means nondisruptive operations and upgrades, and being “always online.” Beyond
previous Symmetrix generations, Symmetrix VMAX arrays provide:
Nondisruptive expansion of capacity and performance at a lower price point
Sophisticated migration for multiple storage tiers within the array
The power to maintain service levels and functionality as consolidation grows
Simplified control for provisioning in complex environments
Symmetrix VMAX is the only high-end platform with multi-core processors that
provide maximum performance and energy-efficient capabilities in each VMAX
Engine. This unique feature allows entry-level Symmetrix VMAX configurations to
deliver significantly more performance in a smaller footprint than any other storage
array.
Symmetrix Auto-provisioning Groups
Enginuity 5874 provides storage and system administrators with a simplified model
for storage provisioning referred to as Auto-provisioning Groups. Auto-provisioning
Groups are implemented using the symaccess CLI command with Solutions Enabler
7.0 and later or by using the Symmetrix Management Console (SMC).
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
10
The fundamental concept of Auto-provisioning Groups is the logical grouping of
related objects and the creation of a view that associates related groupings of objects
with each other. The following logical groupings are used:
Initiator groups. An initiator group is a logical grouping of up to 32 Fibre Channel
initiators (identified by World Wide Names or WWNs) or eight iSCSI names or a
combination of the two. An initiator group may also contain the name of another
initiator group, allowing initiator groups to be cascaded to a depth of one.
Port groups. A port group is a logical grouping of Fibre Channel and/or iSCSI frontend director ports.
Storage groups. A storage group is a logical grouping of up to 4,096 Symmetrix
devices. LUN addresses are assigned to the devices in the storage group when a
masking view is created via the dynamic LUN addressing feature.
Masking views. A masking view defines an association between one initiator
group, one port group, and one storage group. When a masking view is created,
the devices in the storage group are mapped to the ports in the port group and
masked to the initiators in the initiator group. Depending on the server and
application requirements, each server or group of servers may have one or more
masking views that associate a set of Symmetrix devices to an application, server,
or cluster of servers.
With Auto-provisioning Groups, related initiators (HBAs) are grouped into an initiator
group, related front-end ports are grouped into a port group, and related devices are
grouped into a storage group. A masking view is then used to associate these groups
with each other. At the time the masking view is created, all the required mapping
and masking are performed automatically in a single operation. This approach
dramatically reduces complexity and simplifies storage allocation.
Symmetrix Management Console (SMC)
Many large enterprise data centers have stringent change control processes that
ensure reliable execution of any modification to their IT infrastructure. Often changes
are implemented using scripts that are fully documented, have been thoroughly
tested, and can be consistently executed by all storage administrators. However, an
alternative to using scripts is to use the Symmetrix Management Console (SMC).
SMC is a GUI that allows storage administrators to easily manage a Symmetrix. SMC
can be run on any open systems host that is connected to a Symmetrix VMAX that
requires management. Alternatively, SMC can be installed and enabled on the
Symmetrix VMAX service processor and SMC functions can be used by directing a
browser to the service processor at port 8443. An example of the SMC can be seen in
Figure 3.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
11
Figure 3. The Symmetrix Management Console
Symmetrix Enterprise Flash Drives
With the introduction of Enterprise Flash Drives (EFDs), EMC has created a new ultraperformance storage capability that removes previous performance limitations
imposed by the physical characteristics of magnetic disk drives.
EFDs dramatically increase performance for latency-sensitive databases like DB2
LUW. EFDs, also known as solid state drives (SSD), contain no moving parts, thereby
removing much of the storage latency delay associated with traditional magnetic disk
drives. A Symmetrix VMAX with EFDs can deliver single-millisecond application
response times and up to 30 times more I/O operations per second (IOPS) than
traditional Fibre Channel hard disk drives (HDDs). Additionally, because there are no
mechanical components, EFDs consume significantly less energy than hard disk
drives. In fact, when replacing a larger number of HDDs with a lesser number of EFDs,
energy consumption can be reduced by up to 98 percent for a given IOPS workload.
The high-performance characteristics of EFDs eliminate the need for organizations to
purchase large numbers of traditional hard disk drives, while only utilizing a small
portion of their capacity to satisfy the IOPS requirements of database. (The practice of
underutilizing a hard disk drive for increased performance is commonly referred to as
short-stroking.) EFDs can increase database performance and eliminate the need to
short-stroke drives, thereby keeping storage footprint and power consumption to a
minimum while reducing TCO.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
12
Symmetrix Enhanced Virtual LUN (VLUN) Technology
Enginuity 5874 provides an enhanced version of Symmetrix Virtual LUN (VLUN)
software to enable transparent, nondisruptive data mobility of devices between
storage types and/or RAID protection schemes. VLUN technology leverages a feature
introduced in Enginuity 5874 called RAID Virtual Architecture (RVA), which abstracts
device protection from its logical representation to the host. RVA allows a device to
have more simultaneous protection types such as BCVs, SRDF, Concurrent SRDF, and
spares. It also enables seamless, nondisruptive transition from one drive type to
another or from one RAID protection scheme to another, while hosts and their
associated applications and Symmetrix software are accessing a device. This
architecture is a significant change from previous RAID implementations and is only
available with the Symmetrix VMAX platform.
Enhanced VLUN migration
The Enhanced Virtual LUN Technology migration feature introduced with Symmetrix
VMAX provides users with the ability to move Symmetrix logical devices between
drive types, such as high-performance EFDs, FC drives, or high-capacity low-cost SATA
drives and RAID protection schemes. All migration combinations of drive types and
protection types are valid with the exception of unprotected volumes.
While the back-end device characteristics change (physical drive type and/or RAID
protection) the migrated devices’ identities remain the same, allowing seamless
online migration. Logical devices can be migrated to either unallocated space (also
referred to as unconfigured space) or to configured space, which is defined as
existing Symmetrix volumes within the same subsystem that are not currently
assigned to a host.
The advantages of migrating data using VLUN technology are ease of use, efficiency,
and simplicity. Data is migrated in the Symmetrix back end without requiring any
additional SAN or host resources. Furthermore, a migration is considered a safe
operation since the target is treated internally as just another “mirror” of the logical
device, although with its own drive type and RAID protection scheme. At the end of
the migration, data on the original source volume(s) is cleared using instant VTOC to
preserve security. Device migration is completely transparent to both the host
operating system and applications running on the host and the pace of migration can
be controlled using Symmetrix quality of service (symqos) commands. And because
the identity of a device doesn’t change (in other words, a device’s host address is not
altered), operations running on the host are not interrupted and additional host
changes, backup script updates, volume manager operations, or changes in file
system mount points are not needed.
Enhanced VLUN migration technology is fully integrated with Symmetrix replication
technology and maintains consistency and source/target device relationships in
replication operations such as SRDF, TimeFinder/Clone, TimeFinder/Snap, or Open
Replicator. A migration does not require swap or Dynamic Relocation Volumes (DRVs)
space, and is nondisruptive to internal Symmetrix applications such as TimeFinder
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
13
and SRDF. Furthermore, in SRDF environments, a migration does not require
customers to re-establish their disaster recovery protection after a migration occurs.
Enhanced VLUN migration helps customers implement an ILM strategy for their
databases, such as the movement of the entire database, specific table spaces, or
table partitions between storage types. It also allows adjustments in service levels
and performance requirements to application data. For example customers often
provision storage for a particular application before clear performance requirements
are known. Enhanced VLUN migration makes it possible to better utilize storage at a
later time, once the requirements are better understood.
Fully Automated Storage Tiering (FAST)
Introduced in the Enginuity 5874 Q4 service release, EMC Symmetrix VMAX FAST is
Symmetrix software that utilizes intelligent algorithms to continuously analyze device
I/O activity and generate plans for moving and swapping devices for the purposes of
allocating or re-allocating application data across different performance storage types
within a Symmetrix array. FAST (also known as standard FAST) proactively monitors
workloads at the Symmetrix device (LUN) level in order to identify “busy” devices that
would benefit from being moved to higher-performing drives such as EFDs. FAST will
also identify less “busy” devices that could be relocated to higher-capacity, more
cost-effective storage such as SATA drives without altering performance.
Time windows can be defined to specify when FAST should collect performance
statistics (upon which the analysis to determine the appropriate storage type for a
device is based), and when FAST should perform the configuration changes necessary
to move devices between storage types. Movement is based on user-defined storage
types and FAST policies.
The primary benefits of FAST include:
Automating the process of identifying volumes that can benefit from EFD and/or
that can be kept on higher-capacity, less-expensive drives without impacting
performance
Improving application performance at the same cost, or providing the same
application performance at lower cost. Cost is defined as space, energy,
acquisition, management, and operational expense
Optimizing and prioritizing business applications, allowing customers to
dynamically allocate resources within a single array
Delivering greater flexibility in meeting different price/performance ratios
throughout the lifecycle of the information stored
The management and operation of FAST can be conducted using either the Symmetrix
Management Console (SMC) or the Solutions Enabler Command Line Interface
(SYMCLI). Additionally, detailed performance trending, forecasting, alerts, and
resource utilization are provided through the Symmetrix Performance Analyzer (SPA).
And if so desired, EMC Ionix ControlCenter provides the capability for advanced
reporting and analysis that can be used for chargeback and capacity planning.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
14
How FAST is configured
FAST is configured by defining three distinct objects:
Storage groups are a logical collection of Symmetrix volumes that are to be
managed together. Storage group definitions are shared between FAST and Autoprovisioning Groups; however, a Symmetrix device may only belong to one
storage group that is under FAST control.
Storage types are a combination of a drive technology (for example, EFD, FC, or
SATA) and a RAID protection type (for example, RAID 1, RAID 5 3+1, RAID 5 7+1,
RAID 6 6+2, and RAID 6 14+2). There are two types of storage types – static and
dynamic. A static storage type contains explicitly specified physical disk groups,
while a dynamic storage type will contain disk groups of the same drive
technology. A storage type will contain at least one Symmetrix disk group but can
contain more than one. If more than one disk group is contained in a storage type,
the disk groups must be of a single drive technology type.
FAST policies associate a set of storage groups with up to three storage types.
When a storage group is associated with a FAST policy, the policy defines the
maximum percentage of devices in the storage group that can exist in a particular
storage type. The percentage of storage specified for each storage type in the
policy, when aggregated, must total at least 100 percent; in some cases, however,
it may total more than 100 percent. For example, if the storage groups associated
with a FAST policy are allowed 100 percent in any of the storage types, FAST can
recommend for all the storage devices to be placed together on any one storage
type (capacity limit on storage types is not forced). In another example, to force a
storage group to a specific storage type, simply set the policy to 100 percent on
that type and 0 percent on all other types. At the time of association, a storage
group may also be given a priority (between 1 and 3) with a policy. If a conflict
arises between multiple active FAST policies, the priority will help determine
which policy gets precedence.
(Refer to Figure 1 on page 9 to see the relationship between storage groups, storage
types, and FAST policies.)
FAST can be configured to operate in a “set it and forget it” mode (Automatic) where
the system will continually gather statistics, and analyze, recommend, and execute
moves and swaps to maintain optimal configuration based on policy, or in a “user
approval” mode (User Approved) where all configuration change plans recommended
by FAST must be approved before they will be executed.
FAST algorithms
FAST uses three distinct algorithms when determining the appropriate tier a device
should belong to. The algorithms used, in order of probability, are:
EFD promotion/demotion algorithm
Capacity-based algorithm
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
15
FC/SATA cross-tier algorithm
The goal of the EFD promotion/demotion algorithm is to maximize EFD drive
utilization within the array. This algorithm will list all devices in the array, in the order
of which devices would be best served by being configured on EFD. FAST will then
attempt to place those devices onto EFDs.
The goal of the capacity-based algorithm is to enforce the FAST policy storage usage
rules. A storage group is considered to be in violation when a higher percentage of
devices exist on a tier than is configured in the policy for that tier.
The goal of the FC/SATA cross-tier algorithm is to balance utilization across Fibre
Channel and SATA technologies. This algorithm will sort devices by drive service time,
and the most utilized devices will be moved to the least utilized drives.
If Optimizer is also enabled on the Symmetrix, then the traditional Optimizer
algorithm will be used to balance the load within a physical disk group.
Device movement
There are two methods by which a device will be relocated to another tier: move or
swap. A move occurs when unconfigured (free) space exists in the target storage
type. Only one device is involved in a move, and a DRV is not required. Moves are
performed by creating new devices in unconfigured space on the appropriate storage
type, moving the data to the new device(s), and deleting the old device(s). A swap
occurs when there is no unconfigured space in the target storage type, and results in
a corresponding device being moved out of the target storage type. In order to
preserve data on both devices involved in the swap a single DRV is used. (The DRV
used should be sized to hold the largest FAST controlled devices available.)
Moves and swaps are completely transparent to the host and applications and can be
performed nondisruptively, without affecting business continuity and data
availability. Symmetrix metadevices are moved as a complete entity; therefore,
metadevice members cannot exist in different Symmetrix disk groups.
FAST optimizes application performance in Symmetrix VMAX arrays that contain
drives of different technologies. It is expected that customers will have their arrays
configured with EFD, FC, and/or SATA drives, resulting in storage tiers with different
performance levels. Rather than leave applications and data statically configured to
reside on the same storage type, FAST will allow customers to establish the
definitions and parameters necessary for automating data movement from one type
to another according to current data usage.
Virtual Provisioning
Introduced with Enginuity 5773, Symmetrix Virtual Provisioning provided a new type
of host-accessible device, called a thin device, that could be used in many of the
same ways that regular, host-accessible Symmetrix devices have traditionally been
used. Unlike regular Symmetrix devices, thin devices do not need to have physical
storage completely allocated at the time they are created and presented to a host.
The physical storage that is used to supply drive space for a thin device comes from a
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
16
shared thin storage pool that has been associated with the thin device. A thin storage
pool is comprised of a new type of internal Symmetrix device called a data device that
is dedicated to the purpose of providing the actual physical storage used by thin
devices. When they are first created, thin devices are not associated with any
particular thin pool – an operation referred to as “binding” must be performed to
associate a thin device with a thin pool.
When a write is performed to a portion of the thin device, the Symmetrix allocates a
minimum allotment of physical storage from the pool and maps that storage to a
region of the thin device including the area targeted by the write. The storage
allocation operations are performed in small units of storage called “track groups.”
(These track groups may also be called “chunks.”) A round-robin mechanism is used
to balance the allocation of data device extents across all of the data devices in the
pool that are enabled and that have remaining unused capacity. The track group size
is 12 tracks (768 KB). That means that the initial bind of a thin device to a pool
causes one track group, or 12 tracks, to be allocated per thin device.
When a read is performed on a thin device, the data being read is retrieved from the
appropriate data device in the storage pool to which the thin device is bound. Reads
directed to an area of a thin device that has not been mapped do not trigger
allocation operations. The result of reading an unmapped block is that a block in
which each byte is equal to zero will be returned. When more storage is required to
service existing or future thin devices, data devices can be added to existing thin
storage pools. New thin devices can also be created and associated with existing thin
pools.
Prior to Enginuity 5875, a thin device could only be bound to, and have tracks
allocated in, a single thin storage pool. This thin storage pool could, in turn, only
contain Symmetrix data devices of a single RAID protection type, and a single drive
technology (and single rotation speed in the case of FC and SATA drives). With
Enginuity 5875, a thin device will still only be considered bound to a single thin pool
but may have tracks allocated in multiple pools within a single Symmetrix. A thin
device may also be “re-bound” to a different thin pool, without any loss of data or
data access. These new features provide the ability to migrate a thin device from one
thin pool to another.
Fully Automated Storage Tiering with Virtual Pools (FAST VP)
Introduced in the Enginuity 5875, FAST VP automates tiered storage strategies, in
Virtual Provisioning environments, by easily moving workloads between Symmetrix
tiers as performance characteristics change over time. Like FAST, FAST VP automates
the identification of data volumes for the purposes of relocating application data
across different performance/capacity tiers within an array. Unlike FAST, FAST VP
proactively monitors workloads at both the LUN and sub-LUN level in order to identify
“busy” data that would benefit from being moved to higher-performing drives such as
EFDs and less “busy” data that could be relocated to higher-capacity, more costeffective storage such as SATA drives without altering performance. (The minimum
amount of data that will be queued for movement is 10 thin device extents – referred
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
17
to as an extent group. Each extent group represents 7,680 KB of contiguous logical
address space on a thin device.) This promotion/demotion activity is based on
policies that associate a storage group to multiple drive technologies, or RAID
protection schemes, via thin storage pools, as well as the performance requirements
of the application contained within the storage group. Data movement executed
during this activity is performed nondisruptively, without affecting business
continuity and data availability.
The primary benefits of FAST VP include:
Best utilization of EFD for high-performance workloads
Lower overall total cost of storage by placing inactive data on SATA drives
Better performance than all-Fibre Channel configurations, but at a lower cost,
requiring fewer drives, less power and cooling, and a smaller footprint
Radically simplified management in a tiered environment
Greater flexibility in meeting different price/performance ratios throughout the
lifecycle of the information stored
As with FAST, the management and operation of FAST VP can be conducted using
either the SMC or SYMCLI. Additionally, detailed performance trending, forecasting,
alerts, and resource utilization are provided through the SPA. And if so desired, EMC
Ionix ControlCenter provides the capability for advanced reporting and analysis that
can be used for chargeback and capacity planning.
How FAST VP is configured
Similar to FAST, FAST VP is configured by defining three distinct objects:
Storage groups are a logical collection of Symmetrix volumes, typically associated
with an application, that are to be managed together. Storage group definitions
are shared between FAST and Auto-provisioning Groups; however, a Symmetrix
device may only belong to one storage group that is under FAST control.
FAST policies contain a set of tier usage rules that can be applied on one or more
storage groups. A FAST VP policy groups between one and three tiers and assigns
an upper usage limit for each VP tier. The upper limit specifies how much
allocated capacity of the thin devices in an associated storage group can reside
on that particular VP tier.
VP tiers contain thin storage pools of a matching drive technology (EFD, FC, or
SATA) and a RAID protection type. A VP tier must contain at least one thin storage
pool, but can contain up to four. If more than one thin pool is assigned to a VP
tier, the thin pools must be of the same drive technology type and must use the
same RAID protection scheme.
The upper capacity usage limit for each VP tier is specified as a percentage of the
configured capacity of the thin devices in the associated storage group. The usage
limit for each tier must be between 1 percent and 100 percent. When combined, the
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
18
upper usage limit for all Symmetrix tiers in the policy must total at least 100 percent,
but may be greater than 100 percent.
FAST VP algorithms
FAST VP uses two distinct algorithms when determining the appropriate VP tier data
should reside on. The algorithms used are:
Intelligent tiering algorithm
Allocation compliance algorithm
The intelligent tiering algorithm uses sub-LUN level performance metrics to determine
the appropriate tier for the data on each thin device under FAST VP control. This
determination is made using the long-term and short-term FAST VP metrics with the
goal of optimizing performance and cost-efficiency. The result of the overall intelligent
tiering algorithm is a set of data movement requests that get submitted to and
executed by the VLUN VP data movement engine.
The allocation compliance algorithm detects when the allocated capacity of a storage
group exceeds the capacity allowed in a single tier, based on the usage limit
specified within the FAST policy. The result of the allocation compliance algorithm is a
set of specific data movements that will bring the allocated capacity storage group
back within the boundaries specified by the associated policy.
The intelligent tiering algorithm and the allocation compliance algorithm are
coordinated in such a way so as not to work at cross purposes.
Data movement
There are two types of data movement that can occur under FAST VP – both are
generated by the intelligent tiering algorithm and the allocation compliance
algorithm, respectively. And both types of data movement will occur only during userdefined data movement windows.
Intelligent tiering algorithm-related data movements are requested and executed by
the Symmetrix microcode. These data movements will be governed by the workload
on each extent group but will only be executed within the constraints of the
associated FAST policy. That is, a performance movement will not cause a storage
group to become non-compliant with its FAST policy.
Allocation compliance-related data movements are generated by the FAST controller,
and executed by the microcode. These movements bring the capacity of the storage
group back within the boundaries specified by the associated policy. Performance
information from the intelligent tiering algorithm is used to determine more
appropriate sub-extents to move when restoring compliance.
When moving a thin device extent group from one pool to another only the allocated
extents are moved – unallocated extents are not moved. This means that the smallest
amount of data that can be moved by FAST VP is 768 KB – representing a single
allocated thin device extent. However, data movements will more typically be 7,680
KB in size.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
19
During the data movement only the location of the extent group changes. The binding
information for the thin device remains the same.
Limitations and restrictions
The following limitations and restrictions apply to FAST VP:
Only host-facing Virtual Provisioning devices, TDEVs, can be managed by FAST VP.
Data devices cannot be managed.
FAST VP management of EMC TimeFinder/Snap devices (that is, VDEV and SAVE
devices) is not supported.
FAST VP management of CKD, or IBM iSeries (AS400), devices is not supported.
DB2 9.7 for Linux, UNIX, and Windows
DB2 version 9.7 for Linux, UNIX, and Windows (LUW) and DB2 pureScale (which
technically, is version 9.8), are the latest releases of IBM’s open-systems hybrid
database management system. As with previous versions, DB2 9.7 runs on a wide
variety of platforms (AIX, HP-UX, Linux, Solaris, Windows, i5/OS, and z/OS), and
several editions are available — each of which has been designed to meet a specific
business need. (DB2 pureScale only runs on AIX and Linux.) These editions, along
with an extensive suite of add-on products that provide additional storage capability
and advanced connectivity, are collectively known as the DB2 Family.
Servers, instances, and databases
DB2 LUW sees the world as a hierarchy of objects. Workstations (or servers) on which
DB2 has been installed occupy the highest level of this hierarchy. During the
installation process, program files for a background process known as the DB2
Database Manager are physically copied to a specific location on the server and an
instance of the DB2 Database Manager is created. (The default instance for a
particular system is defined by the DB2INSTANCE environment variable and this is the
instance used for most operations.)
Instances occupy the second level in the hierarchy and are responsible for managing
system resources and databases that fall under their control. Although only one
instance is created initially, several instances can exist. Each instance behaves like a
separate installation of DB2, even though all instances within a system share the
same DB2 Database Manager program files (unless each instance is running a
different version of DB2). And although multiple instances share the same binary
code, each runs independently of the others and has its own environment, which can
be modified by altering the contents of its associated configuration file.
Every instance controls access to one or more databases; databases make up the
third level in the hierarchy and are responsible for managing the storage,
modification, and retrieval of data. Like instances, databases work independently of
one another. Each database has its own environment (also controlled by a set of
configuration parameters), as well as its own set of grantable authorities and
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
20
privileges to govern how users interact with the data and database objects it controls.
From a user’s perspective, a database is a collection of tables (preferably related in
some way) that are used to store data. However, from a database administrator’s
viewpoint, a DB2 9.7 database is much more; a database is an entity that is
comprised of many physical and logical components. Some of these components
help determine how data is organized, while others determine how and where data is
physically stored. Figure 4 shows the hierarchical relationship between systems,
instances, and databases.
Figure 4. Hierarchical relationship between DB2 systems, instances, and databases
Objects that make up a DB2 database environment
DB2 9.7 uses both logical and physical storage models that are comprised of several
different, yet related, objects. Four types of objects exist. They are:
System objects consist of registry variables, instance configuration files, and
individual database configuration files. Registry variables are set at the system
level and can affect every instance that resides on a particular server. Instance
configuration files (also known as DB2 Database Manager configuration files) are
created and assigned to individual instances during the instance creation
process. Values in an instance’s configuration file control how resources are
allocated for that particular instance, and changes to them affect every database
that falls under that instance’s control. Similarly, database configuration files are
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
21
created and assigned to individual databases during the database creation
process. Values in a database’s configuration file control how resources are
allocated for that particular database and changes to them can impact
performance and control resource utilization.
Recovery objects consist of transaction log files and recovery history files. By
default, one recovery history file and three transaction log files are automatically
created when a database is created. Recovery log files are used, together with
database backup images and transaction log files, to coordinate database
recovery operations. The recovery history file contains information about every
backup operation executed, while transaction log files contain records of recent
database operations performed. In the event a database has to be recovered from
an application, user, or system error, events stored in the transaction log files can
be replayed to return the database to a consistent and stable state, or to return a
database to the state it was in up to the point in time that the error occurred –
provided roll-forward recovery is enabled. You cannot modify transaction log files
or recovery history files directly; however, you can control where transaction log
files are physically stored.
Storage objects control where data is physically stored and how data is moved
between storage and memory during normal operation. Three types of storage
objects are used. They are:

Buffer pools are a section of memory that has been reserved for the sole
purpose of caching data pages as they are read from physical storage.
Whenever data is needed to resolve a query, the page the data is stored on is
located in physical storage and transferred to a buffer pool, where it is then
read and/or modified. If the page is modified, eventually it is copied back to
physical storage; however, all pages read stay in memory until the space they
occupy is needed or until all connections to the database are terminated.
Furthermore, whenever a page of data is retrieved, the DB2 Database Manager
uses a set of heuristic algorithms to try to determine which pages will be
needed next and those pages are retrieved as well (this is referred to as
prefetching). Page retention and prefetching are done to improve overall
performance; data can be accessed much faster when it is stored in memory
than when it is stored on disk.

Containers are some form of physical storage that the DB2 Database Manager
has reserved access to. A container can be a directory that may or may not
already exist, a fixed-size, preallocated file that may or may not already exist,
or a physical (raw) device that is recognized by the operating system. (On
Linux and UNIX operating systems, a physical device can be any logical
volume that uses a character special interface; on Windows operating
systems, a physical device is any unformatted partition or any physical disk
drive.)

Table spaces are used to control where data is physically stored and to
provide a layer of indirection between database objects (such as tables,
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
22
indexes, and views) and one or more containers (that is, directories, files, or
raw devices) in which the object’s data actually resides. A single table space
can span many containers, but each container can only belong to one table
space.
Data (or database) objects are used to logically store and manipulate data, as well
as to control how all user data (and some system data) is organized. Data objects
include tables, indexes, views, aliases, schemas, triggers, user-defined data
types, user-defined functions, and sequences.
A closer look at table spaces
As mentioned earlier, table spaces are used to control where data is physically stored
and to provide a layer of indirection between database objects (such as tables,
indexes, and views) and one or more containers, such as directories, files, or raw
devices, in which the object’s data actually resides. While a table space is a logical
database entity, containers represent the physical storage associated with table
spaces. The container used is dependent on the type of table space being created,
and can be an operating system directory, an individual file, or a raw logical
volume/disk partition. When a table space is created it must have at least one
container associated with it. A single table space can span many containers, but each
container can belong to only one table space.
The basic unit of storage in a DB2 database is a page, and pages can be 4K
(kilobytes), 8K, 16K, or 32K in size. When pages are written to a container they are
grouped into contiguous ranges called extents; the extent size is specified during the
table space creation process and cannot be changed once the table space has been
constructed. When a table space spans multiple containers, data is written in a
round-robin fashion (one extent at a time) to each container assigned to that table
space. This helps balance data across all containers that belong to a given table
space. Figure 5 shows the relationship between pages, extents, and table space
containers.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
23
Figure 5. How data is written to table space containers
Two types of table spaces can exist: System Managed Space (SMS) table spaces and
Database Managed Space (DMS) table spaces. With SMS table spaces, only directory
containers can be used for storage, and the operating system’s file manager is
responsible for controlling how that space is used. If a directory specified as a storage
container does not exist, DB2 will create it; if it does exist, it must be empty – if it
contains any files or subdirectories DB2 will not be able to use it. The SMS storage
model consists of many files (each representing a table, index, or long data object)
that reside within the file system space — the user decides on the location of the
files, the DB2 Database Manager assigns the files their names, and the file system is
responsible for managing their growth. Since containers cannot be dynamically
added to an existing SMS table space, it is important to know the anticipated storage
space requirements before the table space is created.
With DMS table spaces, a storage container can be either a file, a raw device or raw
logical volume, or a disk partition and the DB2 Database Manager is responsible for
controlling how the space is used. If a file is specified as a DMS table space storage
container and the file does not exist, DB2 will create it and initialize it to the size
specified. If an existing file is specified, DB2 will check it to verify that it is not already
being used for some other purpose – if its contents can be overwritten, DB2 will
expand or shrink it to the size specified and initialize it for use. The file size can be
specified in number of pages, KB, MB, or GB.
In Linux and UNIX environments, raw device containers are mapped to underlying
logical volumes. In Windows, a raw device container is mapped to an unformatted
disk partition. If a raw device is specified as a DMS table space storage container, it
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
24
cannot be used for any other purpose – in fact, it cannot contain a file system and it
should not be formatted. When specifying the size of a device container, it is a good
idea to utilize all of the space available since any unused space will not be available
for other applications. (Unused space can be used at a later date if the table space
container is extended or resized.) Like file sizes, device sizes can be specified in
number of pages, KB, MB, or GB.
Raw devices versus files
Within the database community there has been a long-running debate surrounding
the use of raw devices versus files for data storage. Advocates of raw devices stress
the performance gains that can be realized through their use, while file supporters
emphasize the ease of use and manageability features of file systems. As with other
aspects of database system design, a decision must be made as to which is more
important: performance or manageability.
In order to better understand the performance advantages associated with raw
devices, it helps to understand the impact of the file system cache. Most Linux and
UNIX file systems set aside an area of memory to hold recently accessed files, which
can subsequently allow physical I/O requests to be satisfied from memory instead of
from disk. If DB2 requests data that is not already in the cache, the operating system
will read the data from disk into the cache and then copy the data to a buffer pool so
that it can be used. Therefore, each read request translates into a disk read followed
by a copy of the data from the cache to the database buffer pool.
When data is read from the cache, I/O requests can be satisfied in nanoseconds
instead of the milliseconds that would be required in order to retrieve the data from
disk. In addition, most Linux and UNIX file systems employ the use of a sequential
read-ahead mechanism to prefetch data into the cache when it detects that a file is
being accessed sequentially.
In non-database environments, the file system cache can significantly reduce I/O wait
time for heavily accessed files. However, the performance benefits of file system
caching in database environments are not so clear. This is due to the fact that most
relational database management systems, including DB2, also allocate a region of
memory for caching frequently accessed data (that is, the database buffer pools).
This results in double buffering of data in the file system cache and in a DB2 buffer
pool.
In 64-bit systems, the memory used by the file system cache could be better utilized
by the database buffer pools. In 32-bit systems, with their associated shared memory
limits, the file system cache can provide benefit for some workloads.
The primary benefit of raw devices is that they bypass the file system cache by
directly accessing the underlying logical device. The extra memory saved by
eliminating the file system cache can then be allocated to the database buffer pools.
In addition, overall CPU utilization is decreased due to the fact that the system no
longer has to copy the data from the file system cache to the database buffer pools.
Another benefit of raw logical volumes in AIX is that there is no inode management
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
25
overhead, as opposed to file systems where the inode is locked when the file is
accessed.
With DB2 9.7, it is possible have the best of both worlds (performance and
manageability) by using the NO FILE SYSTEM CACHING option when creating
DMS table spaces. This option provides a way to bypass the file system cache when
using file containers for storage.
Table space types
Both SMS and DMS table spaces are classified according to the type of data they are
intended to store; three classifications exist:
Regular table spaces store both table data and index data. The maximum size of a
regular table space depends on the page size used for the table space. For a table
space with 4K pages, the maximum size is 64 GB. For a table space with 32K
pages, the maximum size is 512 GB. This is the only table space type allowed for
SMS table spaces, and it is also the default type for SMS table spaces when no
type is specified.
Large table spaces are used to store regular and index data as well as long and
large object (LOB) data. (The use of large table spaces is optional given that large
data can reside in regular table spaces as well.) The maximum size of a large table
space is 16 TB. If a table contains long varying-length character strings, long
varying-length double-byte character strings, or large object columns, the table’s
data may be stored such that regular data resides in a regular table space and
long/large object data resides in a large table space. However, this method of
storage must be specified at the time the table is created and once the table is
created, it cannot be changed. Beginning with DB2 version 9.1, when DMS table
spaces are created, they are large table spaces by default. (Prior to this release,
regular table spaces were created by default.) In this release, the record identifier
(RID) length has been increased so large table spaces allow more data pages per
table object and more records per page. By default, every DB2 database has at
least one regular table space named USERSPACE1. This table space is a normally
created as a DMS table space but can be created as a SMS table space if so
desired. (The USERSPACE1 table space can also be dropped once another regular
table space has been created.)
Temporary table spaces, as the name implies, are used to store temporary data.
The maximum size of a temporary table space is 2 TB. Temporary table spaces are
further classified as being either system temporary or user temporary.

System temporary table spaces are used by DB2 to hold transient data (such
as intermediate tables) during sort operations and table reorganization
operations, and to aid in SQL statement processing when creating indexes and
joining tables. A database must have at least one system temporary table
space – by default, a system temporary table space named TEMPSPACE1 is
created when a database is created. However, this table space can be dropped
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
26
once another system temporary table space with the same page size has been
created.

User temporary table spaces store declared global temporary tables, which in
turn are used to store application-specific data for a brief period of time. A
database is not required to have a user temporary table space so one is not
automatically created as part of the database creation process. However,
before a declared global temporary table can be created, a user temporary
table space must exist in the database.
If a database is enabled for automatic storage, one other type of table space—an
automatic storage table space—can exist. Automatic storage table spaces use space
in the storage paths that have been defined for the database, and grow automatically
as the table space begins to fill up. Although at first glance, automatic storage table
spaces appear to be a third type of table space, they are really just an extension of
SMS and DMS table spaces: Regular and large table spaces are created as DMS table
spaces with one or more file containers; system and user temporary table spaces are
created as SMS table spaces with one or more directory containers.
Unlike when SMS and DMS table spaces are defined, no container definitions are
needed for automatic storage table spaces; DB2 assigns containers to automatic
storage table spaces automatically. However, an initial size can be specified as part
of the table space creation process. (If an initial size is not specified, DB2 will use a
default value of 32 megabytes.)
The system catalog table space
As part of the database creation process, a table space named SYSCATSPACE is
created and used to hold a special set of tables known as the system catalog tables.
(The system catalog tables are used to store metadata about objects that have been
created in the database.) The SYSCATSPACE table space is a regular table space, but
is only used to store the database catalog tables and once created, it cannot be
dropped. By default, the SYSCATSPACE table space is created as an automatic
storage DMS table space, but it can be created as an SMS table space if so desired.
Creating additional table spaces
When a DB2 database is created, one buffer pool named IBMDEFAULTBP is created,
and three table spaces are created and associated with this buffer pool as part of the
database initialization process. Additional table spaces can be created by executing
the CREATE TABLESPACE SQL statement or by using the Create Table Space
Wizard, which can be activated by selecting the appropriate action from the Table
Spaces menu found in the Control Center.
Modifying existing table spaces
Because SMS table spaces rely on the operating system for physical storage space
management, they rarely need to be modified after they have been successfully
created. DMS table spaces, on the other hand, have to be monitored closely to ensure
that the fixed-size preallocated file(s) or physical raw device(s) that they use for
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
27
storage always have enough free space available to meet the database’s needs.
When the amount of free storage space available to a DMS table space becomes
dangerously low (typically less than 10 percent), you can add more free space either
by increasing the size of one or more of its containers or by adding one or more new
containers to it. Existing table space containers can be resized, new containers can
be made available to an existing table space, and an existing table space’s properties
can be changed by executing the ALTER TABLESPACE SQL statement. Table spaces
can also be altered using the Alter Table Space dialog box, which can be activated by
selecting the appropriate action from the Table Spaces menu found in the Control
Center.
Automatic storage databases
Unless otherwise specified, all DB2 9.7 databases are created with automatic storage
enabled. Automatic storage is intended to make storage management easier –
instead of being managed at the table space level using explicit container definitions,
storage is managed at the database level by the DB2 Database Manager. When you
create an automatic storage database, you specify the storage paths where the DB2
Database Manager is to place your data. The DB2 Database Manager is then
responsible for managing the container and space allocation for table spaces as they
are created and populated. (The Database Manager creates and extends containers
as needed up to the limits imposed by the storage paths associated with the
database.)
In most cases, the same storage paths must be used by every database partition in a
multi-partition database, and the paths used must exist before a partitioned
database can be created. The one exception to this rule is where database partition
expressions are used in the storage path definitions provided. (The argument “ $N”
([blank]$N) is used to indicate a database partition expression.) Using database
partition expressions allows the database partition number to be reflected in the
storage path such that the resulting path name is different on each partition.
Beginning with DB2 9.7, you can modify an existing database — even one that was
not created with automatic storage — to take advantage of automatic storage by
executing the ALTER DATABASE SQL statement with the ADD STORAGE ON clause
specified. This has the effect of both adding a new storage path to the database, as
well as causing all new table spaces that are added to the database to be automatic
storage table spaces unless you specify otherwise. The ALTER DATABASE SQL
statement can also be used to add new storage paths to the collection of paths that
are used by a database once the database has been created/converted.
Using the snapshot monitor to identify “hot” logical volumes
Database monitoring is a vital activity that, when performed on a regular basis,
provides continuous feedback on the health of a database system. And because
database monitoring is such an integral part of database administration, DB2 comes
equipped with a built-in monitoring utility known as the Database System Monitor.
Although the name “Database System Monitor” suggests that only one monitoring
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
28
tool is available, in reality the Database System Monitor is composed of two distinct
tools – a snapshot monitor and one or more event monitors – that can be used to
capture and return system monitor information. The snapshot monitor allows you to
capture a picture of the state of a database (along with all database activity) at a
specific point in time whereas event monitors capture and log data as specific events
occur.
Along with system utilities like iostat and filemon, DB2’s snapshot monitor can
be used to identify “hot” table spaces that are good candidates to move to EFDs. For
example, a DB2 table space snapshot provides the following information:
Table space name
Table space page size
Number of pages used
Buffer pool data, index, and XDA physical reads (XDAs are data pages for XML
storage objects)
Buffer pool read/write time
To identify which table space containers are “hot,” examine the following properties:
Access density (which is a function of the number of physical I/Os relative to the
number of used pages in the table space)
Access latency (which is a measure of latency for those physical I/Os)
Table space relative weight (which is calculated to help prioritize between
different table spaces to place on EFD)
Sequential ratio of accesses (which is a ratio of sequential to random access)
Using this information, create a ranking to determine which table spaces are better
candidates to place on EFD storage and which table spaces are suitable for SATA. In
order to rank the table spaces in a database, the following calculations should be
performed:
1. Total Physical I/Os = (Buffer pool data physical reads + Buffer pool index physical
reads + Buffer pool xda physical reads + Buffer pool temporary data physical
reads) + (Direct reads * 512 ) / table space page size
2. Page Velocity = Total physical I/Os / Snapshot interval in seconds
3. Access Time = Total buffer pool read time + Direct reads elapsed time
4. Access Density = Page velocity / Number of used pages in the table space
5. Access Latency = Access time / Total physical I/Os
6. Weighting Factor = Access density * Access latency
7. Sequentiality Ratio = (Asynchronous pool data page reads + Asynchronous pool
index page reads + Asynchronous pool xda page reads) / (Buffer pool data
physical reads + Buffer pool index physical reads + Bufferpool xda physical reads)
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
29
When these calculations are performed for all table spaces in a database and the
table spaces are then listed in descending order, based on their Weighting Factor,
those table spaces that have the highest Weighting Factor are candidates for EFDs.
Likewise, when the table spaces are listed in descending order, based on their
Sequentiality Ratio, those table spaces that have the lowest Sequentiality Ratio are
good candidates for SATA drives.
The information needed to perform these calculations can be obtained by executing
the GET SNAPSHOT FOR TABLESPACES command with the BUFFERPOOL monitor
switch set to ON. With DB2 9.7, it is also possible to obtain this information by
constructing a query that invokes the MON_GET_BUFFERPOOL() monitoring
function.
Working with Enhanced Virtual LUN Technology and DB2 LUW
databases
The goal of an effective storage tiering approach in a multi-typed storage
configuration is to place the right data on the right storage type (disks and RAID
protection scheme) at the right time. A given DB2 database storage device may be
highly active and highly accessed when data is created on it in the first instance. But
over time, its usage may drop to a level where it could be deployed on a storage type
that has lower-cost and lower-performance characteristics.
Manual storage tiering mechanics
A typical manual storage tiering approach consists of the following steps:
1. Monitor database and storage performance
2. Identify and classify hot and cold database objects that are candidates for cost
reduction (down-tiering) or performance improvement (up-tiering)
3. Identify space to be used as targets for tiering operations
4. Use database, host, or storage utilities to move candidates to the right storage
type
5. Validate that the tiering activities performed had the desired effects
6. Repeat the process at a later point in time
Manual storage tiering examples
The following examples illustrate manual storage tiering using Symmetrix Enhanced
Virtual LUN (VLUN) Technology to perform DB2 LUW database migrations seamlessly
inside the storage array. The examples presented in this white paper illustrate a
general OLTP workload with characteristics identical to those seen with DB2 LUW
systems running on an environment like the one shown in Table 1.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
30
Table 1. Examples environment
Configuration Aspect
Description
Servers
2 x Dell R900 servers
Storage array
Symmetrix VMAX (2 VMAX Engines)
Enginuity
5874 service release
EFD
8 x 400 GB Enterprise Flash Drives
HDD
120 x FC 15k rpm 300 GB drives
SATA
32 x SATA 7,200 rpm 1 TB drives
Multipathing
EMC PowerPath® 5.3 SP1
Scenario and results
For this white paper, a scenario was used in which three separate databases were
deployed on a Symmetrix VMAX to simulate three separate I/O profiles. All three
databases were the same size (roughly 1 TB) and each was designed to
accommodate an online-transaction processing (OLTP) workload. RAID groups were
deployed such that physical drives were not shared between the databases. This
prevented I/O activity for one database from influencing the performance of the other
databases and made it simpler to identify which LUNs were the best candidates to
move to different storage types. The goal was to manage the storage types between
databases (that is, placing each database in the type that best matches its business
and performance needs).
The first database, DB-1, stored on FC (15k rpm) drives, was designed to simulate a
low I/O activity database that has very few users and is of low importance to the
business. Such a database is an ideal candidate to be moved from a higher storage
type to a lower storage type (“down-tier”). (Database DB-1 represented a database
that was once active but is now being replaced.) The second database, DB-2, was
designed to simulate an active database that was initially deployed on SATA disks
whose activity level and importance to the business are increasing. Such a database
is an ideal candidate to be moved from a lower storage type to a higher storage type
(“up-tier”). The last database, DB-3, stored on FC (15k rpm) drives, was designed to
simulate an active, high I/O, mission-critical database that supported many users.
This type of database is a good candidate to up-tier to EFD.
The initial configuration had database DB-2 placed on 10 LUNs that spanned 32
physical SATA disk drives while databases DB-1 and DB-3 were each placed on 40 FC
(15k rpm) drives. Table 2 shows the drive configuration used and the initial
performance measurements observed when an OLTP benchmark was run on each
database.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
31
Table 2. Initial performance analysis results
Initial Performance - Manual Storage Tiering
Database
# Physical Drives
Drive Type
Avg. TPM
% Change
DB-1
40
FC (15k rpm)
349.20
0.00%
DB-2
32
SATA
890.53
0.00%
DB-3
40
FC (15k rpm)
11736.03
0.00%
Based on these results we can see that database DB-1 has the lowest average
transactions per minute (TPM) – around 350 TPM – and has no business justification
to be on FC (15k rpm) drives. As a result, the decision is made to down-tier it to SATA
drives.
Database DB-2 has a medium TPM rate – around 890 TPM – and its transaction rate
can surely be improved by moving it from SATA drives to a better fit storage type. In
this case the business goal is to address database DB-2’s increasing importance and
activity and to do that, we’ll move it to FC (15k rpm) drives where the I/O response
time and transaction rate can be improved.
Database DB-3 is already on FC (15k rpm) drives, but based on its high I/O activity it
can benefit from up-tiering to EFD. This is a very visible and critical database to the
business and so it was decided to up-tier its data to EFD.
Figure 6 shows a utilization map of the physical drives that were used to store the
databases. (This map was generated using an EMC internal performance analyzing
tool that shows a “heat map” of the drive utilization at the Symmetrix back end.) Each
physical drive in the array is represented by a single rectangle and that rectangle
corresponds with the physical location of the drive in the array. The rectangle is colorfilled to represent the utilization of the physical drive as shown in the color legend on
the left side of the figure. Drives that are unused, or used very little, will be shown as
shades of blue; drives that are utilized in the 40-60 percent range will be presented
as shades of green; and highly utilized drives will be shown in shades of yellow,
orange, and red.
DB-1 on FC
DB-3 on FC
Figure 6. Initial drive utilization map
DB-2 on SATA
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
32
Database DB-1 was deployed on the first 40 physical drives in the array and these
drives are represented by the top two rows of rectangles shown in Figure 6. Since
database DB-1 has the lowest I/O profile, all 40 drives are depicted in shades of blue,
indicating low drive utilization. The second database, DB-2, was deployed on the last
32 physical drives in the Symmetrix VMAX, which are SATA disks. These drives are
represented by the last three rows of rectangles in Figure 6. Because database DB-2
has a higher I/O profile, these drives are shown in light-green to yellow, indicating a
medium-high level of utilization. If we want to increase the load on this database and
improve transaction throughput, we will need to up-tier these drives. The third
database, DB-3, represents a mission-critical database and the physical drives
associated with this database are easy to see (in the center of the figure) because
they are shown in bright red, meaning that they are nearly 100 percent utilized.
Because of the importance of this database and the high utilization rate shown, this
database is a strong candidate to up-tier to EFD.
Database DB-2 appeared to be a good candidate to up-tier, therefore the decision
was made to up-tier (migrate) that database from SATA to FC (15k rpm) drives first.
Data can be migrated from one set of drives to another by executing the SYMAPI
symmigrate command or by using the LUN Migration Wizard, which can be
activated by selecting the appropriate links in SMC. Figure 7 shows the steps that are
needed to activate the LUN Migration Wizard from SMC; Figure 8 shows how the LUN
Migration Wizard looks when it is first activated.
Figure 7. Steps needed to activate the LUN Migration Wizard from SMC
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
33
Figure 8. LUN Migration Wizard
A description of how the symmigrate command and the LUN Migration Wizard are
used is beyond the scope of this paper. For more information on how these tools are
used to migrate data from one storage type to another, refer to the Technical Note
Best Practices for Nondisruptive Tiering via EMC Symmetrix Virtual LUN (Part Number
300-009-147).
Once the migration of database DB-2 from SATA to FC was complete, the OLTP
benchmark was rerun; Table 3 shows the new drive configuration and the
performance measurements observed when the OLTP benchmark was run again on
each database.
Table 3. Results after the migration of database DB-2 from SATA to FC
Move database DB-2 from SATA to FC (15k rpm)
Database
# Physical Drives
Drive Type
Avg. TPM
% Change
DB-1
40
FC (15k rpm)
343.03
-1.77%
DB-2
40
FC (15k rpm)
2816.43
216.26%
DB-3
40
FC (15k rpm)
11181.37
-4.73%
After the migration, the TPM rate for database DB-2 more than doubled. However, the
resulting load increase on the system caused the performance of the other two
databases to degrade slightly.
Figure 9 shows the utilization map of the Symmetrix VMAX system after database DB2 was migrated from SATA to FC (15k rpm) drives. Disk utilization by database DB-1
did not change substantially, therefore its drives are still shown in dark blue. As
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
34
expected, the location of the drives used by database DB-2 has changed from the
SATA drives shown at the bottom of the map to the FC (15k rpm) drives shown just
above the physical drives being used by database DB-3. The physical drives
associated with database DB-2 are now shown in light yellow, indicating moderate
utilization. The drives associated with database DB-3 are still bright red, indicating
that this database is still a strong candidate to up-tier to EFD.
DB-1 on FC
DB-2 on FC
DB-3 on FC
Figure 9. Drive utilization map after the database DB-2 up-tier from SATA to FC
Next, the decision was made to up-tier database DB-3 to eight Enterprise Flash
Drives. Once the migration of database DB-3 was complete, the OLTP benchmark was
run again; Table 4 shows the new drive configuration and the performance
measurements observed when the OLTP benchmark was run on each database.
Table 4. Results after the migration of database DB-3 from FC to EFD
Move database DB-3 from FC (15k rpm) to EFD
Database
# Physical Drives
Drive Type
Avg. TPM
% Change
DB-1
40
FC (15k rpm)
321.90
-6.16%
DB-2
40
FC (15k rpm)
2609.03
-7.36%
DB-3
8
11408.50
2.03%
EFD
Migrating database DB-3 from 40 physical FC drives (15k rpm) to eight EFDs yielded
the same overall TPM rate while at the same time reduced the number of drives
required. Figure 10 shows the utilization map of the Symmetrix VMAX system after
database DB-3 was migrated from FC (15k rpm) drives to EFD. The EFDs associated
with database DB-3 are shown in green and yellow, indicating 40-60 percent drive
utilization.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
35
DB-1 on FC
DB-2 on FC
DB-3 on EFD
Figure 10. Drive utilization map after the database DB-3 up-tier from FC to EFD
Finally, the decision was made to down-tier database DB-1 to SATA. This decision was
made, regardless of any impact it might have on performance, because it was
deemed that this database was no longer important to the business, and therefore,
did not justify the storage type it was stored on. Once the migration of database DB-1
was complete, the OLTP benchmark was run again. Table 5 shows the new drive
configuration and the performance measurements observed when the OLTP
benchmark was run on each database.
Table 5. Results after migration of database DB-1 from FC to SATA
Move database DB-1 from FC (15k rpm) to SATA
Database
# Physical Drives
Drive Type
DB-1
32
SATA
DB-2
40
FC (15k rpm)
DB-3
8
EFD
Avg. TPM
% Change
168.43
-47.68%
2629.87
0.80%
11450.17
0.37%
As expected, the performance of database DB-1 was degraded because the database
was moved from 40 FC (15k rpm) drives to 32 SATA drives, which are slower. In fact,
performance was decreased by approximately 50 percent. However, by moving
database DB-1 to SATA drives, we were able to make 40 FC (15k rpm) drives available
for use by other databases/applications. The performance of the other two databases
was not affected by this migration.
Figure 11 shows the utilization map of the Symmetrix VMAX system after database
DB-1 was migrated from FC to SATA drives. The SATA drives associated with database
DB-1 are shown in light blue and green, indicating drive utilization of 30 to 50
percent.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
36
DB-2 on FC
DB-1 on SATA
DB-3 on EFD
Figure 11. Drive utilization map after the database DB1-3 down-tier from FC to SATA
Summary
To summarize the results of the migrations, the overall performance of database
DB-1, which was deemed obsolete, was degraded as expected but we were able to
migrate the data without having to take the database offline. Up-tiering database
DB-2 from SATA to FC (15k rpm) drives more than doubled the performance of the
database, and because this database was up-tiered to FC, there are now 40 physical
drives over which we can distribute this database’s load as transaction volume
increases. And finally, database DB-3 was successfully moved from FC (15k rpm)
drives to EFD and while the overall performance did not increase dramatically, we
were able to free up an additional 40 physical FC drives for other uses.
It is important to note that in a real test environment, a TimeFinder copy of the
database LUNs could be taken at the time of the initial creation of the databases and
then be used to restore the database between each test to ensure that the initial
states of the databases are in the same at the beginning of every migration operation.
The scripts running the workload for all three databases would not need any
modification despite the fact that none of the LUNs are in the same location at the
end of the migration that they were in at the beginning. This is a key feature of
Symmetrix LUN migration – all Symmetrix internal device relationships are
maintained at all times during migrations, and therefore no scripts or database
changes are necessary.
Working with FAST and DB2 LUW databases
Earlier, we saw that FAST proactively monitors workloads at the Symmetrix device
(LUN) level in order to identify “busy” devices that would benefit from being moved to
higher-performing drives such as EFD. FAST will also identify less “busy” devices that
could be relocated to higher-capacity, more cost-effective storage such as SATA
drives without altering performance. Time windows can be defined to specify when
FAST should collect performance statistics (upon which the analysis to determine the
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
37
appropriate storage type for a device is based), and when FAST should perform the
configuration changes necessary to move devices between storage types. Movement
is based on user-defined storage types and FAST policies.
FAST considerations for DB2 LUW databases using automatic storage
By default, all DB2 9.7 databases are created with automatic storage enabled. With
automatic storage, one or more storage containers (paths) are specified when a
database is created and each table space that is defined for the database will
automatically stripe its data across all of the containers used. (New table spaces can
be created without having to explicitly specify container definitions.) Thus, storage is
managed at the database level, not at the individual table space level using explicit
container definitions. For a DB2 LUW database using automatic storage, the goal of
an ILM strategy might be to move or swap an entire disk group, rather than individual
LUNs, from one storage type to another. Implementing such a strategy in a FAST
environment can be done by identifying and using appropriate storage groups,
storage types, and FAST policies.
FAST storage tiering mechanics
A typical FAST storage tiering approach consists of the following steps:
1. Monitor database and storage performance
2. Decide on an appropriate logical FAST profile to use
3. Create the FAST storage types, storage groups, and FAST policies needed for the
FAST profile
4. Validate that the automated tiering activities performed by FAST had the desired
effects
FAST storage tiering examples
The following examples illustrate automated storage tiering using FAST to perform
DB2 LUW database migrations seamlessly inside the storage array. As before, the
examples presented in this white paper illustrate a general OLTP workload with
characteristics identical to those seen with DB2 LUW systems running on an
environment like the one shown in Table 1 on page 31.
Scenario and results
Once again, a scenario was used in which three separate databases were deployed
on a Symmetrix VMAX to simulate three separate I/O profiles. All three databases
were the same size (roughly 1 TB) and each was designed to accommodate an OLTP
workload. RAID groups were deployed such that physical drives were not shared
between the databases.
The first database, DB-1, stored on FC (15k rpm) drives, was designed to simulate a
low I/O activity database that has very few users and is of low importance to the
business. The second database, DB-2, was designed to simulate an active database
that was initially deployed on SATA disks whose activity level and importance to the
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
38
business is increasing. The last database, DB-3, stored on FC (15k rpm) drives, was
designed to simulate an active, high I/O, mission-critical database that supported
many users.
As before, the initial configuration had database DB-2 placed on 10 LUNs that
spanned 32 physical SATA disk drives while databases DB-1 and DB-3 were each
placed on 40 FC (15k rpm) drives. Table 6 shows the drive configuration used and the
initial performance measurements observed when an OLTP benchmark was run on
each database.
Table 6. Initial performance analysis results
Initial Performance - FAST
Database
# Physical Drives
Drive Type
Avg. TPM
% Change
DB-1
40
FC (15k rpm)
349.20
0.00%
DB-2
32
SATA
890.53
0.00%
DB-3
40
FC (15k rpm)
11736.03
0.00%
Figure 12 shows a utilization map of the physical drives that were used to store all
three databases.
DB-1 on FC
DB-3 on FC
DB-2 on SATA
Figure 12. Initial drive utilization map
Once again, database DB-1 was deployed on the first 40 physical drives in the array
and these drives are represented by the top two rows of rectangles. Since this
database has the lowest I/O profile, all 40 drives are depicted in shades of blue,
indicating low drive utilization. The second database, DB-2, was deployed on the last
32 physical drives in the Symmetrix VMAX, which are SATA disks. These drives are
represented by the last three rows of rectangles in Figure 12. Because database DB-2
has a higher I/O profile, these drives are shown in yellow and red, indicating a high
level of utilization. The third database, DB-3, resides on the physical drives shown in
the center of Figure 12 and these drives are easy to see because they are depicted in
bright red, meaning that they are nearly 100 percent utilized.
After evaluating the drive utilization map, the decision was made to create a logical
FAST profile for database DB-3 that looks like the one shown in Figure 13.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
39
Figure 13. Logical FAST profile desired for database DB-3
While there are three storage types available (EFD, FC, and SATA) in the Symmetrix
VMAX used, the decision was made to never allow database DB-3 to reside on SATA
disks. Therefore, a SATA storage type was not included in the FAST profile. (Including
the SATA storage type and setting the allowable percentage to 0 percent has the
same effect as not including the SATA storage type at all.)
The management and operation of FAST can be conducted by executing the SYMAPI
symfast command or by using the FAST Configuration Wizard, which can be
activated by selecting the appropriate links in SMC. The FAST Configuration Wizard
makes creating FAST storage types, storage groups, and FAST policies simpler by
providing the user with an easy-to-understand point-and-click interface. Figure 14
shows the steps that are needed to activate the FAST Configuration Wizard from SMC;
Figure 15 shows how the FAST Configuration Wizard looks when it is first activated.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
40
Figure 14. Steps needed to activate the FAST Configuration Wizard from SMC
Figure 15. FAST Configuration Wizard
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
41
A description of how the symfast command and the FAST Configuration Wizard are
used is beyond the scope of this paper. The screen captures that follow show the
FAST settings that were used to monitor and manage the high-performance, missioncritical I/O profile of database DB-3. However, before using the symfast command or
the FAST Configuration Wizard, it is recommended that you create the storage groups
that FAST will operate on. Storage groups in Symmetrix VMAX are used for both Autoprovisioning Groups to simplify device masking operations, as well as to group
devices for FAST control. While Symmetrix devices can be in multiple storage groups,
no two storage groups under FAST control can contain the same devices.
FAST setup for database DB-3 management
The first step in developing a FAST profile for database DB-3 involved creating a
storage type (tier) for the physical drives that contained the database files. This
storage type described the 40 physical drives that contained the DB-3 database,
which resided in Symmetrix Disk Group 25.The results of creating this storage type
can be seen in Figure 16.
Figure 16. DB-3 storage type properties
Once a storage type for the DB-3 database was defined, the next step was to create a
storage type (tier) for the Enterprise Flash Drives. This was done by adding Symmetrix
Disk Group 10 to the EFD tier, which in this case was defined to be a RAID 5 (7+1) tier.
The results of creating this storage type can be seen in Figure 17.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
42
Figure 17. EFD storage type properties
Once the EFD storage type was defined, the next step was to create the appropriate
storage groups. Figure 18 shows the properties of the storage group that was created
for the devices containing the DB-3 database.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
43
Figure 18. Storage group properties
Note that in Figure 18, the properties box for the storage group that was created for
the DB-3 database (named “DB3_SG”) has three tabs: General, Devices, and FAST
Compliance. The Devices tab shows the 10 Symmetrix devices that belong to the disk
group that contains the DB-3 database and comprise the DB-3 storage group. The
FAST Compliance tab shows the tiers of storage this storage group may reside in. In
this example, we have defined the FC tier as the place where the database’s drives
are now and the EFD tier as a place where FAST may choose to move this disk group.
Because there is no option for a SATA tier in the DB3_SG storage group, FAST is
prohibited from ever recommending a down-tier of database DB-3 to SATA.
The final step of the process was to associate the storage group DB3_SG with the
FAST storage types (tiers) and define a policy to manage FAST behavior. The results of
creating the FAST policy that would be used to manage FAST behavior can be seen in
Figure 19.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
44
Figure 19. DB-3 FAST policy
For this scenario, we had one storage group (DB3_SG), two storage types (tiers) (EFD
and FC), and two FAST policies. The first FAST policy allowed for up to 100 percent of
the storage group to reside on EFD devices. The second policy allowed for 100
percent of database DB-3 to reside on FC devices. By allowing up to 100 percent of
the DB3_SG storage group to reside on EFD, it was expected that if FAST was going to
move any DB-3 LUN to EFD, it would move every DB-3 LUN since they all have the
same I/O profile and there was ample capacity available on EFD to accommodate the
entire DB-3 database.
After making some final adjustments to start FAST and collect statistics, the OLTP
benchmark was run and after an hour of collecting data, FAST proposed a Move/Swap
plan. In this plan, FAST proposed that all LUNs in the DB-3 database disk group be
moved from FC to EFD in a single move operation, which is exactly what was
expected. This plan was approved and FAST executed it; once the move plan was
executed, the OLTP benchmark was run again against all three databases. Table 7
shows the new drive configuration and the performance measurements observed
when the OLTP benchmark was run on each database.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
45
Table 7. Results after FAST migration of database DB-3 from FC to EFD
FAST migration of database DB-3 from FC (15k rpm) to EFD
Database
# Physical Drives
Drive Type
Avg. TPM
% Change
DB-1
40
FC (15k rpm)
358.12
2.55%
DB-2
32
SATA
897.27
0.76%
DB-3
8
13334.98
13.62%
EFD
Migrating database DB-3 from 40 FC drives (15k rpm) to eight EFDs yielded roughly a
13 percent in TPM performance. There was no degradation in performance of the
other two databases. Figure 20 shows the utilization map of the Symmetrix VMAX
system after database DB-3 was moved by FAST from FC to EFD. The EFDs associated
with database DB-3 are shown in green and yellow, indicating 40-60 percent drive
utilization.
DB-1 on FC
DB-2 on SATA
DB-3 on EFD
Figure 20. Utilization map after FAST migration of DB-3 to Flash
Summary
To summarize the results of the FAST migrations, database DB-3 was successfully
moved from FC to EFD and the overall performance increased by about 13 percent. In
addition, we were able to free up an additional 40 physical FC drives for other uses.
As expected, FAST could be counted on to automate the migration that was performed
manually earlier.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
46
Conclusion
In a multi-tiered DB2 LUW storage environment, moving highly accessed data from FC
drives to EFDs can maintain or improve performance while freeing up FC drives for
other uses. Likewise, moving data from SATA to FC drives can improve database
performance and allows for increased application activity, while moving lightly
accessed data from FC to SATA drives can drive down storage costs.
Enhanced VLUN migration technology introduced with Symmetrix VMAX provides
users with the ability to manually move Symmetrix logical devices between drive
types and RAID protection schemes. FAST and FAST VP automate the process of
identifying data volumes that would benefit from the relocation of their data across
different performance/capacity tiers within an array. FAST, also known as standard
FAST, operates on standard, non-thin, Symmetrix devices; with FAST, data
movements between tiers are performed at the full volume level. FAST VP, on the
other hand, operates on Virtual Provisioning thin devices. As a result, data
movements can be performed at the sub-LUN level, and a single thin device may have
extents allocated across multiple thin pools within the array.
With Enhanced VLUN migration technology, FAST, and FAST VP, data center
administrators are now able to dynamically manage data placement in a Symmetrix
array to maximize performance and minimize costs.
Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW)
with EMC Symmetrix VMAX and Enginuity 5875
47