如题.
图:
rh8dseHU.jpg (32.37 KB, 下载次数: 261)
解决oracle问题的思路
2013-3-6 18:59 上传
遇到这个问题,是否尝试了什么解决办法?
结果如何?
李邦勇(387912995) 9:58:56
你切换日志后再看看呢
姚欣(1207788790) 9:59:25
我切了,但直接就挂起了.
好,切换就挂起了,那么怎么办呢?
到底挂在哪里了,如果有oracle的原程序就好了,实际情况是我们不可能获得oracle的原程序,但oracle提供了报警日志文件,为我们找到问题提供了觉得问题的突破口
.
因此,我们遇到这些问题,首先查看报警日志的内容.
在11g中,报警日志文件,默认在 $ORACLE_BASE/diag/rdbms/db_unique_name/sid/trace/alert_sid.log,
在11g以前,在 $ORACLE_BASE/admin/sid/bdump/alert_sid.log.
当前问题,版本为11.2.0.3,因此日志文件在 $ORACLE_BASE/diag/rdbms/db_unique_name/sid/trace/alert_sid.log
也可以查看 show parameter background_dump_dest;
73T8jRsZ.jpg (49.77 KB, 下载次数: 252) 解决oracle问题的思路 2013-3-6 19:12 上传 可以看出,数据库名字为sztech 查看这个日志文件的内容,可以使用more,cat,vi,tail 等工具. 由于当前切换就挂起,可以只需要看最后几行日志信息即可,最快的方法为: tail -f $ORACLE_BASE/diag/rdbms/sztech/sztech/trace/alert_sztech.log 只要一切换,就有消息出来.
okw3BxCG.jpg (100.1 KB, 下载次数: 323) 解决oracle问题的思路 2013-3-6 19:17 上传
cusUUgfc.jpg (29.49 KB, 下载次数: 313) 解决oracle问题的思路 2013-3-6 19:19 上传 可以看出,是归档目的地无法创建文件所导致, 归档目的地是哪里呢? 根据上图,我们可以看到在 /oracle/app/ 那么这个目录是否空间满了,还是权限不对,还是不存在这个目录?
brvaAUyJ.jpg (18.78 KB, 下载次数: 235) 解决oracle问题的思路 2013-3-6 19:22 上传 可以看出,空间是有的.
F8uu0uKb.jpg (17.23 KB, 下载次数: 240) 解决oracle问题的思路 2013-3-6 19:24 上传 看到 /oracle/app 的所有者为grid:dba ,而且权限为: rwxr-xr-x ,因此,oracle用户无法写,就会出现这个问题. 到此,问题已经很明了了,就是归档日志目录权限不够导致,直接修改归档日志的位置,问题能够得到解决: 这个问题的关键,就是要根据问题现象,依据oracle提供的报警文件,进行问题的解决. 不错 当时看到这个情况 我第一反映是 存储爆仓 看聊天记录 郑老师的权限建议之后 排除oracle内用户权限问题 再来检查日志文件 结果检查出是操作系统权限和文件夹的属主问题 经常遇见这种类似的情况 对于有经验的来说 一般是喜欢先入为主 往往认为是因为这样 结果却不是这样 所以 我的体会是:要养成查看日志文件的习惯 掌握查看日志文件的方法和技巧
作者: 郑全 时间: 2013-3-6 19:16
标题: 查看方法
作者: 郑全 时间: 2013-3-6 19:17
作者: 郑全 时间: 2013-3-6 19:20
作者: 郑全 时间: 2013-3-6 19:22
作者: 郑全 时间: 2013-3-6 19:23
作者: 郑全 时间: 2013-3-6 19:25
作者: 郑全 时间: 2013-3-6 19:28
作者: 杨芳超 时间: 2013-3-6 19:39
作者: mars 时间: 2013-4-9 22:37
很不错,看了收益
欢迎光临 重庆思庄Oracle、Redhat认证学习论坛 (http://bbs.cqsztech.com/)
Powered by Discuz! X3.2