今天客户来电，表示数据库很慢，表空间快满了。当时第一反应是不科学，因为年假之前刚检查并添加了数据文件，没有理由那么快。不管那么多，慢是一定的，看看原因先。
1.针对客户反映表空间问题，查询表空间使用率：
TABLESPACE_NAME TOTAL_G FREE_G USED_G USED_PERCENT
-------------------- ---------- ---------- ---------- ------------
USERS 463.1 4.89 458.21 98.95 --确实比较满
SYSTEM 51 18.24 32.76 64.24
UNDOTBS2 30.1 22.54 7.55 25.09
SYSAUX 31.1 23.92 7.18 23.08
UNDOTBS1 44.3 37.54 6.76 15.26
但是：
TABLESPACE_NAME TOTAL_WITHOUT_EXTEND_GB TOTAL_WITH_EXTEND_GB FREE_WITH_EXTEND_GB USED_GB USED_PERCENT_WITH_EXTEND
-------------------- ----------------------- -------------------- ------------------- ---------- ------------------------
USERS 463.1 566 107.79 458.21 80.96 --其实并不满
SYSTEM 51 64 31.24 32.76 51.19
UNDOTBS2 30.1 62 54.46 7.54 12.17
SYSAUX 31.1 64 56.82 7.18 11.22
UNDOTBS1 44.3 64 57.25 6.75 10.55
数据文件是由可扩展属性的。那么，为什么慢呢？那就查看等待事件。
2.查看等待事件
SQL> select inst_id,event,count(1) from gv$session where wait_class#<> 6 group by inst_id,event order by 1,3;
INST_ID EVENT COUNT(1)
---------- ---------------------------------------------------------------- ----------
1 db file scattered read 1
1 gcs log flush sync 1
1 gc cr request 1
1 direct path read 1
1 db file sequential read 2
1 gc current request 2
1 cursor: pin S wait on X 36
1 library cache lock 130
2 log file parallel write 1
2 db file parallel read 1
2 latch: row cache objects 1
INST_ID EVENT COUNT(1)
---------- ---------------------------------------------------------------- ----------
2 gc current request 1
2 library cache pin 1
2 gc cr request 1
2 db file scattered read 2
2 db file sequential read 3
2 cursor: pin S wait on X 39
2 library cache lock 127
18 rows selected.
等待事件中，library cache lock比较严重。1节点130,2节点也有127，不慢才怪了
赶紧开始解决问题（参考：http://blog.csdn.net/msdnchina/article/details/46493643）：
SQL> select sid,saddr from v$session where event= 'library cache lock';
SID SADDR
---------- ----------------
3 0000000E40BE1440
10 0000000E40BDE360
41 0000000E88C3F430
42 0000000E48BA2870
43 0000000E20BC1A60
80 0000000E20BD0EC0
115 0000000E88C5DCF0
146 0000000E48BD3670
147 0000000E20BF2860
184 0000000E20C01CC0
188 0000000E40C2DA20
SID SADDR
---------- ----------------
220 0000000E48BF1F30
222 0000000E28C12E58
260 0000000E30C03E68
295 0000000E20C2F9E0
296 0000000E28C31718
326 0000000E28C43C58
328 0000000E38C2AAF0
329 0000000E40C6DC80
332 0000000E20C3EE40
362 0000000E20C51380
365 0000000E38C39F50
SID SADDR
---------- ----------------
366 0000000E40C7D0E0
368 0000000E48C2F0B0
398 0000000E48C415F0
400 0000000E28C62518
401 0000000E30C440C8
405 0000000E48C3E510
406 0000000E20C5D700
437 0000000E28C71978
441 0000000E88CEA530
471 0000000E88CFCA70
476 0000000E38C67C70
SID SADDR
---------- ----------------
509 0000000E48C6F310
548 0000000E28C9F698
551 0000000E40CC96C0
581 0000000E40CDBC00
583 0000000E48C8DBD0
617 0000000E38CA7ED0
652 0000000E28CD0498
654 0000000E38CB7330
691 0000000E38CC6790
692 0000000E40D09920
693 0000000E88D584B0
SID SADDR
---------- ----------------
724 0000000E48CCDE30
725 0000000E20CED020
764 0000000E30CDFD68
765 0000000E38CE5050
766 0000000E40D281E0
796 0000000E40D3A720
797 0000000E88D892B0
799 0000000E20D0B8E0
834 0000000E88D98710
836 0000000E20D1AD40
837 0000000E28D1CA78
SID SADDR
---------- ----------------
868 0000000E30D10B68
869 0000000E38D15E50
872 0000000E48D0AFB0
902 0000000E48D1D4F0
909 0000000E48D1A410
939 0000000E48D2C950
940 0000000E20D4BB40
973 0000000E38D46C50
975 0000000E88DD8970
981 0000000E40D86D00
1015 0000000E28D6C138
SID SADDR
---------- ----------------
1017 0000000E38D52FD0
1082 0000000E28D8DAD8
1083 0000000E30D6F688
1085 0000000E40DB7B00
1155 0000000E20DAA660
1156 0000000E28DAC398
1157 0000000E30D8DF48
1196 0000000E40DE5820
1197 0000000E88E343B0
1233 0000000E40DF4C80
1265 0000000E48DB9190
SID SADDR
---------- ----------------
1266 0000000E20DD8380
1269 0000000E38DC0F50
1270 0000000E40E040E0
1297 0000000E28DEC5F8
1298 0000000E30DCE1A8
1303 0000000E20DE77E0
1334 0000000E28DFBA58
1337 0000000E40E25A80
1338 0000000E88E74610
1373 0000000E38DF1D50
1375 0000000E88E83A70
SID SADDR
---------- ----------------
1378 0000000E28E07DD8
1414 0000000E20E15500
1444 0000000E20E27A40
1445 0000000E28E29778
1449 0000000E88EA2330
1483 0000000E30E1A788
1521 0000000E38E2EED0
1551 0000000E38E41410
1585 0000000E20E67CA0
1588 0000000E38E50870
1590 0000000E88EE2590
SID SADDR
---------- ----------------
1625 0000000E38E5FCD0
1630 0000000E28E75D58
1659 0000000E20E86560
1662 0000000E38E6F130
1663 0000000E40EB22C0
1696 0000000E20E959C0
1698 0000000E30E792A8
1701 0000000E88F102B0
1730 0000000E40ED3C60
1738 0000000E88F1F710
1769 0000000E48E95090
SID SADDR
---------- ----------------
1770 0000000E20EB4280
1771 0000000E28EB5FB8
1804 0000000E40EF2520
1805 0000000E88F410B0
1838 0000000E28ED7958
1845 0000000E28ED4878
1876 0000000E30EC8968
1877 0000000E38ECDC50
1878 0000000E40F10DE0
1914 0000000E38EDD0B0
1950 0000000E30EE7228
SID SADDR
---------- ----------------
1981 0000000E38EFEA50
1984 0000000E48EF3BB0
1987 0000000E30EF6688
2019 0000000E40F51040
2020 0000000E88F9FBD0
2024 0000000E30F05AE8
2053 0000000E28F36478
2055 0000000E38F1D310
2059 0000000E20F31660
2091 0000000E30F27488
2098 0000000E30F243A8
SID SADDR
---------- ----------------
2127 0000000E28F54D38
2130 0000000E40F7ED60
2133 0000000E20F4FF20
2164 0000000E28F64198
2167 0000000E40F8E1C0
2200 0000000E20F718C0
2203 0000000E38F5A490
2204 0000000E40F9D620
2271 0000000E40FBEFC0
2276 0000000E30F73A68
142 rows selected.
随便选了一个SADDR
SQL> select kgllkhdl Handle,kgllkreq Request, kglnaobj Object from x$kgllk
2 where kgllkses = '0000000E40FBEFC0' and kgllkreq > 0;
HANDLE REQUEST OBJECT
---------------- ---------- ------------------------------------------------------------
0000000E567B8CD0 2 GEXXXXXGUIDS
查到了对象名称：GEXXXXXGUIDS
通过生成trace文件的方式查找持有的会话：
$sqlplus '/ as sysdba'
oradebug setmypid
oradebug unlimit
oradebug dump systemstate 266
查到自己的SID= 2127
select pid from v$process where addr=
(select paddr from v$session where sid= 2127 );
通过SID找到了进程id=23607
根据23607找到了trace文件
根据上面提到的文章（http://blog.csdn.net/msdnchina/article/details/46493643） ：
select pid from v$process where addr=
1. (select paddr from v$session where sid= <sid_of_hanging_session> ); --随便找了一个hang的sid，得到pid=123
在trace文件中：
Open the tracefile and do a search for "PROCESS <PID from above>".----->先定位到等待者session对应的pid （非ospid）
In the process section, search for the wait event by doing a search on 'waiting for'. ----->再用'waiting for'定位，注意'waiting for'下一行的handle address 地址，接下来会用该地址进行搜索 --假设ADD
结果发现：waiting for中没有library cache，然后再次在数据库中检查，竟然发现，所有的library cache lock均没有了！
那么，就写下接下来的步骤，以备后用：
我看上面提到的文章（http://blog.csdn.net/msdnchina/article/details/46493643），在使用handle address查找对象的时候，前面有LIBRARY OBJECT LOCK ,机制如我，果断在trace文件中查找LIBRARY OBJECT LOCK，统计竟有317处LIBRARY OBJECT LOCK（将trace文件中pid=123的记录单独取出查找）发现了很多对象。。不过，已经没有锁。
用上面的ADD查找锁定的对象OBJ
继续使用ADD找到持有mode=X的会话，找到process PPP，问下客户，杀掉。
select sid from v$session where paddr=(select addr from v$process where pid=PPP);
kill -9
