Storage Best Practices for Deploying IBM DB2 on HP Integrity Servers & HP EVA8400 Storage
-
Upload
muhamad-noor-chik -
Category
Documents
-
view
35 -
download
8
description
Transcript of Storage Best Practices for Deploying IBM DB2 on HP Integrity Servers & HP EVA8400 Storage
-
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