CSS initialization事件溯源

本文章,给大家分享一个经典的案例:负载很低的数据库,日常使用正常,巡检时发现等待事件异常,建议刚接触oracle数据库的DBA,检查时一定要重点关注等待事件。
问 题:
巡检发现数据库Top 5 Timed Events中CSS initialization事件排在第一

CSS initialization事件溯源
CSS initialization事件溯源

环境:

Aix 6.1

Oracle 10.2.0.5单机
 分 析:
CSS initialization 代表有进程在向CSS进行注册。但数据库是单实例,且数据库也没有使用ASM,那么为什么会出现CSS initialization?

该等待事件虽然等待的次数不多,但是每次等待的时间却很长,对系统性能肯定会有影响,所以必须进行处理。接下来分析为什么会出现该等待事件。

首先检查了数据库的alert日志,发现日志里面没有出现相关的错误。

然后找到该事件对应的sql

CSS initialization事件溯源
CSS initialization事件溯源

查看具体的sql

CSS initialization事件溯源
CSS initialization事件溯源

发现相关的sql都是对v$asm_diskgroup视图进行查询,因为查询针对系统视图的,怀疑可能是系统自带的job执行的,接下来检查是哪个用户在执行sql:

CSS initialization事件溯源

该用户是XXX系统监控模块连接数据库使用的账号,判断是数据库监控在执行该sql。

虽然该库没有使用asm,也不是RAC环境,查询v$asm_diskgroup视图也不应该有问题啊,继续分析。

手动执行sql一次耗时2分钟,检查该sql的执行计划,没有发现异常。

CSS initialization事件溯源
CSS initialization事件溯源

查询metalink,Bug 10024824 – Database/session hang with ‘CSS initialization’ ,版本是10.2.0.5,而我们的数据库版本也正好是这个版本。

CSS initialization事件溯源
CSS initialization事件溯源

文档提示该bug只出现在RAC环境,由于OH/log/<node>/client目录权限不对导致,建议改为771。

故障数据库不是RAC环境的,检查该目录权限755

CSS initialization事件溯源

检查另一套环境一样的数据库,目录权限也是755,执行同样的sql,没有问题。

如果按照bug来说,是权限的问题,那么client目录一定是不能被写入,所以才hang住。我们继续检查目录和目录中的文件。

查看目录client的下文件css*.log,共66667,每天生成251个文件。每次查询v$asm_diskgroup一次,就出现一个新的文件。另一套正常的数据库该目录下的文件只有168个。

文件内容

CSS initialization事件溯源

再次测试运行一个查询,并且用truss追踪该进程,发现了问题的根源:进程大部分的时间是花在遍历client下cssN.log文件

CSS initialization事件溯源
CSS initialization事件溯源

判断在每次查询v$asm_diskgroup的时候,都会在client下生成一个新的cssN.log文件(10.2.0.5才有,其他版本没发现),生成的命名规则是前一个数字加1。因此,生成新的cssN.log文件时,需要遍历整个client目录下的cssN.log文件,才能知道最大的数字是多少,才能生成第N+1的文件。而在client下不断生成大量文件,这个和oracle的一个unpublish bug 6004127 有关(ID 729349.1)。目前没有patch,文档上说解决的方法是用crontab定期清理client下的cssN.log、清理超过3天的日志,再次查询v$asm_diskgroup,耗时低于0.01秒。解决方案:

  1. 定期清理$ORACLE_HOME/log/hostname/client下的文件,或者升级数据库到11.2.0.3以上。
  2. 该库没有使用asm磁盘组,不用监控v$asm_diskgroup视图数据。

发表评论

登录后才能评论
服务中心
服务中心
联系客服
联系客服
返回顶部