之前遇到的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博客 ” ,链接:http://blog.itpub.net/14517718/viewspace-1007957/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14517718/viewspace-1007957/