High Water Mark过高导致cache buffer chain等待严重
一、问题现象
数据库wait event显示latch free(cache buffer chains)等待严重，服务器CPU使用率持续达100%，数据库应用普遍出现性能问题。
数据库wait event显示latch free(cache buffer chains)等待严重，服务器CPU使用率持续达100%，数据库应用普遍出现性能问题。
二、原因分析
某分区表的其中一个分区只有4行记录，但其data blocks数目却与其他有着百万行记录的分区相当，数据高水位HWM（High Water Mark）较高（insert了大量数据，
后来又delete，导致HWM升高），导致每次访问该分区时的buffer gets较高，约几万次buffer gets。
有一些sql语句在nest loop最里层访问到该分区，nest loop几千次，多条sql并发，导致数据库热块竞争严重：latch free(cache buffer chains) ，
同时因sql的buffer gets高成本导致CPU 使用率100%。
某分区表的其中一个分区只有4行记录，但其data blocks数目却与其他有着百万行记录的分区相当，数据高水位HWM（High Water Mark）较高（insert了大量数据，
后来又delete，导致HWM升高），导致每次访问该分区时的buffer gets较高，约几万次buffer gets。
有一些sql语句在nest loop最里层访问到该分区，nest loop几千次，多条sql并发，导致数据库热块竞争严重：latch free(cache buffer chains) ，
同时因sql的buffer gets高成本导致CPU 使用率100%。
三、解决方法
（1）临时缓解方法：在HWM问题解决之前，应用禁止问题sql再次运行，Kill当前running的问题sql进程。
（2）根本解决方法：降低分区的HWM，维护后sql运行时间从小时级下降到秒级。关于降低HWM的方法，
例如可以采用下面的步骤：
备份数据，truncate问题分区，恢复数据；需留意truncate分区动作会导致该分区表上的global index状态变成unusable（local index状态不受影响），
DBA还需要对global index进行rebuild，或者在truncate的同时指定update global indexes选项。如需保留统计信息，可以先提前备份，操作完成后再将其导入。
（2）根本解决方法：降低分区的HWM，维护后sql运行时间从小时级下降到秒级。关于降低HWM的方法，
例如可以采用下面的步骤：
备份数据，truncate问题分区，恢复数据；需留意truncate分区动作会导致该分区表上的global index状态变成unusable（local index状态不受影响），
DBA还需要对global index进行rebuild，或者在truncate的同时指定update global indexes选项。如需保留统计信息，可以先提前备份，操作完成后再将其导入。
Partly command examples:
alter table odsmiddata.mid_policy_info truncate partition part0;
alter index odsmiddata.mid_policy_info_pk tablespace odsmiddata_idx rebuild parallel 6;
alter index odsmiddata.mid_policy_info_pk noparallel;
alter table odsmiddata.mid_policy_info truncate partition part0;
alter index odsmiddata.mid_policy_info_pk tablespace odsmiddata_idx rebuild parallel 6;
alter index odsmiddata.mid_policy_info_pk noparallel;
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/22578826/viewspace-749300/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
