Friday, March 30, 2012

ORA-04023, big trace files in UDUMP

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:
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