数据库慢之Library cache lock
2016-02-15 21:37
399 查看
今天客户来电,表示数据库很慢,表空间快满了。当时第一反应是不科学,因为年假之前刚检查并添加了数据文件,没有理由那么快。不管那么多,慢是一定的,看看原因先。 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
相关文章推荐
- postgresql 帐号密码修改方法
- Mysql中组合的insert和update语句
- MySQL中的级联约束
- MySQL将查询结果输出都爱服务器文件中
- MySQL、SQLServer、Oracle中约束和索引的关系
- MySQL-SQL Server、Oracle中的索引维护方式
- sqlserver、oracle、mysql 锁类型
- sql进阶:case表达式的两种类型
- 【高可用HA】Centos7.0下通过Corosync+pacemaker+pcs+drbd实现mariadb的高可用
- oracle字符串函数
- ORACLE系统表总结
- MYSQL优化
- Oracle SP2-0640
- SQL Server 数据变更时间戳(timestamp)在复制中的运用
- sqlite 终端输入指令
- 关于SQLSERVER的全文目录跟全文索引的区别
- 一条sql语句分别统计出来两张表的数据
- linux下redis安装
- 文件服务器和数据库服务器的区别
- mysql 备份与还原