rollforward和缓冲池

字数 1787阅读 2450评论 5赞 0

俺们的生产环境是64G内存，DB2实际使用28G，把800G的备份镜像在内存4G的乞丐小机上恢复，rollforward日志时遇到性能问题，DB2（9.5.6）收到SIGDANGER信号，db2wdog报error，内存Free为0，hdisk0忙到100%，显然内存不足，PS很忙。为了赶时间将PS由2G调至32G，经过漫长等待，rollforward成功！（不过悲剧的是哥忘了加上and stop！试了一下单独stop，我次奥，还是要费好长时间）但这么处理显然不完美，最不解的是问题发生原因。   为啥要把PS直接调至32G？因为哥第一反应是怀疑rollforward会用原系统的缓冲池大小做为干活时的内存大小，但反过来想，如果DB2真这么干，那它也太笨了啊！它能知道原来bufferpool是多大，也能知道当前的系统有多少内存可用啊，变通一下多容易的事啊，它不会这么傻吧！   后面的事实证明，它就是特么的这么傻。   rollforward干活需要内存，这个内存是什么？在某个角落另开辟一个？DB2没这么大胆吧。难道用bufferpool？不会吧，数据库处于rollforward pending状态，不能connect的。但DB2会不会对rollforward命令网开一面？把它算成是一个特殊应用而允许连接到数据库，将数据库偷偷激活，或直接读取缓冲池控制文件就可以知道bufferpool有多大，从而激活并使用。   验证这个想法只能是db2trc大招了。   创建一个库，把IBMDEFAULTBP改成一个特殊的大小，恩，就改成我儿子的生日吧：   C:>db2 alter bufferpool ibmdefaultbp size 120509  DB20000I The SQL command completed successfully.   干掉数据库，恢复，打开db2trc，rollforward，关闭db2trc，生成泥玛的dump文件有826兆，FLW是345兆，FMT是2G！只有用UE才能胜任打开FMT文件，直奔FMT文件，全字匹配搜索120509，嘿嘿！把缓冲池设成这样的大小妙用正是在此。果然rollforward不负哥的期望，真的找到它了：   30487 entry DB2 UDB buffer pool services sqlbSetupSegmentInfo fnc (1.3.2.205.0)  pid 880 tid 5524 cpid 3616 node 0 sec 26 nsec 471387264  eduid 5524 eduname db2agent  bytes 36   Data1 (PD_TYPE_SQLB_PAGESIZE_TYPE,4) Page size type:  4096  Data2 (PD_TYPE_UINT,4) unsigned integer:  120509  Data3 (PD_TYPE_UINT,4) unsigned integer:  32   第30487即是，很靠前，搜SQLBP.1一样可以找的到。又翻了翻FLW，看到了许多它上一级的App字样，大意应该是做为App连到数据库，先激活隐藏缓冲池，又激活了这个120509的缓冲池，总之这两个文件太大，细节看不过来了，但基本对前面的猜想有了验证。   接下来重做一次恢复和前滚，在做的过程中，用db2pd在另一个窗口执行db2pd -db test -buf -repe 1   结果很神奇也在预料之中，restore时，看到了四个隐藏缓冲池，restore结束后，提示数据库未激活。rollforward时再次可以看到数据，除了四个隐藏，还有IBMDEFAULTBP，rollforward结束后又提示数据库未激活了，哈哈！真好玩！   解决这样问题的思路也就清晰了，restore和缓冲池无关，rollforward必须override掉原有系统的缓冲池，db2set DB2_OVERRIDE_BPF=1000，重新启一次实例，后边的事就都OK啰！

内存

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！