was+oracle+挂起,Oracle技巧:诊断数据库挂起(HANG) 事件

1) 使用以下命令生成 HANGANALYZE 追踪文件 ==>

was+oracle+挂起,Oracle技巧:诊断数据库挂起(HANG) 事件_第1张图片

使用以下语法在执行 RAC 级 HANGANALYZE:

94161_1480382108.png

2) 在运行 Hanganalyze 之后,登入一个新 SQL 会话来生成系统状态转储(dump)文件==>

was+oracle+挂起,Oracle技巧:诊断数据库挂起(HANG) 事件_第2张图片

Level 266和267包含了一些堆信息。 Level 266是对单实例的信息转储, 而Level 267则是对 RAC 系统 systemstate 转储。

**Note: 我们同样可以通过使用Hang File Generator (HANGFG) 工具来完成以上

1)和 2)中使用 hanganalyze 和 systemstate 收集信息的操作。HANGFG 工具提供了一系列 UNIX shell 脚本命令来自动化收集和生成 hanganalyze 和 sysemstate 追踪文件。 在使用 HANGFG 生成并收集追踪文件时需要考虑到需要在已处于性能退化的系统中进行诊断的影响。由于影响级别作为此工具参数被传给 HANGFG, 所以用户需要做出决定, 在启用此工具时,何种级别的影响是可接受的。当用户选择轻度影响或中等影响(选项 1 或 2)作为参数时, HANGFG 工具同样有能力做出调整以适应用户做出的决定。HANGFG 是 RAC 自识别的,并且能在 RAC 和非 RAC环境中运行。

3) 当 hang 事件发生后, 获取到的 Statspack 或 AWR/ASH(10g/11g)报告是否具有时效性取决于做 Statspack 快照频繁程度。 举个例子, 如果你每隔 1 小时做一次快照,在下一次快照前发生了 5 分钟的数据库挂起事件。那么快照由于显得时间跨度太长而很难用于分析当时 5 分钟发生的情况。

有时在尝试连接数据库时,你的调试会话也会挂起在那里。这时留给你 3 种可选方法==>

1) 找一个之前已连上的可用会话。

2) 如果你正在使用 10g/11g,那么你可以使用-prelim 选项来登录数据库:

94161_1480382201.png

3) 使用操作系统调试器来查看运行进程

获取服务器oracle先关影子进程ID (请注意并非oracle后台进程,调试后台进程可能导致数据库奔溃)…”ps –ef | grep ora”

使用当前系统级调试器(如 dbx, adb, gdb 等)来获取 systemstate:$ gdb $ORACLE_HOME/bin/oracle (gdb) print ksudss(267)

括号中的数字(267)是你希望转储 systemstate 的级别.

对于 RAC 挂起事件请看“RAC 性能”部分中对于 racdiag 脚本的使用

通过以下 systemstate 命令可在同一时点转储所有 RAC 节点状态:

SQL> oradebug -g all dump systemstate 267

总结,你可以上传以下文件:

Hanganalyze 输出

Systemstate 转储(dumps)

hangfiles.out (如果使用 HANGFG 工具命令)

alert.log

在一个很短时间内的 Statspack/AWR/ASH 报告

可用的系统调试监控输出

你可能感兴趣的:(was+oracle+挂起)