Storage best practices for deploying IBM DB2 on HP

Integrity servers and HP EVA8400 storage

Technical white paper

Table of contents

Executive summary ....................................................................................................................... 2

Overview..................................................................................................................................... 2

Disk storage ................................................................................................................................. 3

Multipath storage devices .............................................................................................................. 4

DB2 log files ................................................................................................................................ 6

DB2 tablespaces........................................................................................................................... 7 System Managed Space (SMS) tablespace .................................................................................. 7 Database Managed Space (DMS) tablespace .............................................................................. 7

LVM layout .................................................................................................................................. 8

File system layout .......................................................................................................................... 9

DB2 registry variables ................................................................................................................... 9

Implementing a proof-of-concept ................................................................................................... 10

Summary ................................................................................................................................... 10

For more information ................................................................................................................... 11

2

Executive summary

This document provides suggestions and best practices for configuring disk storage for IBM DB2 database. The

document mainly focuses on HP 8400 Enterprise Virtual Arrays (EVAs) and an HP Integrity rx8640 server running

HP-UX 11i v3 operating system. The test configuration consists of three EVA8400 arrays and an HP Integrity rx8640

server in a DB2/SAP environment. Two EVAs are used for database tablespaces and one for database logs. The

recommendations focus on the following areas:

Physical disks and logical unit numbers (LUNs)

Striping

Database logs and data

File system configuration

Registry variables and configuration parameters

Target audience: This document is intended for database and system administrators. Prior knowledge of DB2

database and HP-UX operating system is required.

This white paper describes testing performed in June 2011.

Overview

The following recommendations are provided from the tests performed in our lab environment running a DB2 SAP

environment. The environment was tested with IBM DB2 9.7 fix pack 2 and 3a on HP-UX DC-OE Sep 2010 Update 7

running on an HP Integrity rx8640 server. Figure 1 shows the hardware configuration of the test environment. On the

database system OnlineJFS (Journaled File System) was installed, which supports Concurrent I/O (CIO) capabilities.

Also LibcEnhancement library a set of APIs which are extension to libc was installed on the HP-UX system.

Two EVA8400 disk arrays with 192 146GB disks were used for database tablespaces and one EVA8400 disk array

with 112 146GB disks were used for database log files to eliminate I/O contention in the benchmark environment.

Generally it is recommended to have dedicated LUNs and file systems for database tablespaces and log files. While

running the tests two large tables were moved to different tablespaces to improve the I/O response time for those

tables. The tablespace creation statement is provided in the section describing the tablespaces. DB2 registry variable

db2set DB2_WORKLOAD=SAP was set for the instance profile.

3

Figure 1. DB2 database configuration

RunAttention

Fault

Remote

SP Present

Standby Power

Power

hp Integrity rx8640

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

ENTERESC

HP

StorageWorks

HSV450

UID

ENTERESC

HP

StorageWorks

HSV450

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HP

StorageWorks

HSV300

UID

HP

StorageWorks

HSV300

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

8765432187654321

UID21

G5

HPProLiantDL580

8765432187654321

UID21

G5

HPProLiantDL580

8765432187654321

UID21

G5

HPProLiantDL580

8765432187654321

UID21

G5

HPProLiantDL580

UID

21

87654321

HPProLiant

DL785G5

UID

21

87654321

HPProLiant

DL785G5

UID

21

87654321

HPProLiant

DL785G5

UID

21

87654321

HPProLiant

DL785G5

HP Integrity rx8640 Server with 32 core Intel Itanium 2

9100 series processors (1.6 GHz, 24 MB); 255.74 GB

Database IBM DB2 9.7

3 x HP 8400 Enterprise Virtual Array (EVA8400) with 1 - 112x146GB EVA DB2 log 2 - 192x146GB EVA DB2

database

HP ProLiant DL580 and DL785 Servers

Application Server SAP NetWeaver 7.1

4 x DL580 G5; Intel Xeon X7350 4P/16C 2.93GHz;

64GB; 16x146GB 10K SAS

4 x DL785 G6; AMD 08439SE 8P/48C 2.8GHz 6MB L3; 384

GB; 8x146GB 15k SAS

HP Integrity and ProLiant server, IBM DB2 and SAP Reference Configuration

