SQLLOADER不装数情况分析

阅读更多

其实这一篇文章最核心的东西都是项目组的忠哥写的，他已经飞往新疆项目组了。我当一次"小偷"，把他写的一篇分析文章记录下来，以被自己忘记了

sqlloader 不装数情况说明：
1)现象：CCB_COGNOS_COMP_DV表的数据不能装载，在任务管理器里面看到sqlloader进程，但是CPU运行时间一直为0！

2)原因分析：按照现象估计sqlloader 是在等待什么资源，而资源一直未得到，因此sqlloader一直不装数！

3)解决思路：

a) 首先查看锁的情况，看是不是表被锁起，不能装数
查询： SELECT A.OWNER,
       A.OBJECT_NAME,
       B.XIDUSN,
       B.XIDSLOT,
       B.XIDSQN,
       B.SESSION_ID,
       B.ORACLE_USERNAME,
       B.OS_USER_NAME,
       B.PROCESS,
       B.LOCKED_MODE,
       C.MACHINE,
       C.STATUS,
       C.SERVER,
       C.SID,
       C.SERIAL#,
       C.PROGRAM
  FROM ALL_OBJECTS A, V$LOCKED_OBJECT B, v$SESSION C
WHERE (A.OBJECT_ID = B.OBJECT_ID)
      --  AND (B.PROCESS = C.PROCESS)
   and b.SESSION_ID = c.SID
ORDER BY 1, 2
          解锁： alter system kill session 'sid, serial#'
        经过确定，不是表被锁起导致的等待，再分析其他原因。


      b)查询等待事件：
select SID,SEQ#,EVENT,p3 from v$session_wait  
where event not like 'rdbms%'
and  event not like 'SQL*N%'
and  event not like '%timer'
发现里面有很多library cache lock等待事件，需要确认下!

  以SYS用户运行
select Distinct w1.sid waiting_session,
h1.sid holding_session,
od.to_name object_name,
w.kgllktype lock_or_pin,
od.to_owner object_owner,
oc.Type,
decode(h.kgllkmod, 0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
'Unknown') mode_held,
decode(w.kgllkreq, 0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
'Unknown') mode_requested,
xw.KGLNAOBJ wait_sql,xh.KGLNAOBJ hold_sql
from dba_kgllock w, dba_kgllock h, v$session w1,
v$session h1,v$object_dependency od,V$DB_OBJECT_CACHE oc,x$kgllk xw,x$kgllk xh
where
(((h.kgllkmod != 0) and (h.kgllkmod != 1)
and ((h.kgllkreq = 0) or (h.kgllkreq = 1)))
and
(((w.kgllkmod = 0) or (w.kgllkmod= 1))
and ((w.kgllkreq != 0) and (w.kgllkreq != 1))))
and w.kgllktype = h.kgllktype
and w.kgllkhdl = h.kgllkhdl
and w.kgllkuse = w1.saddr
and h.kgllkuse = h1.saddr
And od.to_address = w.kgllkhdl
And od.to_name=oc.Name
And od.to_owner=oc.owner
And w1.sid=xw.KGLLKSNM
And h1.sid=xh.KGLLKSNM
And (w1.SQL_ADDRESS=xw.KGLHDPAR And w1.SQL_HASH_VALUE=xw.KGLNAHSH)
And (h1.SQL_ADDRESS=xh.KGLHDPAR And h1.SQL_HASH_VALUE=xh.KGLNAHSH)

主要根据w1.sid waiting_session(等待的SID),
        zh1.sid holding_session(造成等待的SID),xw.KGLNAOBJ wait_sql(等待执行的SQL),xh.KGLNAOBJ hold_sql(造成等待的SQL) 
这几个字段确定，谁在等待，在等待什么，是什么造成等待.

举例:查询发现：正在等待执行truncate table CCB_COGNOS_COMP_DV;这是SQLLOADER全量装数的第一步；造成等待的是一个COGNOS查询。
    现在原因已经明确：是cognos的一个查询导致了library cache lock,不能正常装数。

       C)杀掉导致library cache lock的SESSION
                select  sid,serial#  from v$session where sid=造成等待的SID;
         然后执行: alter system kill session 'sid, serial#'

            这时候观察sqlloader开始装数是否开始正常运行,如果观察一小段时间后,该表对应的sqldr进程占用的CPU时间如果还是为0:00:00的话(或者经过许久还一直在显示装数进行中,没有其他反应),
         就执行下一步动作(d)      
     
       d)杀掉进程步骤：
         查询进程ID:
        SELECT a.username,c.spid AS os_process_id,c.pid AS oracle_process_id FROM v$session a,v$process c
                   WHERE  c.addr=a.paddr and a.sid=?  and a.serial#=?;

        orakill instance_name spid;(instance_name 换成实例，spid为进程号)

        e)观察sqlloader装数正常开始