Cache buffers hash chain过长的问题。很奇怪~

clevernby

Oracle Support问我要了awr报告，我也传上来吧，快照时间就是做数据块dump的那个小时
awr report.zip (133.54 KB, 下载次数: 9)

2011-6-23 12:58 上传

点击文件名下载附件

由于系统还没有上线，处于开发当中，负载非常低，个人觉得意义不是很大

[ 本帖最后由 clevernby 于 2011-6-23 12:59 编辑 ]

bluemoon0083

这个测试库繁忙吗？这个latch有没有出现contention？db cache都填满了吗？

试想一下，如果一个数据库不繁忙，这种latch也没有争用，别说一个cbc chain上挂几千个，就算所有块都放上去也没有问题啊，如果数据库就一个session，这样反而效率更高
拆成更多的chain本来就是为了防止高并发的
可能oracle觉得此时挂那么多block没问题，况且是同一个block，要是真的变的忙了，有很多session开始请求，说不定还有另一套机制来把一条大的chain上的block拿下来分配给别的小的chain

当然这纯属猜测，而且为什么是First Level Bitmap Block，会有这么多重复的，确实说不上来，
我一个测试库也是这样，非rac，一个segment的第二个块重复了60多次，只不过我这里的状态都是free的，所以有前面的一问
还是看support怎么回答吧

bluemoon0083

_cr_grant_global_role          TRUE                 if TRUE, grant lock for CR requests when block is in global role
_cr_grant_local_role           AUTO                 turn 3-way CR grants off, make it automatic, or turn it on
_cr_grant_only                 FALSE                if TRUE, grant locks when possible and do not send the block
_cr_server_log_flush           TRUE                 if TRUE, flush redo log before serving a CR buffer
_cr_trc_buf_size               8192                 size of cr trace buffer
_db_aging_freeze_cr            FALSE                Make CR buffers always be too cold to keep in cache
_db_block_max_cr_dba           6                    Maximum Allowed Number of CR buffers per dba
_db_cache_process_cr_pin_max                        maximum number of cr pins a process may have
_enable_minscn_cr              TRUE                 enable/disable minscn optimization for CR
_gc_cr_server_read_wait        FALSE                if TRUE, cr server waits for a read to complete
_gc_override_force_cr          TRUE                 if TRUE, try to override force-cr requests
_gc_use_cr                     TRUE                 if TRUE, allow CR pins on PI and WRITING buffers
_kdli_force_cr                 TRUE                 force CR when reading data blocks of direct-write lobs
_kdli_force_cr_meta            TRUE                 force CR when reading metadata blocks of direct-write lobs
_row_cr                        TRUE                 enable row cr for all sql

对了隐藏参数也有可能，如果没设过的话那也问题不大，很多参数可以改变数据库行为的
可以调查下那些名字带cr的或者description里有cr的参数

clevernby

谢"大表哥"回复~

测试库当时没有人在用，只有一个GoldenGate Extract在运行，而且它也没事可干的，所以不可能出现latch竞争的。
此外db cache当时是满的有2G。

其实开这个贴也是处于谨慎考虑，生怕遭遇了什么bug，其实估计重启实例或者flush buffer cache后这个现象就不再存在了，而且也很难再重现（单位其它类似环境的机器都未现此现象），不过保险期间还是想上来问问，毕竟这里高手多，说不定有人遇到过还是个正常现象呢，小心驶得万年船啊~等系统真的上线后可禁不起这种问题折腾的，到时候被动的很。
希望Oracle Support能帮忙解决，正常现象也好、bug也好，反正给个说法嘛，我也好向领导汇报

[ 本帖最后由 clevernby 于 2011-6-23 13:30 编辑 ]

bluemoon0083

看了下awr，一个节点db time 1分钟都不到，另一个0.01分钟。。。

bluemoon0083

确实是这样，没说问这样的问题不好~

其实有条件的话可以做下压力测试，看看会有什么问题，这样就能够更放心了，做完测试再画几个图出来，看看高峰的时候可以承受什么样的压力，搞个PPT给领导看，这样双方心里都有底了

11g也可以考虑用real application testing做测试，很方便的

那个extrace估计应该没什么关系，database之外的一套东西，主要就是读读redo或archive，和buffer cache，latch没太大关联

clevernby

刚才做了一个level 4的buffer dump
alter system set events 'immediate trace name buffer,level 4'
在cache buffers chain部分如愿找到了那个很长的chain，供串了5381个buffer head，可喜的是受对应latch保护的其它buffer header都未出现在此chain上。
由于trace文件太大，刚才上传失败了，就不再上传了。

bluemoon0083

any update from support?

clevernby

Oracle Support最终没能解决这个问题，由于昨天数据库重新启动了，故障目前无法重现，SR只能暂时关闭了。
支持过程中没有什么建设性的意见，还不及坛子上的人呢，唉，总感觉他就在等我重启，好关SR，一定憋坏了.....

bluemoon0083

原帖由 clevernby 于 2011-8-24 13:14 发表
Oracle Support最终没能解决这个问题，由于昨天数据库重新启动了，故障目前无法重现，SR只能暂时关闭了。
支持过程中没有什么建设性的意见，还不及坛子上的人呢，唉，总感觉他就在等我重启，好关SR，一定憋坏了.....

哈哈就是这样的，叫你重启，然后你没办法reproduce，然后SR就名正言顺的关掉喽
万一你可以reproduce，而且db又是新版本，好了，那谁接了这个SR谁倒霉，只能不断的作实验，查文档，查内部资料，做trace，做dump
搞得天昏地暗，几天后发现还是找不出原因，只能转给更牛比的人来看，或者开bug，或者escalation到产品部，让有更多权限的人来处理，
同时你不断更新SR，诉说着俺们家的DB出现严重性能问题，都hang了，估计过会儿就要down了，每小时给公司造成损失XX万美刀，你表示压力很大
好了，此时这个support只能哭了