Memory Notification: Library Cache Object loaded into SGA
Heap size 2295K exceeds notification threshold (2048K)
KGL object name :XDB.XDbD/PLZ01TcHgNAgAIIegtw==
感觉像oracle的BUG
今天在alert.log文件中遇到很多这样的信息：
Memory Notification: Library Cache Object loaded into SGA
Heap size 2295K exceeds notification threshold (2048K)
KGL object name :XDB.XDbD/PLZ01TcHgNAgAIIegtw==
感觉像oracle的BUG
C:>sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on 星期四 11月 22 16:11:50 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
idle>conn sys/sys@doscdb as sysdba
已连接。
DOSCDB(sys)>select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
查看了一下隐含参数
DOSCDB(sys)>select ksppinm name,
2 ksppstvl value,
3 ksppstdf isdefault,
4 decode(bitand(ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod,
5 decode(bitand(ksppstvf,2),2,'TRUE','FALSE') isadj
6 from x$ksppi x, x$ksppcv y
7 where (x.indx = y.indx) and
8 x.ksppinm like '%'||'¶meter'||'%'
9 /
输入 parameter 的值: kgl
原值 8: x.ksppinm like '%'||'¶meter'||'%'
新值 8: x.ksppinm like '%'||'kgl'||'%'
NAME VALUE ISDEFAULT ISMOD ISADJ
------------------------------ ------------------------- ------------------ -------------------- ----------
_kgl_multi_instance_lock TRUE TRUE FALSE FALSE
_kgl_multi_instance_pin TRUE TRUE FALSE FALSE
_kgl_multi_instance_invalidati TRUE TRUE FALSE FALSE
on
_kgl_latch_count 0 TRUE FALSE FALSE
_kgl_heap_size 1024 TRUE FALSE FALSE
_kgl_fixed_extents TRUE TRUE FALSE FALSE
_kgl_session_cached_objects 10 TRUE FALSE FALSE
_kgl_keep_cache_pct 30 TRUE FALSE FALSE
_kgl_keep_cache_retain_pct 20 TRUE FALSE FALSE
_kgl_bucket_count 9 TRUE FALSE FALSE
_kglsim_maxmem_percent 5 TRUE FALSE FALSE
_kgl_hash_collision FALSE TRUE FALSE FALSE
_kgl_time_to_wait_for_locks 15 TRUE FALSE FALSE
_kgl_large_heap_warning_thresh 2097152 TRUE FALSE FALSE
old
已选择14行。
_kgl_large_heap_warning_threshold 2097152
这行数据是值得怀疑的 ，应该就是它的问题
分析问题：
DOSCDB(sys)>select KSPPDESC from x$ksppi where ksppinm like '_kgl_large_heap_warning%';
KSPPDESC
-----------------------------------------------------------------------------------------
maximum heap size before KGL writes warnings to the alert log
从字面上分析就是这个原因。查询了一些资料发现，Oracle10g中，在load较大的对象进library cache中时，
会记录以上警告。在版本10.2.0.1中，这个定义大对象的阈值是2M，这是有隐含参数_kgl_large_heap_warning_threshold 指定的，
如果系统中需要load很多大对象，又不想在alert中看到太多这类的警告信息，可以修改该参数
解决问题：
将其修改成10m大小
DOSCDB(sys)>alter system set "_kgl_large_heap_warning_threshold"=10485760 scope=spfile ;
系统已更改。
DOSCDB(sys)>shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
DOSCDB(sys)>startup
ORACLE 例程已经启动。
Total System Global Area 419430400 bytes
Fixed Size 1249368 bytes
Variable Size 125833128 bytes
Database Buffers 285212672 bytes
Redo Buffers 7135232 bytes
数据库装载完毕。
数据库已经打开。
DOSCDB(sys)>select ksppinm name,
2 ksppstvl value,
3 ksppstdf isdefault,
4 decode(bitand(ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod,
5 decode(bitand(ksppstvf,2),2,'TRUE','FALSE') isadj
6 from x$ksppi x, x$ksppcv y
7 where (x.indx = y.indx) and
8 x.ksppinm like '%'||'¶meter'||'%'
9 /
输入 parameter 的值: kgl
原值 8: x.ksppinm like '%'||'¶meter'||'%'
新值 8: x.ksppinm like '%'||'kgl'||'%'
NAME VALUE ISDEFAULT ISMOD ISADJ
------------------------------ ------------------------- ------------------ -------------------- ----------
_kgl_multi_instance_lock TRUE TRUE FALSE FALSE
_kgl_multi_instance_pin TRUE TRUE FALSE FALSE
_kgl_multi_instance_invalidati TRUE TRUE FALSE FALSE
on
_kgl_latch_count 0 TRUE FALSE FALSE
_kgl_heap_size 1024 TRUE FALSE FALSE
_kgl_fixed_extents TRUE TRUE FALSE FALSE
_kgl_session_cached_objects 10 TRUE FALSE FALSE
_kgl_keep_cache_pct 30 TRUE FALSE FALSE
_kgl_keep_cache_retain_pct 20 TRUE FALSE FALSE
_kgl_bucket_count 9 TRUE FALSE FALSE
_kglsim_maxmem_percent 5 TRUE FALSE FALSE
_kgl_hash_collision FALSE TRUE FALSE FALSE
_kgl_time_to_wait_for_locks 15 TRUE FALSE FALSE
_kgl_large_heap_warning_thresh 10485760 FALSE FALSE FALSE
old
已选择14行。
再检查alert.log文件，没有发现类似信息，问题得以解决。
摘自：
在使用SQL TRACE之前，需要先查看 oracle 的初始参数是否设置好，有三个参数需要正确设置，分别是timed_statistics=true、user_dump_dest=跟踪文件存放位置、max_dump_file_size=unlimited、，这个值可以自己设定，其中timed_statistics参数用于是否可以在系统中执行跟踪，为true是表示可以执行跟踪。
其实在oracle10gR2中这几个参数都是已经设置好了的不用多做设置。 确定好这几个参数之后，就可以开始跟踪执行了。你可以在sys用户下执行跟踪，或者其他具有权限的用户下执行跟踪（不过当我在scott用户下执行跟踪之后发现没有跟踪文件）。
（1）开启跟踪：
Alter session set sql_trace true;
（2）执行需要跟踪的操作，比如
Select ename from emp where empno=7788;
（3）关闭跟踪
Alter session set sql_trace false;
2、转换、查询跟踪文件
我的初始参数user_dump_dest参数的值为/home/oracle/orcl/udump，则跟踪完成之后，我再这个目录下将看到这个跟踪文件，但是当我打开它是发现里面有很多跟踪文件，我不知道哪个文件时我刚才的跟踪文件，所以接下来，我再回到sql*plus里面查询我执行跟踪的会话的进程id，因为跟踪文件的文件名的格式是（实例名_ora_进程id.trc），我的实例名是orcl，所以我执行查询来确定进程id，查询之前先给用户赋予查询v$process、v$session和v$mystat视图的权限：
Grant select on v_$process to scott;
Grant select on v_$session to scott;
Grant select on v_$mystat to scott;
还好，在赋予权限的时候我时刻记得，在oracle中，我平时所访问的v$视图其实就是一个同义词，她不是实际的视图，而是由底层视图创建的同义词，而这些视图的底层视图与这些视图名称极为相似，比如v$process的底层视图是v_$process，所以在赋权时应该将v_$process视图的查询权限赋给用户。赋权完成之后就可以执行查询了：
Select spid
From v$process p,v$session s
Where p.addr=s.paddr and s.sid=(select sid from v$mystat where
rownum=1);
在返回的查询结果中，spid（也就是会话进程id）为2842，则我确定我刚才的跟踪文件为orcl_ora_2842.trc。
确定了跟踪文件就可以对其进行格式转换了：
Tkprof orcl_ora_2842.trc orcl_ora_2842_1.prf explain=system/password;
这不是在sql*plus中运行，而是在终端中运行。其实这个转换并不是必须的，但是阅读orcl_ora_2842.trc确实有点费劲，所以我用tkprof实用程序对跟踪文件进行转换，但是这种转换不会包含原始跟踪文件的所有信息，她会丢失一些信息，但是转换之后便于阅读。转换完毕，我先打开它，看看这些跟踪信息···
摘自：
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