73625140 15111410139128 2319221821172016

HP StorageWorks 8/8 SAN Switch

ProCurve Switch

3500yl-48G

J8693A PoE

Power

Fault

Status

LED

Mode

Act

FDx

Spd

Fan

Test

RPSEPS

PoE

Reset Clear

Mdl

PoE

Tmp

Usr

off = 10Mbps flash = 100Mbps on = 1000MbpsSpd ModeStatus of the Back Dual-Personality Port 10/100/1000-T (T) or Mini-GBIC (M)

Use o

nly

on

e (

T o

r M

) fo

r each

Po

rt

PoE-Integrated 10/100/1000Base-T Ports (1-24T) - Ports are IEEE Auto MDI/MDI-X

Link Mode

Link ModeM

M

M

M

46

45

48

47Link Mode

Link Mode T

T

T

T

44424038

43413937Link Mode

Link Mode 36343230

35333129

2826

2725Mode

Mode 22

21

24

23

20181614

19171513Link

Link

Link Mode

Link Mode 121086

11975

42

31

48

47

46

45

SAN SWITCH PROCURVE NETWORK SWITCH

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

ENTERESC

HP

StorageWorks

HSV450

UID

ENTERESC

HP

StorageWorks

HSV450

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HP

StorageWorks

HSV300

UID

HP

StorageWorks

HSV300

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

HPProLiant

DL380 G6

FANS

PROC

1

PROC

2

POWER

SUPPLY

2POWER

SUPPLY

1OVERTEMP

POWERCAP

1 2 3 4

9

8

7

6

5

4

3

2

1 1

2

3

4

5

6

7

8

9

ONLINESPARE

MIRROR

UID

2

1

4

3

6

5

8

76 5 4 3 2 1

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

ENTERESC

HP

StorageWorks

HSV450

UID

ENTERESC

HP

StorageWorks

HSV450

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HP

StorageWorks

HSV300

UID

HP

StorageWorks

HSV300

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

HPProLiant

DL380 G6

FANS

PROC

1

PROC

2

POWER

SUPPLY

2POWER

SUPPLY

1OVERTEMP

POWERCAP

1 2 3 4

9

8

7

6

5

4

3

2

1 1

2

3

4

5

6

7

8

9

ONLINESPARE

MIRROR

UID

2

1

4

3

6

5

8

76 5 4 3 2 1

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

ENTERESC

HP

StorageWorks

HSV450

UID

ENTERESC

HP

StorageWorks

HSV450

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HP

StorageWorks

HSV300

UID

HP

StorageWorks

HSV300

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

UID

HPStorageWorks

1 4 7 10

12963

HPProLiant

DL380 G6

FANS

PROC

1

PROC

2

POWER

SUPPLY

2POWER

SUPPLY

1OVERTEMP

POWERCAP

1 2 3 4

9

8

7

6

5

4

3

2

1 1

2

3

4

5

6

7

8

9

ONLINESPARE

MIRROR

UID

2

1

4

3

6

5

8

76 5 4 3 2 1

UID

HPStorageWorks

1 4 7 10

12963

Disk storage

The key advantage of the EVA disk array is its ability to virtualize multiple physical disk drives into a single block of

disk space, called a disk group. Although both controllers in an EVA can access all physical disks, a Vdisk is

assigned to be managed by only one controller at a time. The HSV450 controllers connect via four host ports (FP1,

FP2, FP3, and FP4) to the SAN fabrics. The hosts that will access the storage system are connected to the same

fabrics. The logical representation of SAN topology is shown in figure 2. Consequently, a single Vdisk can only use

the resources of a single controller, such as cache, data path bandwidth, Fibre Channel ports, or processor cycles.

Distributing the workload evenly across both controllers ensures the maximum total performance of the array. There

are two methods to distribute the access: assignment and striping. In assignment, the database or system

administrator will assign different files or file sets to different Vdisks through different controllers. The Vdisks are

assigned access through different controllers to the host machine and are allocated to DB2 as FILE containers. This is

discussed in detail in the Database Managed Space (DMS) tablespace section. DB2 does the striping across both the

Vdisks thus both controllers are accessed equally.

For striping, database administrators can use the operating system to stripe the data evenly to the controllers. Striping

