document describes why and how to migrate DB2 objects to Dorado Storage System. designed to eliminate IO bottleneck.

Transcription

1 Accelerate DB2 Performance by Migrating Objects to Dorado Using solid storage in DB2 database makes the performance speed up with less power consumption. This document describes why and how to migrate DB2 objects to Dorado Storage System. HUAWEI OceanStor Dorado2100 G2 and Dorado5100 are SAN storage systems using all solid state disks designed to eliminate IO bottleneck. Jarvis WANG IT Storage Solution SDT, Enterprise BG Version 1.1 1

2 Why Migrate As we know, whether in OLTP (online transactional processing) or OLAP (online analytical processing) systems, DB2 database is I/O intensive. Besides, the increasing of capacity and performance is not in-phase for enterprise hard disk. The capacity of enterprise hard disk is too big and too slow for DB2 database nowadays. Migrating DB2 objects to SSDs (solid state disks, also known as flash disk), user can benefit from the low latency, high random IOPS, high sequential throughput and low power consumption features. I/O Bottleneck The result of the following statement shows the I/O wait time percent in total execute time of a DB2 OLTP database running on traditional magnets disks (15K RPM SAS disk). There s 96.25% DB time is spent on waits of I/O requests, and each physical read costs 15.4 milliseconds. The high latency of the slow magnets disks is definitely the bottleneck of the OLTP system. Capacity and Performance of Hard Disk The following table shows the capacity and performance change of enterprise hard disk in the last 5 years, the capacity is increased year by year, but the performance stays the same level. When deploying DB2 database on hard disk, users will buy much more spindles than the capacity needs to suport the high I/O throughput requirements, while the free capacity can t be used to store other data because that will make the performance of database bad. Tiering storage or pure SSD solution are now strongly recommended in DB2 database, and the solution that migrating hottest objects to Dorado fit into the performnace and capacity requirements. Year Capacity RPM OLTP Throughput OLAP Throughput GB 15 K 200 IO/s 30 MB/s GB 15 K 200 IO/s 30 MB/s GB 15 K 200 IO/s 30 MB/s GB 15 K 200 IO/s 30 MB/s GB 15 K 200 IO/s 30 MB/s OceanStor Dorado HUAWEI OceanStor Dorado2100 G2 and Dorado5100 are SAN storage systems using all solid state disks, they are designed to eliminate IO bottleneck, and accelerate mission-critical applications by reducing latency. Using Dorado2100 G2 or Dorado5100 to accelerate DB2 performance is the best choice. 2

3 Latency (ms) The following chart shows the SPC1-LIKE (OLTP workload) benchmark results of OceanStor Dorado and traditional storage systems. The latency of Dorado is lower than 1ms, but the latency of traditional storage is higher to 10ms. Dorado could significantly improve the response time and throughput in OLTP systems Troditional High End Storage-1(608 15K SAS) Dorado2100 G2 (75 SSD) Troditional High End Storage-2 ( K SAS) Dorado5100 ( 96 SSD) IOPS x Performance Acceleration The following chart shows the improvement of transaction response time and maximum user load when migrating DB2 objects from SAS disks to Dorado. Active Users Trans. Resp. Time (ms) Base Line - 48 HDDs, 16 used for data Migrate hot objects to Dorado 22 Migrate all objects to Dorado The tests are performed using TPC-C Like workload on a traditional storage with 48-15K RPM SAS disks and a Dorado5100 storage with 24 SLC SSD disks. The TPC-C objects are migrated one by one from 16 SAS disks which are configured as 2 RAID10 group, to 18 SSDs disks which are configured as 2 RAID5 group. After migrating hot objects to Dorado, the transaction response time (Trans. Resp. Time) is reduced from 260ms to 123ms, reduced 53%; the maximum user load (Active Users) is increased from 2000 to 3800, increased 90%. 3

4 After migrating all objects to Dorado, the transaction response time (Trans. Resp. Time) is reduced from 260ms to 22ms, reduced 92%; the maximum user load (Active Users) is increased from 2000 to 16000, increased to 800%. Users are significantly benefited from the low latency and high random I/O throughput of Dorado. The following two statement results show the I/O wait time information before and after migrating all objects to Dorado. The wait time of I/O operations is reduced from 15.42ms to 0.46ms, and the I/O wait time percentage is reduced from 96.24% to 48.36%. I/O wait time of hard disk I/O wait time of solid disk 4

