本文记录了一次解决数据库Hang住的问题，主要原因是日志切换频繁导致脏块无法及时写入数据文件。通过增加redo日志文件数量及大小，降低了日志切换频率，解决了问题。
解决项目数据库问题，记录如下：
问题原因：
总的来说这个数据问题主要是日志切换频繁导致脏块来不及写入数据文件，以至于数据库hang住；
问题解决：
将redo文件增加到8组，新增加的3组每组500M大小，降低日志文件的切换频率，为LGWn和DBWn争取时间；
解决过程：
按照以往的经验，数据库慢，可能是某种操作导致一些等待事件，所以先做AWR报告，但是发现所有的快照都没有，首先想到重启
过数据库，但是经询问和查找数据库运行时间并没有，使用EM发现也不能正常使用，所以怀疑是SYSAUX表空间的问题，经查看
SYSAUX表空间的大小为32G（默认不超过2G），使用率为100%，alert文件中报不能扩展的问题（由于SYSAUX单个数据文件不能
超过32G限制，所以报这种问题），通select occupant_name, occupant_desc, schema_name, space_usage_kbytes / 1024
from v$sysaux_occupants order by 4 desc;查看到SM/OPTSTAT（统计信息收集信息）竟然使用了29G之多（应该是执行了全库
的统计信息收集才会这么多），统计信息默认保留31天，快照保留7天，所以没有快照的问题在这里可以解释了（6月初就有SYSAUX不
能扩展的问题），此时也看到了alert文件中有好多的checkpoint not complete，但是由于之前加了两组日志每组为100M，所以没有
往这方面想，受思维定式的影响，觉得是SYSAUX表空间占满，导致某个组件不能正常使用所致，将31个组件研究了一遍，并没有发现
有什么组件能导致这种问题，又从新思考回到了checkpoint not complete问题，粗略的计算了下，数据库大约每分钟有7次日志切
换，一个日志51M，那么一天的日志总量为24*60*7*51/1024=502Gb的日志量，查看了官方文档，官方建议日志的切换为30分钟
一次，所以加了3组500M的日志组，经观察alert中基本没有checkpoint not complete提示，此问题基本解决，同时添加了一个
SYSAUX数据文件，解决了快照的问题；
解决过程中用到的语句：
--查看统计信息保存时间：
select dbms_stats.get_stats_history_retention from dual;
--修改统计信息保存时间：
execute dbms_stats.alter_stats_history_retention(15);
--查看统计信息能恢复到那个时间点：
select dbms_stats.get_stats_history_availability from dual;
扫一扫
553
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
