基于aix 5.3的oracle 10.2.0.2因为paing space消耗尽导致数据库及主机不可用简要分析
分析过程
1，具体分析过程：
获取oracle alert日志文件，定位问题时间点，由下可知为2015-7-23 12：22：39左右出现故障
分析上述的oracle trc文件，报错和ALERT日志文件报错一致
查阅ORACLE MOS文章579365.1，获取上述ORA-报错的原因，进程启动所需内存不足导致无法正常启动
我们再来看看aix操作系统的日志信息，可知2015-7-23 12：15：16报clstrmgrdanger，经查IBM官方手册，可知仍是与SWAP SPACE相关的错误（即其不足导致）
再尝试从$ORACLE_BASE/admin/cordysprod/bdump,想去分析2015-7-23当天出故障其它后台进程（如：m000,pmon,smon）,以期获取相关的线索，经李琦确认，没有相关日志文件
再从主机相关内存配置来分析，VMO虚拟内存配置相关，经对比ORACLE ALERT日志，2015-7-23之前并未出现过内存消尽情况，所以基本可以
排除是VMO
相关配置不当引发（其相关参数如下：
maxclient%
maxperm%
minperm% ）
分析至此，最重要就是要知道内存到底被哪些进程消耗了，即到底是ORACLE还是操作系统其它进程，但由于缺少：
NMON性能监控数据
ORACLE出问题前后的AWR性能数据
故我司无法进一步分析导致内存消耗用尽的原因
怀疑问题原因
2.1，可能是因为紧急上线功能引发，主要可能是因为SQL引发
2.2, AIX 5.3的BUG或PATCH应用不全，在MOS找到如下文章 1322967.1(但注意：此文数据库版本为11.2.0.1之后，而我们的数据库却是10.2.0.2）：
文章相关内容如下：
本文章给出解决方案：
1,增加操作系统交换空间
2，应用AIX PATCH 1Z19670
（这个还需要主机的同事再确认下）
给出的建议
3.1，出现故障，建议请ORACLE专业人员马上介入处理，最好不要延期，以免诸多故障数据无法及时复现分析
3.2，强烈建议开启配置nmon，便于全方位诊断分析数据库及操作系统相关的性能故障
或者配置oracle oswatcher（类似于nmon功能）
3.3，启用awr采样功能，强烈建议至少保存1个月的AWR历史数据，便于出现相关问题分析原因
最后真诚感谢各位相关人员的协作与配合，谢谢大家，请指正！
个人简介
项目经验:
中国联通4G数据库性能分析与优化
贵州移动crm及客服数据库性能优化项目
贵州移动crm及客服务数据库sql审核项目
深圳穆迪软件有限公司数据库性能优化项目
联系方式：
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/9240380/viewspace-1770742/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- redhat要持续学习哟加加油
- 升级redhat 6.8 默认gdb 7.2到gdb 8.3.1操作指南
- redhat 6.8升级默认cmake 2.8到cmake 3.9
- mysql source code源代安装的前提条件requirement
- mysql handler语句之一
- mysql show open tables相关知识体系之一
- mysql snapshot read快照读及current read当前读与锁lock之一
- mysql 5.7 _rowid虚列之一
- mysql innodb lock锁之record lock之一
- mysql隐式提交事务transaction一点笔记
