Memory Notification:Library Cache Object loaded in Heap size 2262K exceeds

Dear all
I am facing the following problem. I am using Oracle 10gR2 on Windows.
Please help me.
Memory Notification: Library Cache Object loaded into SGA
Heap size 2262K exceeds notification threshold (2048K)
KGL object name :XDB.XDbD/PLZ01TcHgNAgAIIegtw==
Thanks

This is a normal warning message displayed for release 10.2.0.1.0, this is just a bug that by default has declared the kgllarge_heap_warning_threshold instance parameter to 8388608 . The bug is harmless, but the problem is that you will see a lot of messages displayed on the alert.log file, which renders this file difficult to read and it is uncomfortable to spot the real errors.
Just declare a higher value for the kgllarge_heap_warning_threshold undocumented instance parameter. This is meant to be corrected at 10.2.0.2.0, but you can manually have this parameter increased to a value higher than the highest value reported.
For further references take a look at this metalink note:
Memory Notification: Library Cache Object Loaded Into Sga
Doc ID: Note:330239.1
~ Madrid
http://hrivera99.blogspot.com/

Similar Messages

Memory Notification: Library Cache Object loaded into SGA

Dear Gurus
I am noticing the following error into my database. database version is Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi host sun solaris
Memory Notification: Library Cache Object loaded into SGA
Heap size 2905K exceeds notification threshold (2048K)
Details in trace file /orafs/app/oracle/admin/pblsw/bdump/pblsw_dw01_14545.trc
KGL object name :SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2('VIEW_T', '7')), KU$.OBJ_NUM ,KU$.SCHEMA_OBJ.NAME ,KU$.SCHEMA_OBJ.NAME ,'VIEW' ,KU$.SCHEMA_OBJ.OWNER_NAME FROM SYS.KU$_VIEW_VIEW KU$ WHERE KU$.OBJ_NUM IN (SELECT * FROM TABLE(DBMS_METADATA.FETCH_OBJNUMS(200001)))
Regards
Rabi

refer
Memory Notification: Library Cache Object Loaded Into Sga (Doc ID 330239.1)
http://support.oracle.com

Notification about cache objects changes when node dies

Hi Guys,
     Coherence 3.3.1/389
     .Net API 3.3.1.2
     Sorry, i did not find in forum something similar to my question.
     Well, i have this situation:
     I have 8 Coherence nodes.
     I have one client connected to Coherence node number 1.
     The client have been listening for notifications about cache objects changes.
     Coherence node number 1 dead for some reason (not enough memory).
     What's happened with the client which was connected to this node?
     I think it just reconnect to other one, but what's happened with notifications which occurs until the client reconnects?
     Regards,
     Dmitry.

Hi Dmitry,
     Notifications are delivered only while the client is connected. So if the client or its proxy fail, upon reconnection, the client will need to recover appropriately.
     If you're using Coherence's built-in client-side data management features (such as Near cache or ContinuousQueryCache), Coherence will do this for you automatically (resynchronizing the local datasets).
     One other comment, the reconnection attempt is lazy and the client will not reconnect until your application code touches a clustered resource.
     (EDIT: If store-and-forward guarantees are required, then you can queue those messages on the server on a per-client basis in a dedicated NamedCache, which the client can then consume at its leisure whenever connected. This is an application-level construct.)
     Jon Purdy
     Oracle

Object in cache count and total heap size consumed.

Hi
Can you please help me to extract - total number of custom value objects (count) and its total heap space consumed. How do we extract this information (from jrcmd or jrockit command control - jrockit jvm).
Do we need to use - com.tangosol.net.management.Registry? can you share some example/documentation in this regard.
Thanks
sunder

