Oracle数据库大量library cache: mutex X及latch: shared pool问题排查一例
Posted lYong90
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Oracle数据库大量library cache: mutex X及latch: shared pool问题排查一例相关的知识，希望对你有一定的参考价值。
业务系统数据库夯住，数据库内大量的library cache: mutex X及latch: shared pool等待，alert日志信息如下
Tue Sep 26 22:10:04 2017 WARNING: inbound connection timed out (ORA-3136) Tue Sep 26 22:10:04 2017 WARNING: inbound connection timed out (ORA-3136) Tue Sep 26 22:10:04 2017 WARNING: inbound connection timed out (ORA-3136) Tue Sep 26 22:10:04 2017 WARNING: inbound connection timed out (ORA-3136)
数据库历史session统计如下
201709262207 352 latch: shared pool 180 201709262207 library cache: mutex X 60 201709262207 476 library cache: mutex X 60 201709262207 6hurnha5k9qb6 352 latch: shared pool 60 201709262207 latch: shared pool 60 201709262207 0rs4yunhszr7w 352 latch: shared pool 60 201709262207 b7fy2a0snpja9 476 library cache: mutex X 60 201709262208 null event 300 201709262208 352 latch: shared pool 180 201709262208 0rs4yunhszr7w 352 latch: shared pool 60 201709262208 476 library cache: mutex X 60 201709262208 6hurnha5k9qb6 352 latch: shared pool 60 201709262208 b7fy2a0snpja9 476 library cache: mutex X 60 201709262208 latch: shared pool 60 201709262208 library cache: mutex X 60 201709262209 null event 326 201709262209 352 latch: shared pool 180 201709262209 latch: shared pool 60 201709262209 0rs4yunhszr7w 352 latch: shared pool 60 201709262209 b7fy2a0snpja9 476 library cache: mutex X 60 201709262209 6hurnha5k9qb6 352 latch: shared pool 60 201709262209 library cache: mutex X 60 201709262209 476 library cache: mutex X 60
阻塞会话明细
SQL> select event,sql_id,USER_ID,program from gV$active_session_history a where INST_ID=1 and SESSION_ID=476 and to_char(a.sample_time, ‘yyyymmddHH24mi‘)=201709262203; latch: shared pool 6hurnha5k9qb6 0 [email protected]39 (J002) latch: shared pool 6hurnha5k9qb6 0 [email protected]39 (J002) latch: shared pool 6hurnha5k9qb6 0 [email protected]39 (J002) latch: shared pool 6hurnha5k9qb6 0 [email protected]39 (J002) latch: shared pool 6hurnha5k9qb6 0 [email protected]39 (J002) latch: shared pool 6hurnha5k9qb6 0 [email protected]39 (J002) latch: shared pool 6hurnha5k9qb6 0 [email protected]39 (J002) latch: shared pool 6hurnha5k9qb6 0 [email protected]39 (J002) latch: shared pool 6hurnha5k9qb6 0 [email protected]39 (J002) SQL> select event,sql_id,USER_ID,program from gV$active_session_history a where INST_ID=1 and SESSION_ID=352and to_char(a.sample_time, ‘yyyymmddHH24mi‘)=201709262203; EVENT SQL_ID USER_ID PROGRAM ------------------------------ ------------- ---------- ------------------------------------------------ 0 [email protected]39 (MMAN) 0 [email protected]39 (MMAN) 0 [email protected]39 (MMAN) 0 [email protected]39 (MMAN) 0 [email protected]39 (MMAN) 0 [email protected]39 (MMAN) 0 [email protected]39 (MMAN) 0 [email protected]39 (MMAN) 0 [email protected]39 (MMAN) 0 [email protected]39 (MMAN) 0 [email protected]39 (MMAN) 0 [email protected]39 (MMAN)
MMAN进程是Oracle 10g引入用于进行内存管理的进程，在进行动态内存调整时，这个进程要发挥其作用,这个进程的作用是内部数据库任务的执行者：MMAN is used for internal database tasks.
MMAN to wait and post itself for satisfying an auto-tuned memory request while trying to fully free a component‘s quiesced granules. In Release 10.1, the name of this event was ‘wait for SGA component shrink‘.
在后台转储跟踪，可以看到MMAN进程的等待：
WAIT #0: nam=‘SGA: MMAN sleep for component shrink‘ ela= 10045 component id=6 current size=8 target size=7 obj#=-1 tim=9815936073 WAIT #0: nam=‘SGA: MMAN sleep for component shrink‘ ela= 10581 component id=6 current size=8 target size=7 obj#=-1 tim=9815946809 WAIT #0: nam=‘SGA: MMAN sleep for component shrink‘ ela= 10541 component id=6 current size=8 target size=7 obj#=-1 tim=9815957544 WAIT #0: nam=‘SGA: MMAN sleep for component shrink‘ ela= 10655 component id=6 current size=8 target size=7 obj#=-1 tim=9815968290 WAIT #0: nam=‘SGA: MMAN sleep for component shrink‘ ela= 10649 component id=6 current size=8 target size=7 obj#=-1 tim=9815979031
查询数据库最近内存调整记录
SQL> select COMPONENT, 2 STATUS, 3 OPER_TYPE, 4 OPER_MODE, 5 PARAMETER, 6 round(INITIAL_SIZE/1024/1024,2) INITIAL_mb , 7 round(TARGET_SIZE/1024/1024,2) TARGET_MB, 8 round(FINAL_SIZE/1024/1024,2) FINAL_mb, 9 to_char(START_TIME, ‘yyyy-mm-dd hh24:mi:ss‘) START_TIME, 10 to_char(END_TIME, ‘yyyy-mm-dd hh24:mi:ss‘) END_TIME 11 from V$MEMORY_RESIZE_OPS 12 where START_TIME > to_date(‘2017092621‘,‘yyyymmddhh24‘) 13 order by END_TIME; COMPONENT STATUS OPER_TYPE OPER_MODE PARAMETER INITIAL_MB TARGET_MB FINAL_MB START_TIME END_TIME ------------------------------ --------- ------------- --------- ------------------------------ ---------- ---------- ---------- ------------------- ------------------- shared pool COMPLETE SHRINK DEFERRED shared_pool_size 2752 2624 2624 2017-09-26 22:01:21 2017-09-26 22:10:07 DEFAULT buffer cache COMPLETE GROW DEFERRED db_cache_size 1536 1664 1664 2017-09-26 22:01:21 2017-09-26 22:10:07 DEFAULT buffer cache COMPLETE SHRINK DEFERRED db_cache_size 1664 1536 1536 2017-09-26 22:23:11 2017-09-26 22:23:13 shared pool COMPLETE GROW DEFERRED shared_pool_size 2624 2752 2752 2017-09-26 22:23:11 2017-09-26 22:23:13
至此问题定位，是由于SGA内存自动调整导致数据库异常
以上是关于Oracle数据库大量library cache: mutex X及latch: shared pool问题排查一例的主要内容，如果未能解决你的问题，请参考以下文章
重启大法失效？详述Oracle11g因JDBC bug引发异常Library Cache Lock等
Oracle11g 密码延迟认证导致library cache lock的情况分析
oracle 基础知识----Library Cache *
Oracle单实例情况下的library cache pin的问题模拟与问题分析
[转载——故障排除：Shared Pool优化和Library Cache Latch冲突优化 (文档 ID 1523934.1)