之前遇到的buffer busy waits的问题在所做的一些变动后，情况下降许多，但问题依然存在。[@more@]因为我们的环境中遇到的buffer busy waits为data block类型，识别码为220，让人直接想到的就是，高并发的DML是导致这个环境buffer busy waits的主因。(额外附注一下：当块被读到sga后，若有session想读取或者修改它，必先获取cache buffers chains锁存器以遍历该缓冲区链而找到所必需的缓冲区头，然后，根据session所请求的类别来以共享模式或者独占模式来pin住该缓冲区头，然后才可以进行读取或者修改,pin住后然后释放cache buffer chains锁存器)。
至于出现的global null to x 和global cr request之类的cluster wait，跟我们的应用较为相关，频繁的相同的DML动作分布在三个不同的节点(RAC环境为4节点)，当修改其中一个节点SGA里的一个块后，其他节点同样有这个动作，9i的cache fusion会根据其他请求节点的GCS请求生成pi块到对应请求节点，因为session的pin动作是1:1的(pin:对象块)，且9i默认pi块是6个，所以，这是目前环境中造成cluster wait的主要原因，再深入分析一下，这也跟block_size有较大原因，若一个块中含有的行不多，就算有此类buffer busy waits 220识别码的等待，也不会是非常突出的。不行的是，这个db环境的db_block_size不知是谁设的，大小为16K。
解决方法：
1、减少块中的行数(可增加pctfree，若块大小较大，应该收效甚微)
2、将client连接节点的操作进行分类，比如将那些造成并发update的应用都连接至同一个节点，当然，这样对rac的failover挑战又提高到新的一个层面，比如若这个节点crash掉，整个业务的流程基本也被破坏掉。
至于出现的global null to x 和global cr request之类的cluster wait，跟我们的应用较为相关，频繁的相同的DML动作分布在三个不同的节点(RAC环境为4节点)，当修改其中一个节点SGA里的一个块后，其他节点同样有这个动作，9i的cache fusion会根据其他请求节点的GCS请求生成pi块到对应请求节点，因为session的pin动作是1:1的(pin:对象块)，且9i默认pi块是6个，所以，这是目前环境中造成cluster wait的主要原因，再深入分析一下，这也跟block_size有较大原因，若一个块中含有的行不多，就算有此类buffer busy waits 220识别码的等待，也不会是非常突出的。不行的是，这个db环境的db_block_size不知是谁设的，大小为16K。
解决方法：
1、减少块中的行数(可增加pctfree，若块大小较大，应该收效甚微)
2、将client连接节点的操作进行分类，比如将那些造成并发update的应用都连接至同一个节点，当然，这样对rac的failover挑战又提高到新的一个层面，比如若这个节点crash掉，整个业务的流程基本也被破坏掉。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/14517718/viewspace-1007957/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
HugeTLBfs
请登录后发表评论
登录
全部评论
最新文章
- 8.0.5是不支持case语句的
- Why does my system swaps the data instead of freeing cache and buffer memory?
- 为listener增加密码验证
- CTAS方式通过dblink抓取blob字段
- Procedure加密
- HugeTLBfs
- 性能调整一则：buffer busy waits导致主要issue
- 遭遇ORA-01152: file 1 was not restored from a sufficiently old backup
- 初始化参数OPEN_CURSORS的理解加深
- linux下转移(或者说备份)listener.log