Hi NJ,
Thanks for your response - if I have to implement unit-calculator - i need to use instrumentation API to compute the size of a entry which will affect the performance of system.
Here is my problem.
1 - Have a com.tangosol.net.DefaultCacheServer (distributed cache) instance running
2 - A client joins the distributed cluster and inserts records into cluster and leaves the cluster.
when I do jrcmd on "DefaultCacheServer" i dont see any of custom java components (beans set distributed cache) - I want to have visibility of objects being put in cache and actual space consumed. Is there a way to get this?
[xx@yyy ~]$ jrcmd 10693 print_object_summary
10693:
--------- Detailed Heap Statistics: ---------
64.7% 6565k 2571 +6565k [B
10.2% 1034k 14816 +1034k [C
3.7% 374k 3199 +374k java/lang/Class
3.6% 364k 15560 +364k java/lang/String
2.8% 280k 3468 +280k [Ljava/lang/Object;
1.2% 119k 118 +119k [Lcom/tangosol/util/RecyclingLinkedList$Node;
1.0% 98k 2510 +98k com/tangosol/io/ByteArrayWriteBuffer
0.9% 94k 2418 +94k com/tangosol/run/xml/SimpleElement
0.8% 81k 2088 +81k com/tangosol/run/xml/SimpleElement$AttributeMap
0.8% 80k 696 +80k [Ljava/util/HashMap$Entry;
0.6% 64k 2740 +64k java/util/HashMap$Entry
Note there are no custom component been listed in DefaultCacheServer instance.
Thanks
sunder

Just i notice a heap memory notification in alert.log file

Hi,
i notice that whenever a user exectuing a qurey this heap memory notification is coming in alert.log file.
Memory Notification: Library Cache Object loaded into SGA
Heap size 2294K exceeds notification threshold (2048K).
what it is actully tell me plz.

Duplicate post. Seems you don't want to read the replies to your previous similar question.
geting error in alert log file
Jaffar

Memory notification in Alert Log

I'm seeing the following in my alert log. Does this mean i am running out of SGA memory? if so, How do i increase it?
Wed Oct 22 10:10:29 2008
Memory Notification: Library Cache Object loaded into SGA
Heap size 2507K exceeds notification threshold (2048K)
KGL object name :Select status from ALL_OBJECTS where object_name = :objname and object_type = :objtype and owner = :ownere
Wed Oct 22 11:39:10 2008
Thread 1 advanced to log sequence 11479
Current log# 3 seq# 11479 mem# 0: /u03/oradata/psrdev/onlinelog/redo03a.log
Current log# 3 seq# 11479 mem# 1: /u03/oradata/psrdev/onlinelog/redo03b.log
Wed Oct 22 12:39:37 2008
Memory Notification: Library Cache Object loaded into SGA
Heap size 2543K exceeds notification threshold (2048K)
KGL object name :Select owner, object_type from all_objects where object_name = :ObjName
order by 2 DESC
Wed Oct 22 13:46:38 2008
Thread 1 advanced to log sequence 11480
Current log# 1 seq# 11480 mem# 0: /u01/oradata/psrdev/onlinelog/redo01a.log
Current log# 1 seq# 11480 mem# 1: /u01/oradata/psrdev/onlinelog/redo01b.log

I've seen this before. Search MetaLink on "Heap size exceeds notification threshold" or "Memory Notification: Library Cache Object loaded into SGA" (both copied straight from your alert log) and see note Note:330239.1
Metalink has an amazingly rich search. I've often found the solution to problems like this simply by copying relevant text from my alert log and pasting it into the MetaLink search field.

Memory Notification

Hi all,
We have oracle 10g RAC on IBM AIX.
Recently checking Alert log i found out this notification
Wed Oct 21 09:13:34 2009
Memory Notification: Library Cache Object loaded into SGA
Heap size 3722K exceeds notification threshold (2048K)
KGL object name :XDB.XDbD/PLZ01TcHgNAgAIIegtw==
Wed Oct 21 09:13:37 2009
Memory Notification: Library Cache Object loaded into SGA
Heap size 4072K exceeds notification threshold (2048K)
Details in trace file /Oracle/admin/KKMS/udump/kkms1_ora_786660.trc
KGL object name :XDB.XD/HngR5i2kv7gM4IjoliS/g==
Wed Oct 21 09:13:55 2009
Memory Notification: Library Cache Object loaded into SGA
Heap size 3103K exceeds notification threshold (2048K)
Details in trace file /Oracle/admin/KKMS/udump/kkms1_ora_786660.trc
KGL object name :SELECT TOWNER, TNAME, NAME, LENGTH, PRECISION, SCALE, TYPE, ISN
ULL, CONNAME, COLID, INTCOLID, SEGCOLID, COMMENT$, DEFAULT$, DFLTLEN
, ENABLED, DEFER, FLAGS, COLPROP, ADTNAME, ADTOWNER, CHARSETID,
CHARSETFORM, FSPRECISION, LFPRECISION, CHARLEN, TFLAGS, TYPESYN,
100 FROM SYS.EXU9COO WHERE TOBJID = :1 ORDER BY INTCOLID
Wed Oct 21 09:30:09 2009
Thread 1 advanced to log sequence 667
Current log# 2 seq# 667 mem# 0: +DG_DB_ASM/kkms/onlinelog/group_2.262.67594681
Does above notification means something bad coming up?
What steps will help me to overcome above notification
Thanks,
Neerav

Probably nothing to worry about
Do you set SGA_TARGET as init parameter. When you set SGA_TARGET parameter the db_cache and shared_poll memory balanced as per memory requirement. The mentioned notification is generated for the same process.
You can over come this notification by setting db_cache and library_cache size and by removing SGA_TARGET parameter. Or you can supress this message by setting kgl_large_heap_warning_threshold init parameter to some high values.
SQL> alter system set "_kgl_large_heap_warning_threshold"=8388608 scope=spfile ;
SQL> shutdown immediate SQL> startup

Database Heap Size issue -- Urgent Issue is on production

Hi All,
Iam encuntering the below errors in my alert log:
ue Jun 23 16:24:38 2009
Memory Notification: Library Cache Object loaded into SGA
Heap size 2467K exceeds notification threshold (2048K)
Details in trace file /oracle/home/oracle/OraHome_1/admin/tu/bdump/tu_dw01_3456.
trc
KGL object name :SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2
('TABLE_DATA_T', '7')), 0 ,KU$.BASE_OBJ.NAME ,KU$.BASE_OBJ.OWNER_NAME ,'TABLE' ,
to_char(KU$.BYTES_ALLOC) ,to_char(KU$.ET_PARALLEL) ,KU$.FGAC ,KU$.NONSCOPED_REF
,KU$.XMLSCHEMACOLS ,KU$.NAME ,KU$.NAME ,'TABLE_DATA' ,KU$.PART_NAME ,KU$.SCHEMA_
OBJ.OWNER_NAME ,KU$.TS_NAME ,KU$.TRIGFLAG ,decode(KU$.SCHEMA_OBJ.TYPE_NUM,2,deco
de(bitand(KU$.PROPERTY,8192),8192,'NESTED TABLE','TABLE'),19,'PARTITION',20,'PAR
TITION','SUBPARTITION') ,to_char(KU$.UNLOAD_METHO
Tue Jun 23 16:26:31 2009
The value (30) of MAXTRANS parameter ignored.
kupprdp: master process DM00 started with pid=18, OS id=3853
to execute - SYS.KUPM$MCP.MAIN('SYS_EXPORT_SCHEMA_01', 'SYSTEM', 'KUPC$
C_1_20090623162631', 'KUPC$S_1_20090623162631', 0);
kupprdp: worker process DW01 started with worker id=1, pid=21, OS id=3857
to execute - SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_01', 'SYSTEM');
what could be the reason for this?
Thanks in advance.

Hi ,
Thanks for an quick update.
The below is the contents of trace file:
000006ab8f100,c00000007160e4e8]
LIBRARY OBJECT: object=c000000074798aa8
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
CHILDREN: size=16
child# table reference handle
0 c0000000747658c8 c000000074765538 c0000000724dac78
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
0 c00000006aaeeb50 c000000074798bc0 I/P/A/-/- 0 NONE 00 1.19
2.17
LIBRARY OBJECT HANDLE: handle=c0000000724dac78 mutex=c0000000724dada8(0)
namespace=CRSR flags=RON/KGHP/PN0/[10010000]
kkkk-dddd-llll=0000-0001-0000 lock=N pin=X latch#=5 hpc=0002 hlc=0002
lwt=c0000000724dad20[c0000000724dad20,c0000000724dad20] ltm=c0000000724dad30[c00
00000724dad30,c0000000724dad30]
pwt=c0000000724dace8[c0000000724dace8,c0000000724dace8] ptm=c0000000724dacf8[c00
00000724dacf8,c0000000724dacf8]
ref=c0000000724dad50[c000000074765538,c000000074765538] lnd=c0000000724dad68[c00
00000724dad68,c0000000724dad68]
LIBRARY OBJECT: object=c00000006b93a468
type=CRSR flags=EXS[0001] pflags=NST[0001] status=VALD load=0
DEPENDENCIES: count=47 size=48
dependency# table reference handle position flags
0 c00000006bf2b288 c000000070caed00 c0000000727d3000 524 DEP[01
1 c00000006bf2b288 c000000070caed50 c00000007f87f728 14 DEP[01
2 c00000006bf2b288 c000000070caeda0 c00000007fae0558 396 DEP[01
3 c00000006bf2b288 c000000070caedf0 c00000007faf1940 322 DEP[01
4 c00000006bf2b288 c000000070caee40 c000000072a9aa28 2053 DEP[01
5 c00000006bf2b288 c000000070caee90 c00000007045b5a8 122 DEP[01
6 c00000006bf2b288 c000000070caeee0 c00000007f9e4120 198 DEP[01
7 c00000006bf2b288 c000000070caef30 c00000007f9e8f20 579 DEP[01
8 c00000006bf2b288 c00000006b93a6c8 c00000007fadb6c8 481 DEP[01
9 c00000006bf2b288 c00000006b93a718 c00000007f9e07d0 565 DEP[01
10 c00000006bf2b288 c00000006b93a768 c000000072965498 1436 DEP[01
11 c00000006bf2b288 c00000007457e5e0 c00000007fada748 27 DEP[01
12 c00000006bf2b288 c00000007457e630 c00000007fade610 88 DEP[01
13 c00000006bf2b288 c00000007457e680 c00000006b214380 86 DEP[01
14 c00000006bf2b288 c00000007457e6d0 c000000070734038 54 DEP[01
15 c00000006bf2b288 c00000007457e720 c000000072bdb6d0 376 DEP[01
16 c00000007457e970 c00000007457e770 c00000007fae2528 306 DEP[01
17 c00000007457e970 c00000007457e7c0 c00000006b0c37e8 192 DEP[01
18 c00000007457e970 c00000007457e810 c00000007f9ea290 339 DEP[01
19 c00000007457e970 c00000007457e860 c00000006afef650 2428 DEP[01
20 c00000007457e970 c00000007457e8b0 c00000007f9d9310 138 DEP[01
21 c00000007457e970 c00000007457e900 c00000007f9e57a8 972 DEP[01
22 c00000007457e970 c00000006bf45540 c0000000727f2af0 1459 DEP[01
23 c00000007457e970 c00000006bf45590 c00000007fadd5f0 506 DEP[01
24 c00000007457e970 c00000006bf455e0 c00000006ade1f88 2593 DEP[01
25 c00000007457e970 c00000006bf45630 c00000006afd9290 19 DEP[01
26 c00000007457e970 c00000006bf45680 c00000006abe3990 63 DEP[01
27 c00000007457e970 c00000006bf456d0 c0000000704c80a8 530 DEP[01
28 c00000007457e970 c00000006bf45720 c00000006a8c04d0 1999 DEP[01
29 c00000007457e970 c00000006bf45770 c000000070605530 343 DEP[01
30 c00000007457e970 c00000006bf457c0 c0000000705c55d8 112 DEP[01
31 c00000007457e970 c00000006bf45810 c00000006b260aa0 552 DEP[01
32 c00000006bf458d0 c00000006bf45860 c000000072776fe0 535 DEP[01
33 c00000006bf458d0 c000000074d91b20 c00000006b0fa028 2053 DEP[01
34 c00000006bf458d0 c000000074d91b70 c00000007259dc78 162 DEP[01
35 c00000006bf458d0 c000000074d91bc0 c000000072ae0368 1996 DEP[01
36 c00000006bf458d0 c000000074d91c10 c0000000706303b0 212 DEP[01
37 c00000006bf458d0 c000000074d91c60 c00000006b16eb98 2336 DEP[01
38 c00000006bf458d0 c000000074d91cb0 c000000072916b00 211 DEP[01
39 c00000006bf458d0 c000000074d91d00 c0000000724e4960 261 DEP[01
40 c00000006bf458d0 c000000074d91d50 c00000007272a9f0 594 DEP[01
41 c00000006bf458d0 c000000074d91da0 c0000000726d8c18 2000 DEP[01
42 c00000006bf458d0 c000000074d91df0 c00000006a979970 40 DEP[01
43 c00000006bf458d0 c000000074d91e40 c00000006a979120 40 DEP[01
44 c00000006bf458d0 c000000074d91e90 c00000007270d240 40 DEP[01
45 c00000006bf458d0 c00000006b6bca40 c0000000704b9a28 722 DEP[01
46 c00000006bf458d0 c00000006b6bcb00 c00000007f9cf1d0 0 DEP[01
READ ONLY DEPENDENCIES: count=1 size=16
dependency# table reference handle flags
0 c00000006b93a7e0 c00000006b93a688 c00000007160de78 /ROD/KPP[60]
ACCESSES: count=3 size=16
dependency# types
44 000c
45 0009
0 0009
TRANSLATIONS: count=1 size=16
original final
c00000006a979120 c00000007270d240
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
0 c00000006abd4db8 c00000006bf2aef8 I/P/A/-/- 0 NONE 00 7.78
8.35
6 c000000070caeb80 c000000075d0bd90 I/P/A/-/- 1 NONE 00 2467.53 24
67.77
Memory Notification: Library Cache Object loaded into SGA
Heap size 2467K exceeds notification threshold (2048K)
LIBRARY OBJECT HANDLE: handle=c00000007160de78 mutex=c00000007160dfa8(1)
name=
SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2('TABLE_DATA_T',
'7')), 0 ,KU$.BASE_OBJ.NAME ,KU$.BASE_OBJ.OWNER_NAME ,'TABLE' ,to_char(KU$.BYTES
ALLOC) ,tochar(KU$.ET_PARALLEL) ,KU$.FGAC ,KU$.NONSCOPED_REF ,KU$.XMLSCHEMACOL
S ,KU$.NAME ,KU$.NAME ,'TABLE_DATA' ,KU$.PART_NAME ,KU$.SCHEMA_OBJ.OWNER_NAME ,K
U$.TS_NAME ,KU$.TRIGFLAG ,decode(KU$.SCHEMA_OBJ.TYPE_NUM,2,decode(bitand(KU$.PRO
PERTY,8192),8192,'NESTED TABLE','TABLE'),19,'PARTITION',20,'PARTITION','SUBPARTI
hash=6930382ca9499d586b66e6195bdecc2e timestamp=06-23-2009 16:24:37
namespace=CRSR flags=RON/KGHP/TIM/KEP/PN0/KST/DBN/MTX/[100100d4]
kkkk-dddd-llll=0001-0001-0001 lock=N pin=0 latch#=5 hpc=0002 hlc=0002
lwt=c00000007160df20[c00000007160df20,c00000007160df20] ltm=c00000007160df30[c00
000007160df30,c00000007160df30]
pwt=c00000007160dee8[c00000007160dee8,c00000007160dee8] ptm=c00000007160def8[c00
000007160def8,c00000007160def8]
ref=c00000007160df50[c00000007160df50,c00000007160df50] lnd=c00000007160df68[c00
000006ab8f100,c00000007160e4e8]
LIBRARY OBJECT: object=c000000074798aa8
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
CHILDREN: size=16
child# table reference handle
0 c0000000747658c8 c000000074765538 c0000000724dac78
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
0 c00000006aaeeb50 c000000074798bc0 I/P/A/-/- 0 NONE 00 1.19
2.17
LIBRARY OBJECT HANDLE: handle=c0000000724dac78 mutex=c0000000724dada8(0)
namespace=CRSR flags=RON/KGHP/PN0/[10010000]
kkkk-dddd-llll=0000-0001-0000 lock=N pin=X latch#=5 hpc=0002 hlc=0002
lwt=c0000000724dad20[c0000000724dad20,c0000000724dad20] ltm=c0000000724dad30[c00
00000724dad30,c0000000724dad30]
pwt=c0000000724dace8[c0000000724dace8,c0000000724dace8] ptm=c0000000724dacf8[c00
00000724dacf8,c0000000724dacf8]
ref=c0000000724dad50[c000000074765538,c000000074765538] lnd=c0000000724dad68[c00
00000724dad68,c0000000724dad68]
LIBRARY OBJECT: object=c00000006b93a468
type=CRSR flags=EXS[0001] pflags=NST[0001] status=VALD load=0
DEPENDENCIES: count=47 size=48
dependency# table reference handle position flags
0 c00000006bf2b288 c000000070caed00 c0000000727d3000 524 DEP[01
1 c00000006bf2b288 c000000070caed50 c00000007f87f728 14 DEP[01
2 c00000006bf2b288 c000000070caeda0 c00000007fae0558 396 DEP[01
3 c00000006bf2b288 c000000070caedf0 c00000007faf1940 322 DEP[01
4 c00000006bf2b288 c000000070caee40 c000000072a9aa28 2053 DEP[01
5 c00000006bf2b288 c000000070caee90 c00000007045b5a8 122 DEP[01
6 c00000006bf2b288 c000000070caeee0 c00000007f9e4120 198 DEP[01
7 c00000006bf2b288 c000000070caef30 c00000007f9e8f20 579 DEP[01
8 c00000006bf2b288 c00000006b93a6c8 c00000007fadb6c8 481 DEP[01
9 c00000006bf2b288 c00000006b93a718 c00000007f9e07d0 565 DEP[01
10 c00000006bf2b288 c00000006b93a768 c000000072965498 1436 DEP[01
11 c00000006bf2b288 c00000007457e5e0 c00000007fada748 27 DEP[01
12 c00000006bf2b288 c00000007457e630 c00000007fade610 88 DEP[01
13 c00000006bf2b288 c00000007457e680 c00000006b214380 86 DEP[01
14 c00000006bf2b288 c00000007457e6d0 c000000070734038 54 DEP[01
15 c00000006bf2b288 c00000007457e720 c000000072bdb6d0 376 DEP[01
16 c00000007457e970 c00000007457e770 c00000007fae2528 306 DEP[01
17 c00000007457e970 c00000007457e7c0 c00000006b0c37e8 192 DEP[01
18 c00000007457e970 c00000007457e810 c00000007f9ea290 339 DEP[01
19 c00000007457e970 c00000007457e860 c00000006afef650 2428 DEP[01
20 c00000007457e970 c00000007457e8b0 c00000007f9d9310 138 DEP[01
21 c00000007457e970 c00000007457e900 c00000007f9e57a8 972 DEP[01
22 c00000007457e970 c00000006bf45540 c0000000727f2af0 1459 DEP[01
23 c00000007457e970 c00000006bf45590 c00000007fadd5f0 506 DEP[01
24 c00000007457e970 c00000006bf455e0 c00000006ade1f88 2593 DEP[01
25 c00000007457e970 c00000006bf45630 c00000006afd9290 19 DEP[01
26 c00000007457e970 c00000006bf45680 c00000006abe3990 63 DEP[01
27 c00000007457e970 c00000006bf456d0 c0000000704c80a8 530 DEP[01
28 c00000007457e970 c00000006bf45720 c00000006a8c04d0 1999 DEP[01
29 c00000007457e970 c00000006bf45770 c000000070605530 343 DEP[01
30 c00000007457e970 c00000006bf457c0 c0000000705c55d8 112 DEP[01
31 c00000007457e970 c00000006bf45810 c00000006b260aa0 552 DEP[01
32 c00000006bf458d0 c00000006bf45860 c000000072776fe0 535 DEP[01
33 c00000006bf458d0 c000000074d91b20 c00000006b0fa028 2053 DEP[01
34 c00000006bf458d0 c000000074d91b70 c00000007259dc78 162 DEP[01
35 c00000006bf458d0 c000000074d91bc0 c000000072ae0368 1996 DEP[01
36 c00000006bf458d0 c000000074d91c10 c0000000706303b0 212 DEP[01
37 c00000006bf458d0 c000000074d91c60 c00000006b16eb98 2336 DEP[01
38 c00000006bf458d0 c000000074d91cb0 c000000072916b00 211 DEP[01
39 c00000006bf458d0 c000000074d91d00 c0000000724e4960 261 DEP[01
40 c00000006bf458d0 c000000074d91d50 c00000007272a9f0 594 DEP[01
41 c00000006bf458d0 c000000074d91da0 c0000000726d8c18 2000 DEP[01
42 c00000006bf458d0 c000000074d91df0 c00000006a979970 40 DEP[01
43 c00000006bf458d0 c000000074d91e40 c00000006a979120 40 DEP[01
44 c00000006bf458d0 c000000074d91e90 c00000007270d240 40 DEP[01
45 c00000006bf458d0 c00000006b6bca40 c0000000704b9a28 722 DEP[01
46 c00000006bf458d0 c00000006b6bcb00 c00000007f9cf1d0 0 DEP[01
READ ONLY DEPENDENCIES: count=1 size=16
dependency# table reference handle flags
0 c00000006b93a7e0 c00000006b93a688 c00000007160de78 /ROD/KPP[60]
ACCESSES: count=3 size=16
dependency# types
44 000c
45 0009
0 0009
TRANSLATIONS: count=1 size=16
original final
c00000006a979120 c00000007270d240
DATA BLOCKS:
data# heap pointer status pins change whr alloc(K) size(K)
0 c00000006abd4db8 c00000006bf2aef8 I/P/A/-/- 0 NONE 00 7.45
8.69
6 c000000070caeb80 c000000075d0bd90 I/P/A/-/- 1 NONE 00 2467.53 24

Peformance Improvement by increasing heap size

Hi
Is there any performace benefit when I execute my Java application by increasing the default heap size using Java -ms200m -mx200m <appName>
Please support with some performance figures
Regards
Vishal

If you know the size of the heap gows to you can save some time on startup. i.e.
If you know it grows to 100 MB on startup, make this the initial size.
The only diference I have found is when using SoftReference caching. Having more heap size will allow such a cahce keep it data for longer.
I would suggest running the application with -verbosegc to soo how often it garbage collects and how long it spends do it.
If you want to improve performance use a profiles e.g. JProfiler, Optimize-It, JProbe

"Could not create the Java virtual machine." when max-heap-size is 926Mb

We received "Could not create the Java virtual machine." when the max-heap-size provided exceeded 926 Mb in XP PC. We found the below mentioned link which confirms that this is a bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6945136
But the problem is that the issue does not get recreated in all the XP PCs. Increasing the max heap size to greater than 926 works fine in some XP PCs.
Could there be any configuration related issues for this problem...

If you can't find any difference in your java versions or overall runtime configurations, it's quite possible that the bug doesn't have the complete picture--it might be more subtle than the conditions described. Maybe it works with certain versions of certain lower level DLLs. Maybe it has some dependency on which services are running. Maybe the order in which certain components got installed put one version of something vs. another further ahead in a CLASSPATH, LD_LIBRARY_PATH, etc. variable.
Or maybe it's as simple as you're not running the version of Java you think you are on all those boxes, as jschell suggests.
Regardless of the reason why it happens to work on some configurations, you found that it fails on some, and that failure is in fact a known bug. So it shouldn't surprise you that it fails at least sometimes, and the fact that it works sometimes has been rendered irrelevant. Unless you're doing research into the specific cause of this issue.

High library cache load lock waits in AWR

Hi All,
Today i faced a significant performance problem related to shared pool. I made some observations, thought it would be a nice idea to share them with Oracle experts. Please feel free to add your observations/recommendations and correct me where i am wrong.
Here are the excerpts from AWR report created for the problem timing. Database server is on 10.2.0.3 and running with 2*16 configuration. DB cache size is 4,000M and shared pool size is of 3008M.
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 9994 29-Jun-09 10:00:07 672 66.3
End Snap: 10001 29-Jun-09 17:00:49 651 64.4
Elapsed:   420.70 (mins)
DB Time:   4,045.34 (mins)   -- Very poor response time visible from difference between DB time and elapsed time.
Load Profile
Per Second Per Transaction
Redo size: 248,954.70 23,511.82
Logical reads: 116,107.04 10,965.40
Block changes: 1,357.13 128.17
Physical reads: 125.49 11.85
Physical writes: 51.49 4.86
User calls: 224.69 21.22
Parses: 235.22 22.21
Hard parses: 4.83 0.46
Sorts: 102.94 9.72
Logons: 1.12 0.11
Executes: 821.11 77.55
Transactions: 10.59   -- User calls and Parse count are almost same, means most of the calls are for parse. Most of the parses are soft. Per transaction 22 parses are very high figure.
-- Not much disk I/O activity. Most of the reads are being satisfy from memory.
Instance Efficiency
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.92 In-memory Sort %: 100.00
Library Hit %: 98.92 Soft Parse %: 97.95
Execute to Parse %: 71.35 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 16.82 % Non-Parse CPU: 91.41 -- Low execute to parse ratio denotes CPU is significantly busy in parsing. Soft Parse% showing, most of the parse are soft parses. It means we should concentrate on soft parsing activity.
-- Parse CPU to Parse Elapsed % is quite low, means some bottleneck is there related to parsing. It could be a side-effect of huge parsing pressure. Like CPU cycles are not available.
Shared Pool Statistics
Begin End
Memory Usage %: 81.01 81.92
% SQL with executions>1: 88.51 86.93
% Memory for SQL w/exec>1: 86.16 86.76 -- Shared Pool memory seems ok (in 80% range)
-- 88% of the SQLs are repeating ones. It's a good sign.
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
library cache load lock 24,243 64,286 2,652 26.5 Concurrency
db file sequential read 1,580,769 42,267 27 17.4 User I/O
CPU time   33,039   13.6
latch: library cache 53,013 29,194 551 12.0 Concurrency
db file scattered read 151,669 13,550 89 5.6 User I/O Problem-1: Contention on Library cache: May be due to under-sized shared pool, incorrect parameters, poor application design, But since we already observed that most of the parses are soft parses and shared pool usgae in 80%, seems problem related to holding cursors. open_cursors/session_cached_cursors are red flags.
Problem-2: User I/O, may be due to poor SQLs, I/O sub-system, or poor physical design (wrong indexes are being used as DB file seq reads)
Wait Class
Wait Class Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
Concurrency 170,577 44.58 109,020 639 0.64
User I/O 2,001,978 0.00 59,662 30 7.49
System I/O 564,771 0.00 8,069 14 2.11
Application 145,106 1.25 6,352 44 0.54
Commit 176,671 0.37 4,528 26 0.66
Other 27,557 6.31 2,532 92 0.10
Network 6,862,704 0.00 696 0 25.68
Configuration 3,858 3.71 141 37 0.01
Wait Events
Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
library cache load lock 24,243 83.95 64,286 2652 0.09
db file sequential read 1,580,769 0.00 42,267 27 5.91
latch: library cache 53,013 0.00 29,194 551 0.20
db file scattered read 151,669 0.00 13,550 89 0.57
latch: shared pool 25,403 0.00 12,969 511 0.10
log file sync 176,671 0.37 4,528 26 0.66
enq: TM - contention 1,455 90.93 3,975 2732 0.01 Instance Activity Stats
opened cursors cumulative 5,290,760 209.60 19.80
parse count (failures) 6,181 0.24 0.02
parse count (hard) 121,841 4.83 0.46
parse count (total) 5,937,336 235.22 22.21
parse time cpu 283,787 11.24 1.06
parse time elapsed 1,687,096 66.84 6.31 Latch Activity
library cache 85,042,375 0.15 0.43 29194 304,831 7.16
library cache load lock 257,089 0.00 1.20 0 69,065 0.00
library cache lock 41,467,300 0.02 0.07 6 2,714 0.07
library cache lock allocation 730,422 0.00 0.44 0 0
library cache pin 28,453,986 0.01 0.16 8 167 0.00
library cache pin allocation 509,000 0.00 0.38 0 0 Init.ora parameters
cursor_sharing= EXACT
open_cursors= 3000
session_cached_cursors= 0
-- open_cursors value is too high. I have checked that maximum usage by a single session is 12%.
-- session_cached_cursors are 0 causing soft parsing. 500/600 is good number to start with.
cursor_sharing exact may cause hard parses. But here, hard parsing is comparatively small, we can ignore this.
From v$librarycache
NAMESPACE             GETS    GETHITS GETHITRATIO       PINS PINHITRATIO    RELOADS INVALIDATIONS
SQL AREA            162827      25127 .154317159 748901435 .999153087     107941         81886-- high invalidation count due to DDL like activities.
-- high reloads due to small library cache.
-- hit ratio too small.
-- Need to pin frequently executed objects into library cache.
P.S. Same question asked on Oracle_L, but due to formatting reasons, pasing duplicate contents here.
Regards,
Neeraj Bhatia
Edited by: Neeraj.Bhatia2 on Jul 13, 2009 6:51 AM

Thanks Charles. I really appreciate your efforts to diagnose the issue.
I agree with you performance issue is caused by soft parsing, which can be solved by holding cursors (session_cached_cursors). It may be due to oversized shared pool, which is causing delay in searching child cursors.
My second thought is, there is large number of reloads, which can be due to under-sized shared pool, if invalidation activities are not going (CBO statistics collection, DDL etc), cursors are being flushed frequently.
CPU utilization is continuously high (above 90%). Pasting additional information from same AWR report.
Namespace                Get Requests       Pct Miss        Pin Requests         Pct Miss      Reloads        Invalidations
BODY                       225,345               0.76            4,965,541            0.15           5,533           0
CLUSTER                   1,278                  1.41            2,542                  1.73           26                0
INDEX                       5,982                  9.31            13,922                7.35           258               0
SQL AREA                  141,465              54.10           27,831,235         1.21           69,863          19,085 Latch Miss Sources
Latch Name             Where                                         NoWait Misses                 Sleeps             Waiter Sleeps
library cache lock       kgllkdl: child: no lock handle             0                                   8,250                   5,792 Time Model Statistics
Statistic Name                                                                           Time (s)                               % of DB Time
sql execute elapsed time                                                           206,979.31                                      85.27
PL/SQL execution elapsed time                                                    94,651.78                                      39.00
DB CPU                                                                                     33,039.29                                      13.61
parse time elapsed                                                                      22,635.47                                       9.33
inbound PL/SQL rpc elapsed time                                                  14,763.48                                       6.08
hard parse elapsed time                                                               14,136.77                                       5.82
connection management call elapsed time                                        1,625.07                                       0.67
PL/SQL compilation elapsed time                                                        760.76                                       0.31
repeated bind elapsed time                                                               664.81                                       0.27
hard parse (sharing criteria) elapsed time                                             500.11                                       0.21
Java execution elapsed time                                                              252.95                                       0.10
failed parse elapsed time                                                                   167.23                                       0.07
hard parse (bind mismatch) elapsed time                                             124.11                                       0.05
sequence load elapsed time                                                                23.34                                        0.01
DB time                                                                                   242,720.12
background elapsed time                                                             11,645.52
background cpu time                                                                      247.25 According to this DB CPU is 65% utilization (DB CPU + Background CPU / Total Available CPU seconds). While at the same time DB host was 95% utilized (confirmed from DBA_HIST_SYSMETRIC_SUMMARY).
Operating System Statistics
Statistic                                         Total
BUSY_TIME                             3,586,030
IDLE_TIME                              1,545,064
IOWAIT_TIME                              22,237
NICE_TIME                                           0
SYS_TIME                                  197,661
USER_TIME                              3,319,452
LOAD                                                 11
RSRC_MGR_CPU_WAIT_TIME                  0
PHYSICAL_MEMORY_BYTES          867,180
NUM_CPUS                                           2

How to detect the object or session in a database with library cache lock

Hi Everyone,
We've been experiencing frequent and high time waits for this event: library cache lock.
- What causes this?
- Is there a way to detect the object being locked?
(this doesnt show up in V$LOCK)
- Is there a way to detect the session that is causing the lock? aka blocking session?
(I can detect the objects being blocked, they show up in v$session)
thanks,

Similar post is here, maybe that helps already:
library cache lock
And You can read this as well:
http://www.ixora.com.au/q+a/0101/19235723.htm

How to find which objects were causing library cache latches?

Hi All,
An hour back we saw a lot of sessions waiting on "latch: library cache".
Below is the output of the ASH Report:
Top Event P1/P2/P3 Values
Event     % Event     P1 Value, P2 Value, P3 Value     % Activity     Parameter 1     Parameter 2     Parameter 3
latch: library cache     80.23     "13835058076921816712", "214", "0"     29.16     address     number     tries
          "13835058076921817352", "214", "0"     16.66
          "13835058076921817992", "214", "0"     8.69
latch: shared pool     7.00     "13835058055432026888", "213", "0"     5.93     address     number     tries
How do we find out the Address from this P1 Value?
Thanks in advance

If you want to find the object you are waiting on:
SELECT kglnaown "Owner", kglnaobj "Object"
FROM x$kglob
WHERE kglhdadr=<P1RAW from v$session_wait>

High CPU load with Library Cache Pin wit event.

Oracle8i Enterprise Edition Release 8.1.6.0.0, 64 bit - Production
HP-UX B.11.00 U 9000/800 605309363 unlimited-user license
Currently CPU load is 100% with very less sessions in the database.
But i am finding Library Cache Pin wait event in top.
If i query v$latchholder i am not getting any rows..and in v$lacth_children
SQL> select SID,EVENT,WAIT_TIME,SECONDS_IN_WAIT,STATE from v$session_wait where EVENT='library cache pin';
       SID EVENT                                     WAIT_TIME SECONDS_IN_WAIT STATE
         8 library cache pin                                 0             863 WAITING
        90 library cache pin                                 0            3093 WAITING
        89 library cache pin                                 0            2566 WAITING
        57 library cache pin                                 0           27384 WAITING
        54 library cache pin                                 0           21029 WAITING
        53 library cache pin                                 0            7840 WAITING
        50 library cache pin                                 0            2620 WAITING
        47 library cache pin                                 0            6031 WAITING
        46 library cache pin                                 0            1241 WAITING
        41 library cache pin                                 0           15637 WAITING
       145 library cache pin                                 0             910 WAITING
       133 library cache pin                                 0            5124 WAITING
       111 library cache pin                                 0           15077 WAITING
        98 library cache pin                                 0            6563 WAITING
        94 library cache pin                                 0            2088 WAITING
        93 library cache pin                                 0            4592 WAITING
        92 library cache pin                                 0           14705 WAITING
        91 library cache pin                                 0           14798 WAITING
        36 library cache pin                                 0            1533 WAITING
        33 library cache pin                                 0            1491 WAITING
        28 library cache pin                                 0           13970 WAITING
        25 library cache pin                                 0            7630 WAITING
        11 library cache pin                                 0           12169 WAITING
        12 library cache pin                                 0            2352 WAITING
        14 library cache pin                                 0           19748 WAITING
SQL> select addr,name from v$latch where name='library cache';
ADDR             NAME
C00000006971D460 library cache
SQL> select latch#,name from v$latch_children where name='library cache';
    LATCH# NAME
       105 library cache
       105 library cache
       105 library cache
       105 library cache
       105 library cachePlease help me out to find actual cause of these latches and fix ?
-Yasser

bump
No-one?
The problem seems to have 'resolved itself' over the weekend incidentally (although I don't believe anything truly resolves itself in this manner - something must have changed).

How to resolve Library Cache Pin waits?

Hai All,
I grant a select privilage on a table to another user. Then my session hangs. after 5 minutes a message present that is 'ORA-04021: timeout occurred while waiting to lock object....' etc.
I query the v$session_wait and see a Library Cache pin wait present in my session. I copy the p1raw column from here and put into some x$ tables and v$session then I can identify one session using a application using that table. I kill that session . then my grant privilage query works..
So what is library cache pin waits.. How to identify in application...How to resolve it? it resolve in database level or application level?
Please Help..
Shiju

Most common cause of library cache pin wait event are
-- Not use binding variables in the query
-- Some one keeps modify the schema objects
library cache pin
This event manages library cache concurrency. Pinning an object causes the heaps to be loaded into memory. If a client wants to modify or examine the object, the client must acquire a pin after the lock.
Wait Time: 3 seconds (1 second for PMON)
Parameter Description
handle address Address of the object being loaded
pin address Address of the load lock being used. This is not the same thing as a latch or an enqueue, it is basically a State Object.
mode Indicates which data pieces of the object that needs to be loaded
namespace See "namespace"

Memory Notification:Library Cache Object loaded in Heap size 2262K exceeds

Similar Messages

Maybe you are looking for