storage tiering for db2 for linux, unix ... - dell emc korea · pdf filestorage tiering for...

White Paper

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 non-critical 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

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

2 Storage Tiering for DB2 for Linux, UNIX, and Windows (LUW) with EMC Symmetrix VMAX and Enginuity 5875

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


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


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


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.


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


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 OLTP-type 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


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 service-level 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%

40%

50%

15k rpm RAID 1

10k rpm RAID 5

7.2k rpm SATA RAID 6

Figure 1 provides a quick summary of the relationship between storage types, FAST policies, and storage groups.


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


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).


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 front-end 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.


Figure 3. The Symmetrix Management Console

Symmetrix Enterprise Flash Drives

With the introduction of Enterprise Flash Drives (EFDs), EMC has created a new ultra-performance 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.


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


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.


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 Auto-provisioning 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


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


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 cost-effective 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


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


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 user-defined 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.


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


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


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,


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.


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


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


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


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 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


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)


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.


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.


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 color-filled 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.

Figure 6. Initial drive utilization map DB-2 on SATA

DB-3 on FC

DB-1 on FC


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


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)


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 DB-2 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


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.

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


DB-1 40 FC (15k rpm) 321.90 -6.16%

DB-2 40 FC (15k rpm) 2609.03 -7.36%

DB-3 8 EFD 11408.50 2.03%

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.

DB-1 on FC

DB-2 on FC

DB-3 on FC


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


DB-1 32 SATA 168.43 -47.68%

DB-2 40 FC (15k rpm) 2629.87 0.80%

DB-3 8 EFD 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.

DB-2 on FC

DB-1 on FC

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

DB-3 on EFD

DB-2 on FC

DB-1 on SATA


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


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


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.

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.

DB-2 on SATA

DB-3 on FC

DB-1 on FC

DB-2 on SATA

DB-3 on FC

DB-1 on FC


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.


Figure 14. Steps needed to activate the FAST Configuration Wizard from SMC

Figure 15. FAST Configuration Wizard


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, mission-critical 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 Auto-provisioning 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.


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.


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.


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.


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


DB-1 40 FC (15k rpm) 358.12 2.55%

DB-2 32 SATA 897.27 0.76%

DB-3 8 EFD 13334.98 13.62%

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.

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.

DB-3 on EFD

DB-1 on FC

DB-2 on SATA


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 ... - dell emc korea · pdf filestorage tiering for...

Documents