CSS initialization事件溯源

介绍

我是本际云服务器推荐网的小编小本本，今天给大家分享一个经典的案例：负载很低的数据库，日常使用正常，巡检时发现等待事件异常，建议刚接触oracle数据库的DBA，检查时一定要重点关注等待事件。

CSS initialization事件溯源

问题：巡检发现数据库Top5TimedEvents中CSS initialization事件排在第一。CSS initialization代表有进程在向CSS进行注册。但数据库是单实例，且数据库也没有使用ASM，那么为什么会出现CSS initialization？该等待事件虽然等待的次数不多，但是每次等待的时间却很长，对系统性能肯定会有影响，所以必须进行处理。

分析：首先检查了数据库的alert日志，发现日志里面没有出现相关的错误。然后找到该事件对应的sql查看具体的sql发现相关的sql都是对v$asm_diskgroup视图进行查询，因为查询针对系统视图的，怀疑可能是系统自带的job执行的。接下来检查是哪个用户在执行sql：该用户是XXX系统监控模块连接数据库使用的账号，判断是数据库监控在执行该sql。虽然该库没有使用ASM，也不是RAC环境，查询v$asm_diskgroup视图也不应该有问题啊，继续分析。手动执行sql一次耗时2分钟，检查该sql的执行计划，没有发现异常。查询metalink，Bug10024824–Database/sessionhangwith ‘CSS initialization’，版本是10.2.0.5，而我们的数据库版本也正好是这个版本。文档提示该bug只出现在RAC环境，由于OH/log//client目录权限不对导致，建议改为771。故障数据库不是RAC环境的，检查该目录权限755检查另一套环境一样的数据库，目录权限也是755，执行同样的sql，没有问题。如果按照bug来说，是权限的问题，那么client目录一定是不能被写入，所以才hang住。

我们继续检查目录和目录中的文件。查看目录client的下文件css*.log，共66667，每天生成251个文件。每次查询v$asm_diskgroup一次，就出现一个新的文件。另一套正常的数据库该目录下的文件只有168个。文件内容再次测试运行一个查询，并且用truss追踪该进程，发现了问题的根源：进程大部分的时间是花在遍历client下cssN.log文件判断在每次查询v$asm_diskgroup的时候，都会在client下生成一个新的cssN.log文件（10.2.0.5才有，其他版本没发现），生成的命名规则是前一个数字加1。因此，生成新的cssN.log文件时，需要遍历整个client目录下的cssN.log文件，才能知道最大的数字是多少，才能生成第N+1的文件。而在client下不断生成大量文件，这个和oracle的一个unpublishbug6004127有关（ID729349.1）。目前没有patch，文档上说解决的方法是用crontab定期清理client下的cssN.log、清理超过3天的日志，再次查询v$asm_diskgroup，耗时低于0.01秒。