provides the best performance distribution of the workload. Here is an example of striping across controllers: Two

Vdisks are created within a single disk group. Each Vdisk is assigned access through a different controller. HP-UX

LVM (logical volume manager) stripes the two Vdisks to form a single logical disk or LVM presented to the file system.

The LVM striping ensures both controllers are accessed equally. This is discussed in the section LVM layout.

4

Figure 2. DB2 Database SAN topology

EVA 8400

1620

1721

1822

1923

2428

2529

2630

2731

04

15

26

37

812

913

114

1115

4/32 SAN Switch

1620

1721

1822

1923

2428

2529

2630

2731

04

15

26

37

812

913

114

1115

4/32 SAN Switch

EVA HSV450 Controller

PS 2PS 1

Mgmt

DP1-A DP2-A DP3-A MP1 FP4FP3FP2FP1 MP2 DP1-B DP2-B DP3-B

EVA HSV450 Controller

PS 2PS 1

Mgmt

DP1-A DP2-A DP3-A MP1 FP4FP3FP2FP1 MP2 DP1-B DP2-B DP3-B

Cell 0 Core I/O Cell 1 Core I/O

Ce

ll 3

Ce

ll 1

Ce

ll 0

Ce

ll 2

Console LANConsole LAN

LVD

SCSI

Optional Cell Board

Optional Cell BoardOptional Cell Board

BPS 1

BPS 0

PDCA B1

PDCA B0

LVD

SCSI

BPS5

BPS4

PDCA A1

PDCA A0

DVD / DDS 0 DVD / DDS 1

Modem

UPSConsole

1000t LAN

Se

rial

u320 Disk Slot 2

u320 Disk Slot 3

Modem

UPSConsole

Se

rial

1000t LAN

u320 Disk Slot 0

u320 Disk Slot 1

1 2 3 4 5 6 7 81 2 3 4 5 6 7 8

66

MH

z P

CI-X

Mo

de

1

13

3M

Hz P

CI-X

Mo

de

1

66

MH

z P

CI-X

Mo

de

1

13

3M

Hz P

CI-X

Mo

de

1

13

3M

Hz P

CI-X

Mo

de

1

13

3M

Hz P

CI-X

Mo

de

1

13

3M

Hz P

CI-X

Mo

de

1

26

6M

Hz P

CI-e

Mo

de

2

26

6M

Hz P

CI-e

Mo

de

2

26

6M

Hz P

CI-e

Mo

de

2

26

6M

Hz P

CI-e

Mo

de

2

26

6M

Hz P

CI-e

Mo

de

2

26

6M

Hz P

CI-e

Mo

de

2

26

6M

Hz P

CI-e

Mo

de

2

0/0

/8/0

/0

0/0

/10

/0/0

0/0

/12

/0/0

0/0

/14

/0/0

0/0

/6/0

/0

0/0

/4/0

/0

0/0

/2/0

/0

0/0

/1/0

/0

1/0

/8/0

/0

1/0

/10

/0/0

1/0

/12

/0/0

1/0

/14

/0/0

1/0

/6/0

/0

1/0

/4/0

/0

1/0

/2/0

/0

1/0

/1/0

/0

13

3M

Hz P

CI-X

Mo

de

1

26

6M

Hz P

CI-e

Mo

de

2

0/0/0/2/1.x.0 1/0/0/2/1.x.0

0/0/0/2/0.6.0

0/0/0/3/0.6.0

1/0/0/2/0.6.0

1/0/0/3/0.6.0

Partition 1 Partition 1

Partition 0Partition 0

BPS3

BPS2

Chipset HP SX2000

rx8640

CPU 1

CPU 2

CPU 3

CPU 0

Memory

CPU

CTRL A

CTRL B

SAN 1

SAN 2

SAN TOPOLOGY FOR EACH EVA8400

Multipath storage devices

HP-UX 11i v3 introduces a new representation of mass storage devices called the agile view. The central idea of the

agile view is that disk and tape devices are identified by the actual object via its World Wide Identifier (WWID) and

not by a path to the device. Paths to a device can change dynamically, and multiple paths to a single device can be transparently treated as a single virtualized path, with I/O distributed across those multiple paths. This representation