5 What to Migrate In OLTP database, I/O operations on data files are very random and the blocks are relatively small (typically 4KB in DB2). Mostly, the performance bottleneck is caused by the latency of physical random read. The redo write is synchronize I/O operation and very frequent, and the transaction commit must wait the success of redo log write, so redo write is another critical component in OLTP system and is the second files need to be migrated to Dorado. The undo and temporary table spaces are the third objects need to be migrated to Dorado. The archive log and flash back recovery area are sequential and periodical I/O operations, and are the last to be migrated to Dorado. In OLAP database, I/O operations on data files are multiple streams sequential read and the blocks are relatively large (32k-512k). The queries are usually executed in parallel and there re multiple streams, causing I/O operations more random and the throughput decreased. Mostly, the performance bottleneck is caused by the read operation of temporary and user table spaces. The best migrating solution is move all DB2 objects to Dorado, but when the budget is not enough, you could follow the steps below to find and migrate the hottest objects to Dorado. Hottest Objects First of all, you could use the following statement to find the hottest tables and migrate them to Dorado. The following execute result shows the hottest objects order by read temperature (rows read multiple by table size) in an OLTP system which could be migrated to Dorado one by one. select substr(tabname,1,20) as table_name,data_partition_id, decimal(rows_read)/(data_object_pages+index_object_pages) AS read_temperature, decimal(rows_written)/(data_object_pages+index_object_pages) AS write_temperature from sysibmadm.snaptab where tabschema='db2inst1' order by read_temperature desc 5

6 Redo Logs The 2 nd step is to migrate redo log files to Dorado, reducing the latency of log file sync operation and log archive operation. Temporary Table Space The 3 rd step is to migrate temporary table space to Dorado. The temporary table space is a critical component in OLAP systems. Migrating temporary table space could significantly improve the performance of sorting operations. Archive Log The 4 th step is to set archive log destination to Dorado. Log archiving operation performs sequential read from redo log and sequential write to archive destination, which has a performance impact on redo log sync operations. The faster log archives, the smaller impact on performance. Setting archive log destination to Dorado could improve the transaction performance. Backup Destination The last step is to set the backup destination to Dorado, making the backup and recovery much more quickly. 6

7 How to Migrate There re many ways to migrate objects from one table space to another table space. The following steps describe migrating DB2 objects to Dorado using LOAD FROM CURSOR method. Before migrating, finding the hottest objects, planning storage size and estimating migration window are strongly recommended by HUAWEI. Also, please ensure there s no user online when migrating. The following steps are performed in DB2 LUW V on Red Hat Enterprise Linux 6.3. Tables and Indexes 1. Get the object s DDL using db2look command For example, the following DDL is got from the command db2look -d hwdb -z db2inst1 -e -t stock, STOCK is a table with 10 partitions which are stored on 10 different table spaces, and an index PK_STOCK is created on the table. 2. Get the object size from sysibmadm.snaptab view For example, you can get the size of each partitions of the table STOCK using the following command, DATA_OBJECT_PAGES is the size of each partition, INDEX_OBJECT_PAGES is the total size of all indexes created on the table, TBS_NAME is the table space name where the partition created in, and TBSP_TOTAL_PAGES is the size of the table space. 7

8 select data_partition_id, data_object_pages, index_object_pages, substr(tbsp_name,1,20) tbs_name, tbsp_total_pages from sysibmadm.snaptab s,table(mon_get_tablespace('',-2)) t where s.tabschema='db2inst1' and s.tabname='stock' and s.tbsp_id=t.tbsp_id order by data_partition_id 3. Create logical volumes or file systems on Dorado storage devices For example, create 10 volumes using the following commands to store the 10 partitions of table STOCK, the size of the volume should be at least 50% overhead to the size got in last step, it is 150% * (DATA_OBJECT_PAGES + INDEX_OBJECT_PAGES / 10) * PAGE_SIZE. pvcreate /dev/sdb pvcreate /dev/sdf vgcreate vgusr /dev/sdb /dev/sdf lvcreate -n s0 -i 2 -I 512 -L 50g vgusr lvcreate -n s1 -i 2 -I 512 -L 50g vgusr... lvcreate -n s9 -i 2 -I 512 -L 50g vgusr chown db2inst1:dasadm1 /dev/vgusr/s[0-9] 4. Create table spaces on Dorado storage path or volumes For example, create 10 table spaces like the following commands on the 10 volumes created in last step. CREATE LARGE TABLESPACE tss0 MANAGED BY DATABASE USING ( DEVICE '/dev/mapper/vgusr-s0' 50G) BUFFERPOOL bps EXTENTSIZE 128 PREFETCHSIZE 128 OVERHEAD 0.5 TRANSFERRATE 0.05 DROPPED TABLE RECOVERY OFF; 5. Rename the tables and indexes For example, using the following commands to rename table STOCK to STOCK_OLD and index PK_STOCK to PK_STOCK_OLD : 8

