The other day I met problem:
- while attampting query to some views got ORA-04023 - udump directory size increas
Size of some trace files in UDUMP directory were more then 200M.
So, what's in UDUMP "big" trace file?... Something like this:
........
kksfbc: entering diagnosis mode for xsc:110a65f48
CUR#4 XSC 110a65f48 CHILD#49 CI 0 CTX 0
Compilation environment difference Failed sharing : 0
Change in cursor environment
SQL pgadep:0 pgapls:0 user
Reparse from kzp.c-1296
LIBRARY OBJECT HANDLE: handle=700000125c3baa8 mtx=700000125c3bbd8(0) lct=500118 pct=500121 cdp=0
name=ASUPPP.MENU_MENU
hash=b823edba89e14a29b261f413e378445c timestamp=03-13-2012 09:38:36
namespace=TABL flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0000-0709-272b lock=S pin=S latch#=1 hpc=06ee hlc=06ee
lwt=700000125c3bb50[700000125c3bb50,700000125c3bb50] ltm=700000125c3bb60[700000125c3bb60,700000125c3bb60]
pwt=700000125c3bb18[700000125c3bb18,700000125c3bb18] ptm=700000125c3bb28[700000125c3bb28,700000125c3bb28]
ref=700000125c3bb80[700000125c3bb80,700000125c3bb80] lnd=700000125c3bb98[700000125b791d0,700000125c3acf0]
LIBRARY OBJECT: object=700000125c3b628
type=VIEW flags=EXS/LOC[0005] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=5 size=16
dependency# table reference handle position flags
----------- -------- --------- -------- -------- -------------------
0 700000125c3b4f8 700000125c3b168 700000125c3af38 0 DEP[01]
1 700000125c3b4f8 700000125c3b1c0 700000126b563f8 0 DEP[01]
2 700000125c3b4f8 700000125c3b218 700000126b560c0 0 DEP/INV[05]
3 700000125c3b4f8 700000125c3b270 700000125c3ac00 0 DEP[01]
4 700000125c3b4f8 700000125c3b2f8 700000125c3a8c8 0 DEP[01]
........
Pay attantion to the line ... DEP/INV[05]
[05] - namespcae - table/procedure
INV - invalid
So, I've got invalid dependent library cache object with handle 700000126b560c0
Fruther searching down in this trace file lead me to this:
.......
LIBRARY OBJECT HANDLE: handle=700000126b560c0 mtx=700000126b561f0(0) lct=756795 pct=61053 cdp=0
name=ASUPPP.TEXT_PODR
hash=5a7e0016c3ccd858042741869af8554e timestamp=03-27-2012 10:14:06
namespace=TABL flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0000-201d-201d lock=S pin=S latch#=8 hpc=0334 hlc=0334
lwt=700000126b56168[700000126b56168,700000126b56168] ltm=700000126b56178[70000011004f288,7000001060bd8c8]
pwt=700000126b56130[700000126b56130,700000126b56130] ptm=700000126b56140[700000126b56140,700000126b56140]
ref=700000126b56198[700000126b56198,700000126b56198] lnd=700000126b561b0[700000126b02768,700000126b564e8]
........
In fact ASUPPP.MENU_MENU it's a view that includes calls to function ASUPPP.TEXT_PODR function.
According to metalink ID 727384.1 this issue due to library objects timestamp mismatch. ASUPPP.MENU_MENU has timestamp=03-13-2012 09:38:36
but ASUPPP.TEXT_PODR has timestamp=03-27-2012 10:14:06 and though parent object TEXT_PODR has timestamp newly than MENU_MENU.
What to do? Metalink states that this problem can be solved in several ways:
- alter view ASUPPP.MENU_MENU compile; -- in my case didn't solve problem and give me ORA-04023
- runing UTLRP.SQL -- recompile invalid objects. I think it also may not work, because both objects (MENU_MENU, TEXT_PODR) have VALID
status in DBA_OBJECTS.
- CREATE OR REPLACE VIEW ASUPPP.MENU_MENU ... ; -- worked fine in my case
- alter system flush SHARED_POOL;
It could be usefull to run periodicaly:
Oracle Metalink ID:
10373013.8
727384.1
444985.1
- while attampting query to some views got ORA-04023 - udump directory size increas
Size of some trace files in UDUMP directory were more then 200M.
So, what's in UDUMP "big" trace file?... Something like this:
........
kksfbc: entering diagnosis mode for xsc:110a65f48
CUR#4 XSC 110a65f48 CHILD#49 CI 0 CTX 0
Compilation environment difference Failed sharing : 0
Change in cursor environment
SQL pgadep:0 pgapls:0 user
Reparse from kzp.c-1296
LIBRARY OBJECT HANDLE: handle=700000125c3baa8 mtx=700000125c3bbd8(0) lct=500118 pct=500121 cdp=0
name=ASUPPP.MENU_MENU
hash=b823edba89e14a29b261f413e378445c timestamp=03-13-2012 09:38:36
namespace=TABL flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0000-0709-272b lock=S pin=S latch#=1 hpc=06ee hlc=06ee
lwt=700000125c3bb50[700000125c3bb50,700000125c3bb50] ltm=700000125c3bb60[700000125c3bb60,700000125c3bb60]
pwt=700000125c3bb18[700000125c3bb18,700000125c3bb18] ptm=700000125c3bb28[700000125c3bb28,700000125c3bb28]
ref=700000125c3bb80[700000125c3bb80,700000125c3bb80] lnd=700000125c3bb98[700000125b791d0,700000125c3acf0]
LIBRARY OBJECT: object=700000125c3b628
type=VIEW flags=EXS/LOC[0005] pflags=[0000] status=VALD load=0
DEPENDENCIES: count=5 size=16
dependency# table reference handle position flags
----------- -------- --------- -------- -------- -------------------
0 700000125c3b4f8 700000125c3b168 700000125c3af38 0 DEP[01]
1 700000125c3b4f8 700000125c3b1c0 700000126b563f8 0 DEP[01]
2 700000125c3b4f8 700000125c3b218 700000126b560c0 0 DEP/INV[05]
3 700000125c3b4f8 700000125c3b270 700000125c3ac00 0 DEP[01]
4 700000125c3b4f8 700000125c3b2f8 700000125c3a8c8 0 DEP[01]
........
Pay attantion to the line ... DEP/INV[05]
[05] - namespcae - table/procedure
INV - invalid
So, I've got invalid dependent library cache object with handle 700000126b560c0
Fruther searching down in this trace file lead me to this:
.......
LIBRARY OBJECT HANDLE: handle=700000126b560c0 mtx=700000126b561f0(0) lct=756795 pct=61053 cdp=0
name=ASUPPP.TEXT_PODR
hash=5a7e0016c3ccd858042741869af8554e timestamp=03-27-2012 10:14:06
namespace=TABL flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0000-201d-201d lock=S pin=S latch#=8 hpc=0334 hlc=0334
lwt=700000126b56168[700000126b56168,700000126b56168] ltm=700000126b56178[70000011004f288,7000001060bd8c8]
pwt=700000126b56130[700000126b56130,700000126b56130] ptm=700000126b56140[700000126b56140,700000126b56140]
ref=700000126b56198[700000126b56198,700000126b56198] lnd=700000126b561b0[700000126b02768,700000126b564e8]
........
In fact ASUPPP.MENU_MENU it's a view that includes calls to function ASUPPP.TEXT_PODR function.
According to metalink ID 727384.1 this issue due to library objects timestamp mismatch. ASUPPP.MENU_MENU has timestamp=03-13-2012 09:38:36
but ASUPPP.TEXT_PODR has timestamp=03-27-2012 10:14:06 and though parent object TEXT_PODR has timestamp newly than MENU_MENU.
What to do? Metalink states that this problem can be solved in several ways:
- alter view ASUPPP.MENU_MENU compile; -- in my case didn't solve problem and give me ORA-04023
- runing UTLRP.SQL -- recompile invalid objects. I think it also may not work, because both objects (MENU_MENU, TEXT_PODR) have VALID
status in DBA_OBJECTS.
- CREATE OR REPLACE VIEW ASUPPP.MENU_MENU ... ; -- worked fine in my case
- alter system flush SHARED_POOL;
It could be usefull to run periodicaly:
select do.obj# d_obj,do.name d_name, do.type# d_type, po.obj# p_obj,po.name p_name, to_char(p_timestamp,'DD-MON-YYYY HH24:MI:SS') "P_Timestamp", to_char(po.stime ,'DD-MON-YYYY HH24:MI:SS') "STIME", decode(sign(po.stime-p_timestamp),0,'SAME','*DIFFER*') X from sys.obj$ do, sys.dependency$ d, sys.obj$ po where P_OBJ#=po.obj#(+) and D_OBJ#=do.obj# and do.status=1 /*dependent is valid*/ and po.status=1 /*parent is valid*/ and po.stime!=p_timestamp /*parent timestamp not match*/ order by 2,1;If there's no any timestamp mismatch then this query returns no rows. Otherwise recompile or recreate displayed objects.
Oracle Metalink ID:
10373013.8
727384.1
444985.1