increases the reliability, adaptability, performance, and scalability of the mass storage stack, all without the need for

operator intervention.

The Vdisks created for the tablespaces and log files are accessed using the agile representation of the disks

(/dev/disk/disk40 and /dev/disk/disk41) so that the HP-UX multipath feature is used. The following example

represents 4 channels from each HBA port. Two HBA ports are presented to each Vdisk for high availability. Two

Vdisks are presented to the host with two HBA ports per EVA controller. LUN disk41 is accessed through controller A

and disk40 is accessed through controller B of the EVA8400. Figure 3 shows the logical representation of how

database tablespaces are striped across two EVAs.

# ioscan -m lun /dev/disk/disk40

class I Lun H/W Path Driver S/W State H/W Type Health Description

disk 40 64000/0xfa00/0x10 esdisk CLAIMED DEVICE online HP HSV450

1/0/8/1/0.0x50001fe1501e76cc.0x400a000000000000

1/0/8/1/0.0x50001fe1501e76cd.0x400a000000000000

1/0/8/1/0.0x50001fe1501e76ce.0x400a000000000000

1/0/8/1/0.0x50001fe1501e76cf.0x400a000000000000

2/0/8/1/0.0x50001fe1501e76cc.0x400a000000000000

2/0/8/1/0.0x50001fe1501e76cd.0x400a000000000000

2/0/8/1/0.0x50001fe1501e76ce.0x400a000000000000

2/0/8/1/0.0x50001fe1501e76cf.0x400a000000000000

/dev/disk/disk40 /dev/rdisk/disk40

5

# ioscan -m lun /dev/disk/disk41

class I Lun H/W Path Driver S/W State H/W Type Health Description

disk 41 64000/0xfa00/0x11 esdisk CLAIMED DEVICE online HP HSV450

1/0/10/1/0.0x50001fe1501e76c8.0x400a000000000000

1/0/10/1/0.0x50001fe1501e76c9.0x400a000000000000

1/0/10/1/0.0x50001fe1501e76ca.0x400a000000000000

1/0/10/1/0.0x50001fe1501e76cb.0x400a000000000000

2/0/10/1/0.0x50001fe1501e76c8.0x400a000000000000

2/0/10/1/0.0x50001fe1501e76c9.0x400a000000000000

2/0/10/1/0.0x50001fe1501e76ca.0x400a000000000000

2/0/10/1/0.0x50001fe1501e76cb.0x400a000000000000

/dev/disk/disk41 /dev/rdisk/disk41

The database can achieve better performance with multiple LUNs, or they might require special queue depth tuning to

achieve maximum performance with a small number of LUNs. The HP-UX system automatically sets the queue depth to

the default value of 8. The scsictl command allows viewing and changing the queue depth parameter for each

device, as shown in the following examples:

View the current SCSI queue depth:

#/usr/sbin/scsictl -a /dev/rdisk/disk40

immediate_report = 0; queue_depth = 8

Change the SCSI queue depth to 24:

#/usr/sbin/scsictl -m queue_depth=24 a /dev/rdisk/disk40

immediate_report = 0; queue_depth = 24

View SCSI queue depth after change:

#/usr/sbin/scsictl -a /dev/rdisk/disk40

immediate_report = 0; queue_depth = 24

6

Figure 3. DB2 database disk layout

GL_PAYMITEM

Tablespace

PAYMITEM

Tablespace

TBK Database

Tablespaces

Disk Group

192-disks

Disk Group

192-disks

Disk Group

112-disks

Logical Volume 1.8TB

Stripe across 4 EVA LUNs

Stripe size 1024K

EVA8400

192x146GBEVA8400

112x146GB

EVA8400

192x146GB

Logical Volume 1.0TB

Stripe across 4 EVA LUNs

Stripe size 1024K

Logical Volume 500GB

Stripe across 4 EVA LUNs

Stripe size 1024K

Logical Volume 500GB

Stripe across 2 EVA

LUN

DB2 LOG

DB2 log files

DB2 supports two different modes of logging: circular or archive (db cfg LOGRETAIN). In circular mode a

predefined number (db cfg LOGPRIMARY) of fixed size (db cfg LOGFILSIZ) log files are created in the database

