Db2备份：模拟fragmentations导致备份性能问题
2018-03-05 17:00
369 查看
最近在研究Db2备份性能问题时，看到一篇文章，说的是fragmentations会影响备份的性能。
BACKUP might be affected by fragmentations in table space
http://www-01.ibm.com/support/docview.wss?uid=swg21678274
于是设计了试验来验证，主要思路是模拟 EMPTY EXTENT，方法是轮流往两个表里插入数据，使得第一个extent里放表T1数据，第二个extent里放表T2数据，第三个extent里放表T1的数据...最后把表T1删除之后，就会留下许多空的extent
1. 创建一个数据库，将userspace1删除
2. 新建一个 USERSPACE1，使extentsize尽量小
create USERSPACE1 managed by database using (file 'file1' 10G) extentsize 2
3. 在表空间userspace1里创建两个表TB1和TB2，并轮流插入数据：
str=`awk 'BEGIN { for(i = 1; i <= 2400; i++) x=x"a"; print "'\''"x"'\''"}'`
db2 "CREATE TABLE TB1(id int, name VARCHAR(3990)) in userspace1"
db2 "CREATE TABLE TB2(id int, name VARCHAR(3990)) in userspace1"
while ture
do
db2 "insert into TB1 values(123, $str)"
db2 "insert into TB2 values(456, $str)"
done
参考链接: http://blog.csdn.net/qingsong3333/article/details/78586350
4. 插入一定量数据后，表空间USERSPACE1使用状况如下
Tablespace ID = 3
Name = USERSPACE1
Type = Database managed space
Contents = All permanent data. Large table space.
State = 0x0000
Detailed explanation:
Normal
Total pages = 2621440
Useable pages = 2621438
Used pages = 1294748
Free pages = 1326690
High water mark (pages) = 1294748
Page size (bytes) = 4096
Extent size (pages) = 2
Prefetch size (pages) = 2
5. 备份，文件大小为 5470740480Bytes，性能统计信息如下：
2018-03-04-17.48.45.911792-480 E100789E1453 LEVEL: Info
PID : 1439 TID : 140007616538368 PROC : db2sysc 0
INSTANCE: inst105 NODE : 000 DB : SAMPLE
APPHDL : 0-42 APPID: *LOCAL.inst105.180305014554
AUTHID : INST105 HOSTNAME: db2a
EDUID : 287 EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, database utilities, sqluxLogDataStats, probe:395
MESSAGE : Performance statistics
DATA #1 : String, 950 bytes
Parallelism = 3
Number of buffers = 3
Buffer size = 16781312 (4097 4kB pages)
BM# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 167.46 166.95 0.00 0.01 319 5178992
001 167.45 0.45 0.03 166.96 1 608
002 167.45 4.61 0.00 162.83 7 112768
--- -------- -------- -------- -------- -------- --------
TOT 502.37 172.02 0.03 329.81 327 5292368
MC# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 169.78 14.93 152.52 0.00 328 5342520
--- -------- -------- -------- -------- -------- --------
TOT 169.78 14.93 152.52 0.00 328 5342520
使用BM#的kBytes除以I/O，得到备份时读数据的速率5292368/172.02=30MB/S
6. 删除表T1，查看表空间状态如下，可以看到高水位1294746，Used pages 647416：
Tablespace ID = 3
Name = USERSPACE1
Type = Database managed space
Contents = All permanent data. Large table space.
State = 0x0000
Detailed explanation:
Normal
Total pages = 2621440
Useable pages = 2621438
Used pages = 647416
Free pages = 1974022
High water mark (pages) = 1294746
Page size (bytes) = 4096
Extent size (pages) = 2
Prefetch size (pages) = 2
Number of containers = 1
Minimum recovery time = 2018-03-05-02.47.06.000000
7. 再次备份，文件大小为2970324992，约为原来的54%，性能统计信息如下：
2018-03-04-18.52.03.432118-480 E122643E1453 LEVEL: Info
PID : 1439 TID : 140010233784064 PROC : db2sysc 0
INSTANCE: inst105 NODE : 000 DB : SAMPLE
APPHDL : 0-78 APPID: *LOCAL.inst105.180305024950
AUTHID : INST105 HOSTNAME: db2a
EDUID : 18 EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, database utilities, sqluxLogDataStats, probe:395
MESSAGE : Performance statistics
DATA #1 : String, 950 bytes
Parallelism = 3
Number of buffers = 3
Buffer size = 16781312 (4097 4kB pages)
BM# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 129.61 0.22 0.01 129.36 3 608
001 129.60 2.30 0.00 127.28 7 112768
002 129.60 128.72 0.00 0.02 168 2589664
--- -------- -------- -------- -------- -------- --------
TOT 388.81 131.25 0.01 256.67 178 2703040
MC# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 131.29 7.44 122.15 0.00 179 2900708
--- -------- -------- -------- -------- -------- --------
TOT 131.29 7.44 122.15 0.00 179 2900708
备份读取速度为2703040/131.25=20MB/S，远远低于删表之前的速度。使用db2dart检查表空间高水位
db2dart sample /dhwm /tsi 3 /rptn db2dart.out
结果如下
...
[15992] 5 0x00 [15993] == EMPTY == [15994] 5 0x00 [15995] == EMPTY ==
[15996] 5 0x00 [15997] == EMPTY == [15998] 5 0x00 [15999] == EMPTY ==
[16000] 65534 0x0e [16001] 5 0x00 [16002] == EMPTY == [16003] 5 0x00
[16004] == EMPTY == [16005] 5 0x00 [16006] == EMPTY == [16007] 5 0x00
[16008] == EMPTY == [16009] 5 0x00 [16010] == EMPTY == [16011] 5 0x00
...
可以看到，有许多EMPTY的EXTENT，以上面为例，如果没有EMPTY的extent，那么从15992到16011的这些extent都可以一次读操作读完。有了EMPTY EXTENT之后，读操作就会中断，于是15992、15994、15996、15998等都需要一次单独的读操作，导致读取的速率降低，从而影响了备份的性能。
8. 降高水位，再次备份，性能统计信息如下
2018-03-04-21.25.31.654462-480 E181173E1453 LEVEL: Info
PID : 1456 TID : 139942902621952 PROC : db2sysc 0
INSTANCE: inst105 NODE : 000 DB : SAMPLE
APPHDL : 0-19 APPID: *LOCAL.inst105.180305052356
AUTHID : INST105 HOSTNAME: db2a
EDUID : 74 EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, database utilities, sqluxLogDataStats, probe:395
MESSAGE : Performance statistics
DATA #1 : String, 950 bytes
Parallelism = 3
Number of buffers = 3
Buffer size = 16781312 (4097 4kB pages)
BM# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 90.91 2.47 0.01 88.36 9 112768
001 90.91 90.58 0.00 0.10 159 2589504
002 90.89 0.30 0.00 90.59 1 608
--- -------- -------- -------- -------- -------- --------
TOT 272.73 93.35 0.02 179.06 169 2702880
MC# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 93.36 7.91 82.99 0.00 170 2753216
--- -------- -------- -------- -------- -------- --------
TOT 93.36 7.91 82.99 0.00 170 2753216
可以看到，BM#读取的速度为2702880/93.35=28.3MB/S,和删表之前的速度很接近，达到预期效果。
BACKUP might be affected by fragmentations in table space
http://www-01.ibm.com/support/docview.wss?uid=swg21678274
于是设计了试验来验证，主要思路是模拟 EMPTY EXTENT，方法是轮流往两个表里插入数据，使得第一个extent里放表T1数据，第二个extent里放表T2数据，第三个extent里放表T1的数据...最后把表T1删除之后，就会留下许多空的extent
1. 创建一个数据库，将userspace1删除
2. 新建一个 USERSPACE1，使extentsize尽量小
create USERSPACE1 managed by database using (file 'file1' 10G) extentsize 2
3. 在表空间userspace1里创建两个表TB1和TB2，并轮流插入数据：
str=`awk 'BEGIN { for(i = 1; i <= 2400; i++) x=x"a"; print "'\''"x"'\''"}'`
db2 "CREATE TABLE TB1(id int, name VARCHAR(3990)) in userspace1"
db2 "CREATE TABLE TB2(id int, name VARCHAR(3990)) in userspace1"
while ture
do
db2 "insert into TB1 values(123, $str)"
db2 "insert into TB2 values(456, $str)"
done
参考链接: http://blog.csdn.net/qingsong3333/article/details/78586350
4. 插入一定量数据后，表空间USERSPACE1使用状况如下
Tablespace ID = 3
Name = USERSPACE1
Type = Database managed space
Contents = All permanent data. Large table space.
State = 0x0000
Detailed explanation:
Normal
Total pages = 2621440
Useable pages = 2621438
Used pages = 1294748
Free pages = 1326690
High water mark (pages) = 1294748
Page size (bytes) = 4096
Extent size (pages) = 2
Prefetch size (pages) = 2
5. 备份，文件大小为 5470740480Bytes，性能统计信息如下：
2018-03-04-17.48.45.911792-480 E100789E1453 LEVEL: Info
PID : 1439 TID : 140007616538368 PROC : db2sysc 0
INSTANCE: inst105 NODE : 000 DB : SAMPLE
APPHDL : 0-42 APPID: *LOCAL.inst105.180305014554
AUTHID : INST105 HOSTNAME: db2a
EDUID : 287 EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, database utilities, sqluxLogDataStats, probe:395
MESSAGE : Performance statistics
DATA #1 : String, 950 bytes
Parallelism = 3
Number of buffers = 3
Buffer size = 16781312 (4097 4kB pages)
BM# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 167.46 166.95 0.00 0.01 319 5178992
001 167.45 0.45 0.03 166.96 1 608
002 167.45 4.61 0.00 162.83 7 112768
--- -------- -------- -------- -------- -------- --------
TOT 502.37 172.02 0.03 329.81 327 5292368
MC# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 169.78 14.93 152.52 0.00 328 5342520
--- -------- -------- -------- -------- -------- --------
TOT 169.78 14.93 152.52 0.00 328 5342520
使用BM#的kBytes除以I/O，得到备份时读数据的速率5292368/172.02=30MB/S
6. 删除表T1，查看表空间状态如下，可以看到高水位1294746，Used pages 647416：
Tablespace ID = 3
Name = USERSPACE1
Type = Database managed space
Contents = All permanent data. Large table space.
State = 0x0000
Detailed explanation:
Normal
Total pages = 2621440
Useable pages = 2621438
Used pages = 647416
Free pages = 1974022
High water mark (pages) = 1294746
Page size (bytes) = 4096
Extent size (pages) = 2
Prefetch size (pages) = 2
Number of containers = 1
Minimum recovery time = 2018-03-05-02.47.06.000000
7. 再次备份，文件大小为2970324992，约为原来的54%，性能统计信息如下：
2018-03-04-18.52.03.432118-480 E122643E1453 LEVEL: Info
PID : 1439 TID : 140010233784064 PROC : db2sysc 0
INSTANCE: inst105 NODE : 000 DB : SAMPLE
APPHDL : 0-78 APPID: *LOCAL.inst105.180305024950
AUTHID : INST105 HOSTNAME: db2a
EDUID : 18 EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, database utilities, sqluxLogDataStats, probe:395
MESSAGE : Performance statistics
DATA #1 : String, 950 bytes
Parallelism = 3
Number of buffers = 3
Buffer size = 16781312 (4097 4kB pages)
BM# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 129.61 0.22 0.01 129.36 3 608
001 129.60 2.30 0.00 127.28 7 112768
002 129.60 128.72 0.00 0.02 168 2589664
--- -------- -------- -------- -------- -------- --------
TOT 388.81 131.25 0.01 256.67 178 2703040
MC# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 131.29 7.44 122.15 0.00 179 2900708
--- -------- -------- -------- -------- -------- --------
TOT 131.29 7.44 122.15 0.00 179 2900708
备份读取速度为2703040/131.25=20MB/S，远远低于删表之前的速度。使用db2dart检查表空间高水位
db2dart sample /dhwm /tsi 3 /rptn db2dart.out
结果如下
...
[15992] 5 0x00 [15993] == EMPTY == [15994] 5 0x00 [15995] == EMPTY ==
[15996] 5 0x00 [15997] == EMPTY == [15998] 5 0x00 [15999] == EMPTY ==
[16000] 65534 0x0e [16001] 5 0x00 [16002] == EMPTY == [16003] 5 0x00
[16004] == EMPTY == [16005] 5 0x00 [16006] == EMPTY == [16007] 5 0x00
[16008] == EMPTY == [16009] 5 0x00 [16010] == EMPTY == [16011] 5 0x00
...
可以看到，有许多EMPTY的EXTENT，以上面为例，如果没有EMPTY的extent，那么从15992到16011的这些extent都可以一次读操作读完。有了EMPTY EXTENT之后，读操作就会中断，于是15992、15994、15996、15998等都需要一次单独的读操作，导致读取的速率降低，从而影响了备份的性能。
8. 降高水位，再次备份，性能统计信息如下
2018-03-04-21.25.31.654462-480 E181173E1453 LEVEL: Info
PID : 1456 TID : 139942902621952 PROC : db2sysc 0
INSTANCE: inst105 NODE : 000 DB : SAMPLE
APPHDL : 0-19 APPID: *LOCAL.inst105.180305052356
AUTHID : INST105 HOSTNAME: db2a
EDUID : 74 EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, database utilities, sqluxLogDataStats, probe:395
MESSAGE : Performance statistics
DATA #1 : String, 950 bytes
Parallelism = 3
Number of buffers = 3
Buffer size = 16781312 (4097 4kB pages)
BM# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 90.91 2.47 0.01 88.36 9 112768
001 90.91 90.58 0.00 0.10 159 2589504
002 90.89 0.30 0.00 90.59 1 608
--- -------- -------- -------- -------- -------- --------
TOT 272.73 93.35 0.02 179.06 169 2702880
MC# Total I/O MsgQ WaitQ Buffers kBytes
--- -------- -------- -------- -------- -------- --------
000 93.36 7.91 82.99 0.00 170 2753216
--- -------- -------- -------- -------- -------- --------
TOT 93.36 7.91 82.99 0.00 170 2753216
可以看到，BM#读取的速度为2702880/93.35=28.3MB/S,和删表之前的速度很接近，达到预期效果。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- Db2由于取sequence 的 next value 导致的性能问题案例分析
- Db2性能问题：临时表空间太大，导致连不上数据库
- 导致性能问题的常见情况
- NLS参数设置导致的性能问题案例
- SQL SERVER 2012 执行计划走嵌套循环导致性能问题的案例
- 解决Scrapy性能问题——案例五（Item并发太多导致溢出）
- 浅谈虚拟磁带库备份的性能问题
- 由于图片链接问题导致Web性能的严重的下降（转贴）
- 一个不起眼的问题导致性能的严重的下降
- sort order by导致分页语句性能问题优化
- 一次socket长连接运行导致的性能问题
- 频繁分配释放内存导致的性能问题的分析
- 自定义函数导致的sql性能问题
- 数据分布不均衡导致性能问题
- Db2性能：操作系统CPU高问题分析的一些思路
- ASP中SQL语句导致的性能问题
- 解决Scrapy性能问题——案例四（响应太多导致溢出）
- SQL优化_高水位线导致的性能问题
- SQL 问题与解答 - 数据库移动、性能优化、备份和镜像
- 频繁分配释放内存导致的性能问题的分析