一、数据库Hang时可能的现象
1、 最直观的是你的大部分的业务操作,比如说一个查询都使用好长的时间,或根本就返回不出结果。这和简单那种锁表是有区别的。
2、在操作系统上用 Hp-unix用glance、Aix用nmon及用sar做监测会出现系统空闲的假象,表面看起来系统很闲,实际上系统已经Hang了。
3、 查v$session_wait会出现大量的”latch free”、”enqueue”、” free buffer waits”等等待事件,有时 后台会出现大量的.trc文件,另外需要观注一下$ORACLE_HOME/rdbms/log这个位置,有一些时侯trace文件会生成到这里。
二、 Oracle库Hang时一些有用的操作和查询
1、如果要寻求Oracle的技术支持,我们需要dump一下Oracle的 systemstate,操作如下
SQL>conn / as sysdba;
SQL> alter session set events ’immediate trace name SYSTEMSTATE level 10’;
需要等几分钟的时间,这时在init.ora中所设置的user_dump_dest所标识的位置就可以找到这 个.trc文件,一般比较大。
2、捕获一些视图的状态值
SQL>conn / as sysdba;
SQL>set linesize 500
SQL>set pagesize 0
SQL>spool v_views.txt
SQL> SELECT * FROM v$parameter;
SQL>SELECT class, value, name FROM v$sysstat;
SQL> SELECT sid, id1, id2, type, lmode, request FROM v$lock;
SQL>SELECT l.latch#, n.name, h.pid, l.gets, l.misses, l.immediate_gets, l.immediate_misses, l.sleeps FROM v$latchname n, v$latchholder h, v$latch l WHERE l.latch# = n.latch# AND l.addr = h.laddr(+);
SQL> SELECT * FROM v$session_wait ORDER BY sid; -- 隔几秒重复执行3次。
SQL>spool off
3、有条件的话用statspack生成了一个Report, 如果你对statspach不熟悉,可以参照http://www.itpub.net/showthread.php?s=& threadid=144448这个链接。 也可以从附件中下载
三、产生Hang可能的几个原因
1、开归档的情况下,归档位置所在的文 件系统满了,这时lgwr就会等待归档进程的完成,DML写不了日志,都处于等待的状态。
2、在HP的系统开异步Io时,没为dba的组设置 MLOCK权限。正常来说Oracle的启动是会报错的,可是有些时侯比如Oracle8.1.6的版本就不报错启动,但是此时的异步Io是有问题的,仔 细查看你会在$ORACLE_HOME/rdbms/log看到大量的.trc文件。这种情形引的Hang我遇到过。
3、由于异常进程引起的, 我所说的是那些占用系统资源(cpu,memory)特别大的进程,这些进程一般占用cpu会达到90%以上,相对其它的进程比较突出。可以通过hp- unix的glance、topas,IBM的nmod,topas,ps等工具进行监测。
4、由于主机系统、阵列的某方面的瓶颈引起的,在实 际中最普遍的应该是Io的问题,比如IO方面有瓶颈,则dbwr、lgwr就会 引” free buffer waits”、” log buffer space”等一系列的等待事件,此时是性能的问题,感觉起来像Hang。
5、 也有bug的因素,我的库都是最新的补丁,这方面的问题还没遇到过。
四、几点处理建议
当得到Oracle的库奇慢或Hang时保持冷静的头脑很重要的,可以按如下的方法进行一些处理:
1、 首先要到操作系统上去,用glance等工具进行一下观察,看一下cpu、内存、交换区、磁盘的繁忙程度与平时是不是相似的, 同时看一看有没有占系统资源特别大的进程,有些时侯是这些进程引起的,通过 v$process和v$session两个视图找到这Oracle进程的sid,serial#,把它用 Alter system kill session ‘sid,serial#’;杀 掉就行了。如果平时同样的时段你的磁盘的繁忙程度是95%,而些时它为20%,当然是假设了,说明Oracle的库没准真的hang了。
2、时 间来得及的话执行一下”二”中的语句是很必要的,这样可以把这些信息提交给Oracle的supporter,让你们给你分析一下,查一下原因。
3、 如果你的库开归档了,出现Hang的时侯一定要看一下归档日志的文件系统是不是满了,做一个完备一些的网管系统是很必要的。
4、在HP系统上打 开异步IO时一定不要忘记为dba这个组加上MLOCK的权限,我就吃过这个亏。
5、时常的观注一下v$session_wait或用 statspack进行观注一下等待事件,一般IO相关的事件较多,为Oracle打开异步IO、多加几个写进程及为Oracle数据文件所用的 raw device使用条带都是很必要的。与应用的开发商交流也很重要,没准最近新上的一个应用就特耗IO或特占CPU资源。
6、尽量要使用 比较稳定的Oracle的版本,比如Oracle8.1.7.4及Oracel9.2.0.4(最新为 9.2.0.5)都很稳定的,可以少去好多的麻 烦。
轉自於:http://dolphin-ygj.广告.com/category/52874?page=3&show_full=true
1、 最直观的是你的大部分的业务操作,比如说一个查询都使用好长的时间,或根本就返回不出结果。这和简单那种锁表是有区别的。
2、在操作系统上用 Hp-unix用glance、Aix用nmon及用sar做监测会出现系统空闲的假象,表面看起来系统很闲,实际上系统已经Hang了。
3、 查v$session_wait会出现大量的”latch free”、”enqueue”、” free buffer waits”等等待事件,有时 后台会出现大量的.trc文件,另外需要观注一下$ORACLE_HOME/rdbms/log这个位置,有一些时侯trace文件会生成到这里。
二、 Oracle库Hang时一些有用的操作和查询
1、如果要寻求Oracle的技术支持,我们需要dump一下Oracle的 systemstate,操作如下
SQL>conn / as sysdba;
SQL> alter session set events ’immediate trace name SYSTEMSTATE level 10’;
需要等几分钟的时间,这时在init.ora中所设置的user_dump_dest所标识的位置就可以找到这 个.trc文件,一般比较大。
2、捕获一些视图的状态值
SQL>conn / as sysdba;
SQL>set linesize 500
SQL>set pagesize 0
SQL>spool v_views.txt
SQL> SELECT * FROM v$parameter;
SQL>SELECT class, value, name FROM v$sysstat;
SQL> SELECT sid, id1, id2, type, lmode, request FROM v$lock;
SQL>SELECT l.latch#, n.name, h.pid, l.gets, l.misses, l.immediate_gets, l.immediate_misses, l.sleeps FROM v$latchname n, v$latchholder h, v$latch l WHERE l.latch# = n.latch# AND l.addr = h.laddr(+);
SQL> SELECT * FROM v$session_wait ORDER BY sid; -- 隔几秒重复执行3次。
SQL>spool off
3、有条件的话用statspack生成了一个Report, 如果你对statspach不熟悉,可以参照http://www.itpub.net/showthread.php?s=& threadid=144448这个链接。 也可以从附件中下载
三、产生Hang可能的几个原因
1、开归档的情况下,归档位置所在的文 件系统满了,这时lgwr就会等待归档进程的完成,DML写不了日志,都处于等待的状态。
2、在HP的系统开异步Io时,没为dba的组设置 MLOCK权限。正常来说Oracle的启动是会报错的,可是有些时侯比如Oracle8.1.6的版本就不报错启动,但是此时的异步Io是有问题的,仔 细查看你会在$ORACLE_HOME/rdbms/log看到大量的.trc文件。这种情形引的Hang我遇到过。
3、由于异常进程引起的, 我所说的是那些占用系统资源(cpu,memory)特别大的进程,这些进程一般占用cpu会达到90%以上,相对其它的进程比较突出。可以通过hp- unix的glance、topas,IBM的nmod,topas,ps等工具进行监测。
4、由于主机系统、阵列的某方面的瓶颈引起的,在实 际中最普遍的应该是Io的问题,比如IO方面有瓶颈,则dbwr、lgwr就会 引” free buffer waits”、” log buffer space”等一系列的等待事件,此时是性能的问题,感觉起来像Hang。
5、 也有bug的因素,我的库都是最新的补丁,这方面的问题还没遇到过。
四、几点处理建议
当得到Oracle的库奇慢或Hang时保持冷静的头脑很重要的,可以按如下的方法进行一些处理:
1、 首先要到操作系统上去,用glance等工具进行一下观察,看一下cpu、内存、交换区、磁盘的繁忙程度与平时是不是相似的, 同时看一看有没有占系统资源特别大的进程,有些时侯是这些进程引起的,通过 v$process和v$session两个视图找到这Oracle进程的sid,serial#,把它用 Alter system kill session ‘sid,serial#’;杀 掉就行了。如果平时同样的时段你的磁盘的繁忙程度是95%,而些时它为20%,当然是假设了,说明Oracle的库没准真的hang了。
2、时 间来得及的话执行一下”二”中的语句是很必要的,这样可以把这些信息提交给Oracle的supporter,让你们给你分析一下,查一下原因。
3、 如果你的库开归档了,出现Hang的时侯一定要看一下归档日志的文件系统是不是满了,做一个完备一些的网管系统是很必要的。
4、在HP系统上打 开异步IO时一定不要忘记为dba这个组加上MLOCK的权限,我就吃过这个亏。
5、时常的观注一下v$session_wait或用 statspack进行观注一下等待事件,一般IO相关的事件较多,为Oracle打开异步IO、多加几个写进程及为Oracle数据文件所用的 raw device使用条带都是很必要的。与应用的开发商交流也很重要,没准最近新上的一个应用就特耗IO或特占CPU资源。
6、尽量要使用 比较稳定的Oracle的版本,比如Oracle8.1.7.4及Oracel9.2.0.4(最新为 9.2.0.5)都很稳定的,可以少去好多的麻 烦。
轉自於:http://dolphin-ygj.广告.com/category/52874?page=3&show_full=true
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/673037/viewspace-662733/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/673037/viewspace-662733/