subdirectory.

The I/O characteristics of log files with primarily sequential writes (sequential reads only during crash recovery) is

different than the primarily random read access to most tablespaces. It is a good idea to place the database control

and log files on a single file system separated from the tablespaces. If necessary the log file can be placed on

separate storage by using the database configuration parameter NEWLOGPATH. Mirroring (RAID1) is highly

recommended because the loss of the log files may render the complete database inaccessible after a server crash.

In the test configuration two Vdisks were created on a separate EVA8400 specifically used for database log files.

Each Vdisk is accessed through a different controller and presented to the HP-UX server. In your environment if you

are sharing the same EVA for tablespaces and log files, you can create separate Vdisks for tablespaces and log files

accessible through different controllers. Figure 3 shows the logical representation of the database tablespace and log

files storage. The two Vdisks were striped across as described below using LVM stripe size of two. The file system

created using the logical volume was provided as NEWLOGPATH database configuration parameter as shown

below.

Create the volume group with two Vdisks:

#vgcreate -s 32 /dev/vgdb2log /dev/disk/disk68 /dev/disk/disk69

-s: sets the number of megabytes in each physical extent expressed in units of megabytes (MB) in the range of

1 to 256.

Create the logical volume with stripe size of 1024k and striping across 2 disks:

#lvcreate i 2 I 1024 L 100000 n lvol1 /dev/vgdb2log

-i: number of disks to stripe across

-I: stripe size in kilobytes

-L: size of logical volume in MB

7

Create the file system for DB2 log:

# mkfs -F vxfs o bsize=8192,largefiles /dev/vgdb2log/rlvol1

bsize=bsize bsize is the block size for files on the file system and represents the smallest amount of disk

space allocated to a file.

Mount the file system for DB2 log:

#mount /dev/vgdb2log/rlvol1 /DB2LOG/TBK

Update the DB2 database parameter with the new log path:

#db2 update db cfg for database_name using NEWLOGPATH /DB2LOG/TBK

Separating logs and data leads to better resiliency and the ability to optimize performance or service levels for each

independently.

A setup with separate logs and data can also outperform a shared storage setup. Firstly, because I/Os to devices

holding logs are sequential on real physical disks, actuator seeks are avoided, I/O service time is reduced, and

throughput is higher than with random I/O. For OLTP, fast log response time is often more important than I/O service

times for data, which is frequently asynchronous.

DB2 tablespaces

DB2 database has two types of tablespaces SMS and DMS. They are described below.

System Managed Space (SMS) tablespace

A minimum set of SMS files are created when the tablespace is created using the MANAGED BY SYSTEM USING

command parameter. The advantage of SMS is that storage space is allocated by the operating system as required.

In contrast, DMS space is allocated using the create command and resized only in predefined extents with db2 alter

tablespace.

The same operating system performance penalties, such as, double buffering and single write locking, apply to SMS

and DMS FILE. DMS provided better performance than SMS tablespaces in the testing. The following site provides

further comparison of SMS and DMS tablespaces

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/c0055446

.html.

Database Managed Space (DMS) tablespace

DMS files are created using the MANAGED BY DATABASE USING command parameter. DMS storage allows

better control of the placement data by the database manager in comparison to SMS. For DMS FILE a single file is

associated which each container and space requirements have to be defined at the time the tablespace is created.

Multiple containers can be associated with a single tablespace. While for DMS FILE the database manager will

allocate the storage inside a file system, added or resized tablespaces can be done only by ALTER TABLESPACE

not dynamically on demand as with SMS. Because data inside tablespaces is read in random patterns by the

database not in a sequential fashion striping across multiple disks and/or controllers significantly boosts

performance. If you choose to implement disk striping along with DB2 striping, the extent size of the tablespace and

the strip size of the disk should be identical.

The following commands are used to create striped logical volumes (LVM) for the database.

Create the volume group with four Vdisks:

#vgcreate -s 32 /dev/vgdb2sap /dev/disk/disk40 /dev/disk/disk41 /dev/disk/disk58

/dev/disk/disk59

-s: sets the number of megabytes in each physical extent expressed in units of megabytes (MB) in the range of

1 to 256.

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/c0055446.htmlhttp://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/c0055446.html

