Memory Notification: Library Cache Object loaded into SGA

问题现象:

数据库服务器可以ping通,但SSH连接不了;应用、plsqldeveloper
也都连接不了。事情到了这个地步,只能重启服务器。

服务器环境:oracle10.2.0.1 +rhel5.8

重启后,查看实例日志:

Wed Apr 30 13:12:24
2014
Memory Notification:
Library Cache Object loaded into SGA
Heap
size 2210K exceeds notification threshold (2048K)
KGL
object name :XDB.XDbD/PLZ01TcHgNAgAIIegtw==
Wed Apr 30 14:00:16
2014
Thread 1 advanced to log sequence 24932
Current log# 1 seq#
24932 mem# 0:
/data/oracle/product/10.2.0/db_1/oradata/urpdb/redo01.log
Wed Apr 30
15:00:16 2014
Thread 1 advanced to log sequence 24933
Current log#
3 seq# 24933 mem# 0:
/data/oracle/product/10.2.0/db_1/oradata/urpdb/redo03.log
Wed Apr 30
15:15:05 2014
Thread 1 advanced to log sequence 24934
Current log#
2 seq# 24934 mem# 0:
/data/oracle/product/10.2.0/db_1/oradata/urpdb/redo02.log
Wed Apr 30
15:16:02 2014
Thread 1 advanced to log sequence 24935
Current log#
1 seq# 24935 mem# 0:
/data/oracle/product/10.2.0/db_1/oradata/urpdb/redo01.log
Wed Apr 30
15:17:42 2014
Thread 1 cannot allocate new log, sequence
24936
Checkpoint not complete

查看系统日志

Apr 30 15:37:17
wiscomApp1 kernel: [<c0456331>] out_of_memory+0x72/0x1a5

Apr 30 15:37:17 wiscomApp1 kernel: [<c0457806>]
__alloc_pages+0x216/0x297
Apr 30 15:37:17 wiscomApp1 kernel:
[<c0458a73>] __do_page_cache_readahead+0xc4/0x1c6
Apr 30 15:37:17
wiscomApp1 kernel: [<c045304c>] sync_page+0x0/0x3b
Apr 30
15:37:17 wiscomApp1 kernel: [<c044e161>]
__delayacct_blkio_end+0x32/0x35
Apr 30 15:37:17 wiscomApp1 kernel:
[<c06077cf>] __wait_on_bit_lock+0x4b/0x52
Apr 30 15:37:17
wiscomApp1 kernel: [<c0452fc7>] __lock_page+0x52/0x59
Apr 30
15:37:17 wiscomApp1 kernel: [<c04558e3>]
filemap_nopage+0x151/0x312
Apr 30 15:37:17 wiscomApp1 kernel:
[<c045f306>] __handle_mm_fault+0x1d0/0xb62
Apr 30 15:37:17
wiscomApp1 kernel: [<c0609886>] do_page_fault+0x2a5/0x5d3
Apr 30
15:37:17 wiscomApp1 kernel: [<c0448f0d>]
audit_syscall_entry+0x14b/0x17d
Apr 30 15:37:17 wiscomApp1 kernel:
[<c06095e1>] do_page_fault+0x0/0x5d3
Apr 30 15:37:17 wiscomApp1
kernel: [<c0405a71>] error_code+0x39/0x40

通过这2个日志可以看出,在13:12分,实例日志提示sga中有数据内存超出默认值

操作系统在15:37:17报错内存溢出。这个内存溢出应该和实例有直接关系。

再次查看服务器环境:物理内存8G,但sga只有2G。另外无意中发现操作系统是32-bit Red Hat
Linux,晕啊!

当时的第一想法,要想彻底解决这个问题,只能重新安装操作系统,再安装数据库,迁移数据。

后来,想看看实例中下面这段报错什么意思,

Memory Notification: Library Cache Object loaded into
SGA
Heap size 2210K exceeds notification threshold
(2048K)

于是发现了http://blog.itpub.net/519536/viewspace-659979这篇文章对这个分析的很好;

但从这个系统的实际情况说,这个只能是次要问题。真正要解决问题,还是上面的办法。

==============摘录链接文章中关键部分:===========================

在Oracle
10.2.0.1版本数据库中隐含参数_kgl_large_heap_warning_threshold默认值是2M,

该参数控制加载到内存中对象的大小,当加载的对象大于2M时,就会在alert警告文件中进行提示。

2M的默认大小相对太小,因此在10.2.0.1版本中可能很容易遇到这个报错信息。

该参数默认值在10.2.0.2版本中进行了调整,调整到了50M。

Memory Notification: Library Cache Object loaded into
SGA

时间: 2024-10-29 00:58:17

Memory Notification: Library Cache Object loaded into SGA的相关文章

笔记:Memory Notification: Library Cache Object loaded into SGA

在警告日志中发现一些这样的警告信息: Mon Nov 21 14:24:22 2011Memory Notification: Library Cache Object loaded into SGAHeap size 5800K exceeds notification threshold (2048K)Details in trace file c:\oracle\product\10.2.0\admin\hy2003\udump\hy2003_ora_4372.trcKGL object

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

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

Library cache lock/pin详解

Library cache lock/pin 一.概述 ---本文是网络资料加metalink 等整理得来一个实例中的library cache包括了不同类型对象的描述,如:游标,索引,表,视图,过程,等等. 这些对象不能在他们被使用的时候改变,他们在被使用的时候会被一种library locks and pins的机制锁住. 一个会话中,需要使用一个对象,会在该对象上先得到一个library lock(null, shared or exclusive模式的)这是为了,防止其他会话也访问这个对

遇到Library cache load lock 等待事件

遇到Library cache load lock 等待事件: 在Troubleshooting Library Cache: Lock, Pin and Load Lock (Doc ID 444560.1)这篇文章中,详细解释了该等待事件: If an object is not in memory, then a library cache lock cannot be acquired on it. The object has to be loaded into the memory

WAITEVENT: &quot;library cache: mutex X&quot; (文档 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

共享内存(Shared Pool)之一:Library cache逻辑结构

What is shared pool? Shared pool是SGA中的一部分,由于它是SGA的一部分,这意味着它可以被所有的进程所访问.Shared pool物理层面上由许多内存块组成,这些内在块称为chunk.但是chunk是大小不一的,在内存中一个chunk是连续的. 按逻辑结构划分:Shared Pool主要包含了3部分:Library cache,Dictionary cache和Control Structure. 由于shared pool中最重要的是library cache

Troubleshooting &#39;library cache: mutex X&#39; 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

Library Cache: Lock, Pin and Load Lock

What is "Library cache lock" ? This event controls the concurrency between clients of the library cache. It acquires a lock on the object handle so that either: One client can prevent other clients from accessing the same object. The client can

rac数据库默认sql tuning advisor,导致大量library cache lock

问题现象:客户反映周六周日固定十点钟,一个程序会特别慢(大概10分钟),平时1到2秒.查看当时的日志发现:DBMS_STATS: GATHER_STATS_JOB encountered errors.  Check the trace file.Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_j002_51847.trc:ORA-04021: timeout occurred while waiting to l