高级trouble shooting 不能logon to database alex

Jonathan Lewis 曾经提到过x$KMPSP 这个表不可轻易查询 因为这里面记录了所有shared pool 的chunk 当你进行查询时  会latch所有的shared pool 结构。

 

于是我想只查询10条应该不会有问题吧？于是我写了一个select * ffrom x$KMPSP where rownum<10

 

结果半天都没有反应，这时我意识到可能出问题了。当我尝试使用另一个SQLPLUS 登陆的时候发现SQL PLUS hang在了那里。

 

我想肯定是当SESSION登陆的时候一些shared pool 分配的动作被锁住了。看来我只能从OS level kill 掉自己的session才能登陆，可是如果这是一个很繁重的系统 ，我怎么知道哪些是我的session？

首先top一下 查看哪些进程消耗的CPU最高，其中有3条进程占了CPU 的100%

但是从用户名来看其中两个用户是用来跑一些后台JOB 的，那么看起来省下的进程应该就是我的进程了 可是该如何判定呢？

Pstack.

 

$ pstack 26136

000000010301f6c0 kghsrch

0000000103021f20 kghprmalo

 0000000103024804 kghalp

 0000000100bb78a4 ksmspc

 000000010303564c kghscn

0000000103034750 kghnwscn

 0000000100bb7a44 ksmshp

 00000001024e67a8 qerfxFetch

00000001024e7edc qercoFetch

 0000000101aa6f24 opifch2

0000000101a4c694 kpoal8

 00000001002d0058 opiodr

 0000000102cded94 ttcpip

 00000001002cd3e8 opitsk

 0000000101aaf564 opiino

 00000001002d0058 opiodr

 00000001002cc174 opidrv

 00000001002c9828 sou2o

 00000001002a7b34 main

 00000001002a7a7c _start

Kghscn     是指 kernel generic heap scan

qercoFetch 是指count fetch

qerfxFetch 是指 query fixed table fetch

 

这个很可能就是我的进程了

 

但是为什么会产生count fetch ？请看这条SQL的execution plan。

 

SQL> select * from x$ksmsp where rownum <=1;

 

ADDR           INDX    INST_ID   KSMCHIDX   KSMCHDUR KSMCHCOM

-------- ---------- ---------- ---------- ---------- ---------------

04AA0A00          0          1          1          1 free memory

 

SQL> @x

 

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------

 

--------------------------------------------------------------------

| Id  | Operation            |  Name       | Rows  | Bytes | Cost  |

--------------------------------------------------------------------

|   0 | SELECT STATEMENT     |             |       |       |       |

|*  1 |  COUNT STOPKEY       |             |       |       |       |

|   2 |   FIXED TABLE FULL   | X$KSMSP     |       |       |       |

--------------------------------------------------------------------

 

Predicate Information (identified by operation id):

---------------------------------------------------

 

   1 - filter(ROWNUM<=1)

看来qercoFetch  这个函数似乎并不会在qerfxFetch fetch到10行后停止.

 

看来似乎kill掉这个进程 我的问题就可以结束了 

但是先让我们来看看我的另一个SQL/PLUS 在做什么吧？

我检查到一个进程的登录时间跟我SQL/PLUS 登录的时间差不多

$ pstack 4848

 

ffffffff7c9a5288 semsys

 0000000102f782c8 sskgpwwait

 0000000100af4b74 kslges

 0000000102d70ea0 kglhdgn

 0000000102d58974 kglget

 000000010128f454 kkttrex

 000000010128e6c8 kktexeevt0

 0000000101a77b60 kpolon

 

Kpolon 是关于session logon 分配相关信息的

Kkt 开头的关于fire logon后的trigger (audit 之类的东西？)

Kglget 是用来分配library cache object的 如果没分配到 那么 library cache miss +1 并且会call kglhdgn

Kglhdgn create new library cache  handle

Kslges get latch function

Sskgpwwait   是OS depend oracle function 用来允许进程等待ORACLE wait event的

Semsys       是用来等待信号量通知他从sleep 转为weekup 的

 

 

 

接下来 kill掉 之前的process 整个问题 得已解决。

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

转载于:http://blog.itpub.net/21818314/viewspace-693212/