8

Create the logical volume with stripe size of 1024k and striping across 4 disks:

#lvcreate i 4 I 1024 L 10000 n lvol1 /dev/vgdb2sap

-i: number of disks to stripe across

-I: stripe size in kilobytes

-L: size of logical volume in MB

Create the file system for DB2 database:

# mkfs -F vxfs o bsize=8192,largefiles /dev/vgdb2sap /rlvol1

bsize=bsize bsize is the block size for files on the file system and represents the smallest amount of disk space

allocated to a file.

Mount the file system for DB2 database:

#mount /dev/vgdb2sap /rlvol1 /db2/TBK

The DB2 database was created on the filesystem that was created on the logical volume in volume group vgdb2sap

with stripe size of 4. The following is the DB2 create database statement:

#db2 create database TBK automatic storage yes on /db2/TBK/sapdata1,

/db2/TBK/sapdata2, /db2/TBK/sapdata3, /db2/TBK/sapdata4 dbpath on /db2/TBK

...

pagesize 16k dft_extent_sz 2 catalog tablespace managed by automatic storage

...

create tablespace TBK#STABD in nodegroup SAPNODEGRP_TBK extentsize 2 prefetchsize

automatic dropped table recovery off no file system caching;

These are the 4 Vdisks presented from the two EVA8400s allocated for database tables. Each Vdisk is managed by a

separate controller on the EVA thus improving the performance. Multiple VxFS file systems were created for database

tablespaces. The largest table PAYMITEM was move to tablespace payitemtbsp using FILE containers on

/db2/TBK/sapdata5, /db2/TBK/sapdata6, /db2/TBK/sapdata7, and /db2/TBK/sapdata8 for better

performance. The following are the commands to create the file system and tablespace:

Create the file system for DB2 tablespaces:

# mkfs -F vxfs o bsize=8192,largefiles /dev/disk/disk111 /db2/TBK/sapdata5

# db2 create tablespace payitemtbsp in nodegroupSAPNODEGRP_TBK pagesize 16k

managed by database using (FILE /db2/TBK/sapdata5, 150000M) using (FILE

/db2/TBK/sapdata6,150000M) using (FILE /db2/TBK/sapdata7, 150000M) using

(FILE /db2/TBK/sapdata8, 150000M) on node(0) extentsize 2 prefetchsize

automatic dropped table recovery off autoresize yes maxsize none no file system

caching;

LVM layout

EVA8400 storage controllers offer excellent RAID striping directly in the controller firmware. Use the striping that

EVA8400 controllers provide. If you provide more than one LUN to a DB2 database server or database partition, use

DB2 fine-grained striping between containers.

Because two levels of striping are adequate for all systems, avoid using a third level of striping, such as the operating

systems logical volume manager (LVM) striping.

In case of DMS, DB2 is able to stripe internally between containers of a single tablespace, but using LVM for this

feature is more flexible and easier to administrate. Striping data across multiple LUNs reduces congestion caused by

nearly concurrent access to the data on the disk. The more stripes the better the read performance and as such the

9

shorter respond time for a database query. In benchmark environments separate spindles are assigned to each stripe

unit using only a fraction of the available space of each disk. In real world database environments any available

space might be allocated in a more random, uncontrolled fashion.

File system layout

The mkfs (make file system) command will use the underlying LVM volume layout and size the new file system

accordingly. On the command line the following command has to be executed:

# mkfs -F vxfs o bsize=8192,largefiles /dev/vg02/rlvol1

bsize: is the block size for files on the file system and represents the smallest amount of disk space allocated to

a file.

This will create a new file system on the logical volume named rvol1. The default block size is increased from the

default of 1024 Byte to the maximum value of 8192 Byte.

DB2 9.7 supports Concurrent I/O (CIO). CIO allows multiple threads to simultaneously perform reads and writes on a

shared file and locks the file in exclusive mode only during metadata (inode) update operations. Locking is taken care

of by the database. CIO can be turned on by using the NO FILE SYSTEM CACHING options of the create/alter

tablespace commands.

db2> create tablespace payitemtbsp in nodegroup SAPNODEGRP_TBK pagesize 16k

