ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 处理EXP导出HANG住问题一例

处理EXP导出HANG住问题一例

原创 Linux操作系统 作者:嘉迷 时间:2012-05-24 10:38:42 0 删除 编辑

论坛求助

    上周CD渠道的ZSL联系我,让我看一下他在论坛上发了一个求助帖《oracle11.2.1全库导出不能使用,告知我这是工作中实际遇到的问题,由于这个原因,用户的数据已经几天没有备份了,用户的数据安全无法得到保障,希望我能协助帮忙处理,由于电话指导比较麻烦,用户又有远程环境,于是我提议进行远程处理。

问题重现

    远程桌面连接到用户处,首先得看一下问题现象,做了一个全库的逻辑备份,确实如其描述的一样,当逻辑备份执行到如下图所示的位置,就一直Hang在那里,几分钟都没有动弹,导致全库备份无法成功。

    通过现象,我们可以分析这是一个典型的资源等待导致,因此我们需要先从ORACLE的等待事件中查找导致问题的原因。

思路分析

    首先肯定是要找到该逻辑导出的会话,通过查询V$SESSION视图,指定program字段为‘exp.exe’执行文件查找,得到结果如下图:

    通过查询的结果,发现居然有2条记录,不过状态不同,sid为148的记录状态是KILLED,sid为213的记录状态为ACTIVE,询问现场工程师,得知148是其几天前执行逻辑备份时,由于有其他操作,技术人员手工直接杀掉会话导致,但是在视图中,其一直保持KILLED状态,而sid为213这个会话是当前执行的逻辑备份会话。经过观察,确实如其所说,接下来我们就需要重点分析下sid为213这个会话,为什么其会hang住,我们需要查下他目前是在等待什么操作,这个我们可以通过查询v$session_wait会话查看,查询下sid为213的会话目前的等待事件为什么,结果如图:

    这里我们看到了一个等待事件‘library cache lock’,那么什么情况下会出现library cache lock,这里我们首先要了解什么是Library Cache。

    Library Cache是Oracle SGA 中Shared pool 的组成部分,它几乎是Oracle内存结构中最复杂的一部分,主要存放shared curosr(SQL)和PLSQL对象(function,procedure,trigger)的信息,以及这些对象所依赖的table,index,view等对象的信息,Library cache主要解决这些对象的三个问题:1.快速定位,2.关系依赖,3.并发控制,其中并发控制就会涉及到library cache lock,当会话访问对象时,首先必须获取lock,然后将访问的数据pin在内存中。lock的作用是控制进程间的并发访问,而pin的作用是保证数据一致性,防止数据在访问时被交换出去,了解到了这个情况,我们就需要查询到是那个会话把该逻辑备份的会话堵塞,只要找到这个堵塞会话,然后加以解决,相信该Hang的问题就能够随之解决。

解决过程

    如前面提到的,首先是找到什么会话导致library cache lock ,这里我们需要用到metalink的一篇文章《How to Find which Session is Holding a Particular Library Cache Lock [ID 122793.1]》,该文详细介绍了如何找到导致holding的会话,大意是说要使用的到oracle的x$内部表,有兴趣的同学可以自己查看下该文章,我这里直接引用。

    x$表是oracle的内部核心表,只有sys用户连接数据库才能访问,通过下面的一段SQL查出堵塞会话。

    这里我眼前一亮,SID为148的会话,不正事前面我们查询出来状态为KILLED的会话吗?看来已经确定是该会话导致后续的exp堵塞,那既然已经杀掉的会话,为什么还会堵塞呢?这里我们有必要说明下oracle的kill会话的操作。

   在Oracle数据库中,可以通过kill session的方式来终止一个进程,语法为:

alter system kill session 'sid,serial# ',但是alter system kill session只是将session标记为可以回收,切断会话与Server Process的映射关系。但没有进行资源释放回收工作,一旦尝试连接,PMON会主动开始清理被kill的会话,同时Oracle拒绝连接操作,Server Process是一个忠实于客户端的进程,只要客户端还在启动,维持着两个之间的联系。Server Process是不会被回收的。直到客户端主动停止与Server Process的通信,Server Process才释放资源。如何才能彻底释放资源呢?其实我们只要在操作系统层面上,结束该会话的进程就行了,首先要找到进程号,由于被置于KILLED状态的会话,该session的paddr被修改,因此无法通过v$session和v$process关联来获得spid,但是可以通过下面的SQL语句,来进行查找:

    知道了会话的spid后,就可以通过orakill工具直接在操作系统命令模式下,结束掉该会话。

    C:\>orakill orcl 1639

    Kill of thread id 1639 in instance orcl successfully signalled

    C:\>

    然后再查询v$session,可以看见killed状态的会话已经消失了,堵塞会话已经彻底清除,orakill是oracle提供的windows平台下强制结束oracle进程的工具,这方面的知识有兴趣的同学查看metalink文档《ALTER SYSTEM KILL SESSION does not Release Locks Killing a Thread on Windows NT [ID 100859.1]》,接着就赶快再试试exp导出是否还会Hang住。

验证问题

    立即执行下exp导出,验证下问题是否已经得到解决,正常情况下,在导出系统对象和过程时也会停顿一段时间,这个时候,查询下v$session_wait视图,可以看到等待事件为SQL*Net message from client如下图:

    SQL*Net message from client属于空闲等待,如图,等待类型属于IDLE,已经不再是Library Cache Lock,一般情况下可以不用理会,属于正常的等待事件。过了大概半分钟,开始看到数据表的导出,此致问题得到圆满的解决。

后续总结

    通过本文的介绍,我们不光晓得本例中问题的解决方法,还应该基本了解到处理ORACLE一般Hang住问题的基本思路:

1.首先确定Hang住会话的等待事件。。

2.然后分析该等待事件,找到引起该等待的原因,是由于锁,还是由于资源繁忙?

3.最后根据其产生的原因,排除问题,一般都能够解决问题。

     希望本例的介绍对大家在以后处理类似业务有所帮助。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/182736/viewspace-730794/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2008-08-12

  • 博文量
    3
  • 访问量
    19265