银行数据库
db2 backup 备份效率请教
我有两个olap系统的数据库。
全备大小:库A 2.5T，库B 1.5T。
目前全备时间:库A 16:30，库B 9:15
表空间个数：都是28个
--备份现状
备份编目分区时:库Ａ的db2bm进程个数16个，db2med进程个数为8个
库B的db2bm进程个数9个，db2med进程个数为5个
启用的buffers数量不详，不知道从哪里去查看。
备份脚本除了指定了多个目录，其他都是默认值【看相关建议，说是backup会根据数据库大小及系统资源情况进行参数的优化配置】
现在觉得备份时间窗口过长，从数据库的角度去想个办法提升下全备的效率。
向各位大侠请教下相关优化方案，谢谢啦！
全备大小:库A 2.5T，库B 1.5T。
目前全备时间:库A 16:30，库B 9:15
表空间个数：都是28个
--备份现状
备份编目分区时:库Ａ的db2bm进程个数16个，db2med进程个数为8个
库B的db2bm进程个数9个，db2med进程个数为5个
启用的buffers数量不详，不知道从哪里去查看。
备份脚本除了指定了多个目录，其他都是默认值【看相关建议，说是backup会根据数据库大小及系统资源情况进行参数的优化配置】
现在觉得备份时间窗口过长，从数据库的角度去想个办法提升下全备的效率。
向各位大侠请教下相关优化方案，谢谢啦！
18同行回答
你是什么方法backup? 用TSM吗？你的backup storage是在LAN上吗？ network speed？drdb2 发表于 2011-12-27 00:08
命令备份到挂载到本地的nas存储上，db2 backup database...这种中等规模数据量，备份策略上可以考虑每周全备，每天增量备份。
优化参数
PARALLELISM n
WITH num-buffers BUFFERS
BUFFER buffer-size
UTIL_IMPACT_PRIORITY
优化技术
增大PARALLELISM为要备份的表空间的数目
增大buffer的数目
增大buffer 的尺寸
增大UTIL_HEAP_SZ的尺寸
只备份不含有LOB数据的表空间
启用压缩收起
优化参数
PARALLELISM n
WITH num-buffers BUFFERS
BUFFER buffer-size
UTIL_IMPACT_PRIORITY
优化技术
增大PARALLELISM为要备份的表空间的数目
增大buffer的数目
增大buffer 的尺寸
增大UTIL_HEAP_SZ的尺寸
只备份不含有LOB数据的表空间
启用压缩收起
浏览798
专家出来了，该去结贴了。
上面的回复都很好，很有启发性，谢谢大家了。
再去研究把备份当时起了多少buffers的数量，然后再确定下需要指定多少的buffers数量，呵呵！
分我就暂时打给王专家了，大家没意见吧？收起
浏览815
浏览793
很多时候就是因为数据分布不均衡，所以在备份时候不能并发的读取，硬件有限的前提下，速度当然没法快了
观看备份期间的OS资源负载曲线[除了备份几乎没起其他作业],
CPU:备份编目分区时,平均值大概在30%上下浮动,高峰不过57%,其他分区同时备份的,最高不过91%,平均基本在57%上下浮动
MEM:整个备份期间物理内存最低也还有将近6G多的空闲[整个物理内存64G]
IO:整个备份期间io曲线还是在低位区域运行[相对正常使用期间].
以上三个资源的曲线走势基本保持一致.
照这样看,系统硬件资源还是跟得上的,呵呵.收起
观看备份期间的OS资源负载曲线[除了备份几乎没起其他作业],
CPU:备份编目分区时,平均值大概在30%上下浮动,高峰不过57%,其他分区同时备份的,最高不过91%,平均基本在57%上下浮动
MEM:整个备份期间物理内存最低也还有将近6G多的空闲[整个物理内存64G]
IO:整个备份期间io曲线还是在低位区域运行[相对正常使用期间].
以上三个资源的曲线走势基本保持一致.
照这样看,系统硬件资源还是跟得上的,呵呵.收起
浏览826