9 rename table stock to stock_old; rename index pk_stock to pk_stock_old; 6. Create new table and load data from the old For example, change the table space in the table DDL got from db2look command, and execute it to create new table on the new table spaces created on Dorado storage. Then load data into the new table from the old one. CREATE TABLE "DB2INST1"."STOCK" ( "S_W_ID" INTEGER NOT NULL,... "S_DIST_10" CHAR(24) ) PARTITION BY RANGE("S_W_ID") (PART "PART0" STARTING(1) IN "TSS0", PART "PART1" STARTING(1001) IN "TSS1",... PART "PART9" STARTING(9001) ENDING(10000) IN "TSS9") ; DECLARE C_STOCK CURSOR FOR SELECT * FROM STOCK_OLD; LOAD FROM C_STOCK OF CURSOR INSERT INTO STOCK NONRECOVERABLE; 7. Re-create indexes on the new table For example, using the DDL got from db2look command to re-create indexes for table STOCK : CREATE INDEX "DB2INST1"."PK_STOCK" ON "DB2INST1"."STOCK" ("S_W_ID" ASC, "S_I_ID" ASC) PARTITIONED COMPRESS NO ALLOW REVERSE SCANS; 8. Run statistics For example, using the following command to re-run statistics on table STOCK : runstats on table stock and indexes all; 9. Done. Redo Logs 1. Change the new transaction log path to Dorado storage path db2 update db cfg using NEWLOGPATH "/opt/db2/fsys" 2. Restart database db2 force application all 9

10 db2 terminate db2 connect to hwdb 3. Done. Temporary Table Space 1. Create temporary table space in Dorado storage path CREATE SYSTEM TEMPORARY TABLESPACE TEMPSPACE2 MANAGED BY SYSTEM USING ('/opt/db2/fsys/tempspace2'); 2. Drop the old temporary table space drop tablespace tempspace1; 3. Done. Archive Log 1. Change the archive log destination parameter db2 update db cfg using LOGARCHMETH1 'DISK:/opt/db2/fsys/' 2. Done. Backup Destination 1. Specify the new backup destination when backup db2 backup db hwdb to /opt/db2/fbak1,/opt/db2/fbak2 2. Done. 10

11 Best Practices for Dorado This chapter introduces best practices when migrating DB2 objects to Dorado Storage System. RAID Level Dorado provides 4 kinds of RAID level: RAID10, RAID5, RAID0, and RAID1. Level RAID0 provides maximum random write performance but it s not safe. RAID10 provides double random write performance than RAID5, but it s more expensive. When migrating DB2 objects to Dorado, RAID5 is the best choice. But when the write performance of RAID5 can t fit into your database throughput, chose RAID10 or add more SSDs to build new RAID5 groups for your database. Write Policy Dorado provides 3 kinds of write policies for LUN: write through, write back with cache mirroring, and write back without cache mirroring. Write through is the default policy, in which mode dirty pages are directly written to SSDs on Dorado by I/O cleaners, which policy can be used for LUNs store user tables and indexes. For LUNs store redo log files and archive logs, you could change the policy to write back with cache mirroring with the help of HUAWEI technical support engineers. In write back mode, dirty pages are written to Dorado Cache Pool, and later synced to SSDs in the background with LRU-LIKE algorithm. The latency is very low because blocks are only written to Dorado memory. With cache mirroring, each write I/O from DB2 is first written to the cache of LUN s owner controller, and at the same time transferred to another controller through the mirror channel between the two controllers, making the latency of write I/O higher than no cache mirroring. Linux I/O Scheduler DB2 database is more widely deployed on Linux operating system nowadays. There re 4 kinds of I/O scheduler for block devices in Linux kernel 2.6: noop, anticipatory, deadline, and cfq. The default I/O scheduler is cfq, which is not suitable for Dorado. For DB2 database, deadline is recommended for OceanStor T series storage systems and noop is recommended for OceanStor Dorado storage system. Using the following command, you can change the I/O scheduler of /dev/sdb to noop and /dev/sdc to deadline : echo noop > /sys/block/sdb/queue/scheduler echo deadline > /sys/block/sdc/queue/scheduler 11

12 SLC or emlc Two types of SSD are supported on Dorado, SLC (Single-Layer Chip) and emlc (Enterprise Multi-Layer Chip). SLC has much better random write performance and more number of block erase count, but more expensive than emlc. SLC and emlc almost have the same random read performance. The write ratio of OLTP workload is typically 20% - 60%, but there re scenarios lower than 20%. For write intensive OLTP workload, SLC is a better choice considering performance and erase count. For read-mostly or read-only OLTP workload, emlc is a better choice. In OLAP database, the data is written once and read many times, and the updated data is periodically loaded into database. Choosing emlc is a better idea for OLAP workload. 12

13 Copyright Huawei Technologies Co., Ltd All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd. Trademark Notice HUAWEI, and are trademarks or registered trademarks of Huawei Technologies Co., Ltd. Other trademarks, product, service and company names mentioned are the property of their respective owners. General Disclaimer The information in this document may contain predictive statements including, without limitation, statements regarding the future financial and operating results, future product portfolio, new technology, etc. There are a number of factors that could cause actual results and developments to differ materially from those expressed or implied in the predictive statements. Therefore, such information is provided for reference purpose only and constitutes neither an offer nor an HUAWEI TECHNOLOGIES CO., LTD. Huawei Industrial Base Bantian Longgang Shenzhen , P.R. China Tel: acceptance. Huawei may change the information at any time without notice. PROVIDED BY HUAWEI STORAGE PERFORMANCE LAB 13