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内存自动调整导致数据库异常

原文地址：https://www.cnblogs.com/lYng/p/9480892.html

时间： 2024-11-05 18:29:06

Oracle数据库大量library cache: mutex X及latch: shared pool问题排查一例的相关文章

WAITEVENT: "library cache: mutex X" (文档 ID 727400.1)

WAITEVENT: "library cache: mutex X" (文档 ID 727400.1) 2014-01-19 09:56 2367人阅读 评论(0) 收藏 举报  分类: 网络资源_ORACLE_调优(108)  目录(?)[-] APPLIES TO PURPOSE SCOPE DETAILS Definition Individual Waits Systemwide Waits Wait Time Reducing Waits Wait times Known

Troubleshooting 'library cache: mutex X' waits. (文档 ID 1357946.1)

In this Document   Purpose   Troubleshooting Steps   What is a 'library cache: mutex X' wait?   What causes 'library cache: mutex X' wait?   How to diagnose the cause.   How to Examine the Diagnostics.   Potential Solutions   References APPLIES TO: O

Troubleshooting 'library cache: mutex X' Waits.

What is a 'library cache: mutex X' wait? The mutex feature is a mechanism to control access to in memory structures. It is used in a number of areas including the library cache. The library cache is a memory area that holds parsed cursor structures n

latch: shared pool latch: library cache 诊断脚本（latchprofx.sql，latchprof.sql）

执行方式如下: @d:\latchprofx.sql  sid,name,laddr % cache 10000 @d:\latchprof.sql  sid,name,laddr % cache 10000 脚本出处:http://www.tanelpoder.com latchprofx.sql -------------------------------------------------------------------------------- -- -- File name: l

Oracle Library Cache深入解析

Oracle Library Cache深入解析 每一个进入库缓存的对象,在库缓存中都被按照本身内容分割成多块进行存贮.Oracle这样做的目的是为了更灵活的内存管理,因为在内存寻找大块连续的内存,总比寻找小块连续内存更慢一些.如果一个库缓存对象(如一条SQL语句的执行计划),它所占的内存被切割成4个小块,它们分别被存放在库缓存的各处,并且互不相连.为了将这4个小块组合起来,Oracle另外这个库缓存对象分配一小块内存,这块内存中存有其他4个小块内存的地址,并且,还有一些有关此库缓存对象的基本信

Oracle Shared Pool 原理

Oracle Shared Pool 原理 由于shared pool中最重要的是library cache,所以本文主要讲解Library cache的结构,library cache latch,library cache lock,library cache pin. What is shared pool? Shared pool是SGA中的一部分,由于它是SGA的一部分,这意味着它可以被所有的进程所访问,Shared Pool当中主要包含了2部分:library cache和dicti

Oracle内存详解之二 Library cache 库缓冲-转载

Library cache是Shared pool的一部分,它几乎是Oracle内存结构中最复杂的一部分,主要存放shared curosr(SQL)和PLSQL对象(function,procedure,trigger)的信息,以及这些对象所依赖的table,index,view等对象的信息. Library cache需要解决三个问题: 1.快速定位的问题:Library cache中对象众多,Oracle如何管理这些对象,以便服务进程可以迅速找到他们需要的信息.比如某个服务进程需要迅速定位

oracle 基础知识(八)----Library Cache *

一,介绍 Library cache是Shared pool的一部分,它几乎是Oracle内存结构中最复杂的一部分,主要存放shared curosr(SQL)和PLSQL对象(function,procedure,trigger)的信息,以及这些对象所依赖的table,index,view等对象的信息. 二,库缓存 01,存放的单元 Library存放的信息单元都叫做对象,这些对象可以分为两类: (1) 存储对象: (2) 过渡对象: 三,查看命中率 SQL> desc v$libraryca

浅谈oracle数据库dbtime

1.如果等待时间比服务时间长很多,那我们就要优化等待时间,如果服务时间比等待时间长很多,就要先优化服务时间 这就是owi思想 那我们就需要判断整个数据库系统平均响应时间中服务时间(Service time)和等待时间(Wait time)各占的百分比.服务时间代表的是" CPU used by this session",是CPU服务会话所花费的所有时间.Response Time = Service Time + Wait TIme(即响应时间=cpu服务时间+等待时间) selec