managed by database using (FILE /db2/TBK/sapdata5, 150000M) using (FILE

/db2/TBK/sapdata6,150000M) using (FILE /db2/TBK/sapdata7, 150000M) using

(FILE /db2/TBK/sapdata8, 150000M) on node(0) extentsize 2 prefetchsize

automatic dropped table recovery off autoresize yes maxsize none no file system

caching;

The above command will create a tablespace with CIO turned on. CIO can be enabled on an existing tablespace

using the command:

db2>ALTER TABLESPACE PAYITEMTBSP NO FILE SYSTEM CACHING;

On HP-UX systems, install the OnlineJFS product to enable CIO. OnlineJFS on HP-UX is a licensed product and should

be purchased before using these features. The DB2 best practice is to use CIO. In case CIO is not enabled then Direct

I/O (DIO) is automatically turned on.

# swlist | grep JFS

B3929GB B.05.01.02 OnlineJFS for Veritas File System 5.0.1 Bundle

File systems can be managed easily when compared to raw devices because you can use a single file system as a

container for multiple tablespaces.

DB2 registry variables

The default value of AUTOMTIC was set to NUM_IOCLEANERS, NUM_IOSERVERS and PREFETCHSIZE configuration

parameters. This setting gave the best performance in the test environment. DB2 best practice is that the number of

cleaners is equal to the number of physical cores instead of logical cores.

#db2set DB2_USE_FAST_PREALLOCATION=OFF

When DB2 fast pre-allocation is enabled (which it is by default), space is reserved on the VxFS file system for new

or extended files via the VX_GROWFILE mechanism. While this allows for the rapid creation of large files, it does

impose a small additional overhead every time a page within the pre-allocated region is first written. The overhead

can become more pronounced when the first write may happen for many pages in parallel, as could happen with

aggressive DB2 page cleaning. For certain workloads, such as tables intended to grow continuously due to frequent

inserts, this small overhead can become a significant bottleneck. The use of fast pre-allocation is therefore not

recommended in scenarios where run-time insert performance is critical.

10

Implementing a proof-of-concept

As a matter of best practice for all deployments, HP recommends implementing a proof-of-concept using a test

environment that matches as closely as possible the planned production environment. In this way, appropriate

performance and scalability characterizations can be obtained. For help with a proof-of-concept, contact an HP

Services representative (http://www.hp.com/large/contact/enterprise/index.html) or your HP partner.

Summary

The DB2 database performance can be improved by utilizing the disk array capabilities (using both the controllers) of

the EVA8400, distributing the load across multiple file systems/containers, and striping across multiple LUNs for

better I/O response time. Configuring the database system with CIO using NO FILE SYSTEM CACHING provides

near raw performance for I/O intensive workloads. DB2 autonomic features help to make database administration as

easy and low-cost as possible. They leverage the flexibility and performance of the database.

http://www.hp.com/large/contact/enterprise/index.html

For more information

Performance improvements using Concurrent I/O on HP-UX 11i v3 with OnlineJFS 5.0.1 and the HP-UX 11i Logical

Volume Manager, http://h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA1-5719ENW HP 4400/6400/8400 Enterprise Virtual Array configuration,

http://h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA2-0914ENW

DB2 Best Practices: Database Storage, http://www.ibm.com/developerworks/data/bestpractices/databasestorage/

IBM DB2 9.7 for Linux, UNIX, and Windows Information Center,

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp

LibcEnhancement library,

https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=LibcEnh

To help us improve our documents, please provide feedback at

http://h71019.www7.hp.com/ActiveAnswers/us/en/solutions/technical_tools_feedback.html.

Copyright 2011 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The

only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services.

Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or

omissions contained herein.

Windows is a U.S. registered trademark of Microsoft Corporation. UNIX is a registered trademark of The Open Group. Intel, Xeon and

Itanium are trademarks of Intel Corporation in the U.S. and other countries.

4AA3-8389ENW, Created November 2011

http://h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA1-5719ENWhttp://h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA2-0914ENWhttp://www.ibm.com/developerworks/data/bestpractices/databasestorage/http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsphttps://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=LibcEnhhttp://h71019.www7.hp.com/ActiveAnswers/us/en/solutions/technical_tools_feedback.htmlhttp://www.hp.com/go/getconnected