Library cache pin when accessing apex_application_page_regions

Hi,
Oracle 11.2.0.3.0, APEX 4.1.1.00.23.
I am trying to compile a procedure that access apex_application_page_regions to get the region source of a report :
BEGIN
     -- get report region source
     SELECT region_source
          INTO l_source
          FROM apex_application_page_regions
      WHERE application_id = p_app_id
           AND page_id = p_app_page_id
           AND static_id = p_report;
END;I can't compile the procedure. After some time I get ORA-04021: timeout occured while waiting to lock object.
From v$session :
STATUS     SERVER          PROGRAM          SQL_EXEC_START          BLOCKING_SESSION_STATUS     BLOCKING_INSTANCE     BLOCKING_SESSION     EVENT               P1TEXT          WAIT_CLASS     STATE
ACTIVE     DEDICATED     plsqldev.exe     07/02/2012 09:12:52     VALID               1               971               library cache pin     handle address     Concurrency     WAITINGI am forced to ask developers to close all APEX instances to kill sessions, to be able to compile the procedure...
Is there any way to bypass this ?
Thank you.
Yann.

Yann39 wrote:
Hi,
Oracle 11.2.0.3.0, APEX 4.1.1.00.23.
I am trying to compile a procedure that access apex_application_page_regions to get the region source of a report :
BEGIN
     -- get report region source
     SELECT region_source
          INTO l_source
          FROM apex_application_page_regions
      WHERE application_id = p_app_id
           AND page_id = p_app_page_id
           AND static_id = p_report;
END;I can't compile the procedure. After some time I get ORA-04021: timeout occured while waiting to lock object.
From v$session :
STATUS     SERVER          PROGRAM          SQL_EXEC_START          BLOCKING_SESSION_STATUS     BLOCKING_INSTANCE     BLOCKING_SESSION     EVENT               P1TEXT          WAIT_CLASS     STATE
ACTIVE     DEDICATED     plsqldev.exe     07/02/2012 09:12:52     VALID               1               971               library cache pin     handle address     Concurrency     WAITINGI am forced to ask developers to close all APEX instances to kill sessions, to be able to compile the procedure...
Is there any way to bypass this ?
Thank you.
Yann.I previously had a problem similar to this. (Un)fortunately, the issue appeared to solve itself...
Library Cache Pin Wait Event (within the context of APEX)

Similar Messages

  • Library Cache Pin Wait Event (within the context of APEX)

    Hello,
    Firstly -
    Oracle Version: 10.2.0.4.0
    Apex Version: 3.0.1.00.08
    Okay, my colleague (no really! This isn't one of those "Ahem ... A friend of mine has contracted something nasty +downstairs+..."-type questions) is having problems compiling a package (using TOAD incidentally, but it's the same in SQL Developer).
    I've searched the forum and the web for a bit of help on what's maybe happening here and it appears to be related to a concurrency conflict with the package definition - from what I can understand it's a case of the package is in use by another session, therefore another session cannot alter it at the same time (which makes sense)
    "What does this have to do with APEX?"... well, he is working on this package using the following methodology:
    1. Compile the package body/spec (as necessary - body more often obviously)
    2. run an apex page which uses the code in a process, which may or may not result in the error page being displayed
    3. Making changes to the package body/spec
    repeat steps 1-3 ad nauseum...
    He is the only user directly accessing the schema (and the only user accessing the page via APEX too, although I appreciate this isn't quite the same thing).
    I was wondering if, due to the architecture of APEX (the use of session pools etc), the state of a package might be being retained in some manner, thus resulting in this library cache pin wait event? If so, is there anything I can do to mitigate against this occurring?
    p.s. the only difference I can see between this particular package and any other package in the schema is that this one interacts with blobs (including making references to the wwv_flow_files view) - with blobs being passed as parameters between procedures (thus potentially creating temporary blobs which may or may not being closed).
    Any ideas?
    p.p.s. there are also no DBMS_SCHEDULER jobs or anything that might potentially be running the code incidentally...
    Edited by: Joel_C on 11-Nov-2011 11:58
    We got our DBAs to run a bit of code to identify the blocking session:
    select
             decode(lob.kglobtyp, 0, 'NEXT OBJECT', 1, 'INDEX', 2, 'TABLE', 3, 'CLUSTER',
                          4, 'VIEW', 5, 'SYNONYM', 6, 'SEQUENCE',
                          7, 'PROCEDURE', 8, 'FUNCTION', 9, 'PACKAGE',
                          11, 'PACKAGE BODY', 12, 'TRIGGER',
                          13, 'TYPE', 14, 'TYPE BODY',
                          19, 'TABLE PARTITION', 20, 'INDEX PARTITION', 21, 'LOB',
                          22, 'LIBRARY', 23, 'DIRECTORY', 24, 'QUEUE',
                          28, 'JAVA SOURCE', 29, 'JAVA CLASS', 30, 'JAVA RESOURCE',
                          32, 'INDEXTYPE', 33, 'OPERATOR',
                          34, 'TABLE SUBPARTITION', 35, 'INDEX SUBPARTITION',
                          40, 'LOB PARTITION', 41, 'LOB SUBPARTITION',
                          42, 'MATERIALIZED VIEW',
                          43, 'DIMENSION',
                          44, 'CONTEXT', 46, 'RULE SET', 47, 'RESOURCE PLAN',
                          48, 'CONSUMER GROUP',
                          51, 'SUBSCRIPTION', 52, 'LOCATION',
                          55, 'XML SCHEMA', 56, 'JAVA DATA',
                          57, 'SECURITY PROFILE', 59, 'RULE',
                          62, 'EVALUATION CONTEXT',
                         'UNDEFINED') object_type,
             lob.KGLNAOBJ object_name,
             pn.KGLPNMOD lock_mode_held,
             pn.KGLPNREQ lock_mode_requested,
             ses.sid,
             ses.serial#,
             ses.username
        FROM
           x$kglpn pn,
           v$session ses,
           x$kglob lob,
           v$session_wait vsw
      WHERE
       pn.KGLPNUSE = ses.saddr and
       pn.KGLPNHDL = lob.KGLHDADR
       and lob.kglhdadr = vsw.p1raw
       and vsw.event = 'library cache pin'
    order by lock_mode_held descresults as follows (I've changed some object names to protect the ignorant):
    OBJECT_TYP OBJECT_NAME                   LOCK_MODE_HELD LOCK_MODE_REQUESTED        SID    SERIAL# USERNAME
    PACKAGE    PKG_FOOBAR                             2                   0        356      21694 HTMLDB_PUBLIC_U
                                                                                                      SER
    PACKAGE    PKG_FOOBAR                             0                   3        463      22309 FOOHTMLDB_PUBLIC_USER is the apex user incidentally. The session is marked in the v$session table as "inactive", the last statement being
    Begin
       Dbms_session.reset_package;
    End;Edited by: Joel_C on 11-Nov-2011 14:39

    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"

  • What is the difference between the library cache pin and the library ...?

    What is the difference between the library cache pin and the library cache lock ?
    What is the relation between them?

    Jonathan Lewis has a nice summary of these two items:
    {message:id=2079008}

  • 先library cache pin还是先library cache lock??

    Question from Oracler:
    session1 给test 建主键
    session2 select test 出现library cache lock
    session3 select test 出现library cache pin
    不是说先获得library cache lock再library cache pin吗
    session1以exclusive模式获得 library cache lock
    session2 以shared模式请求 library cache lock ,session1未释放,所以session2 wait
    那session3 什么解释呢????

    as maclean answer:
    SQL> select * from V$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
    PL/SQL Release 10.2.0.1.0 - Production
    CORE    10.2.0.1.0      Production
    TNS for Linux: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    session A  SQL> alter table maclean add a10 char(2000) default 'maclean';
    session B:  select 1 from maclean where rownum=1;      ==> hang here !
    session C:  select 1 from maclean where rownum=1;   ==> SAME SQL, hang here !
    SQL> select event from v$session where event like 'library%';
    EVENT
    library cache lock
    library cache pin
    session 4:
    SQL> oradebug setmypid;
    Statement processed.
    SQL> oradebug dump systemstate 266;
    Statement processed.
    SQL> oradebug tracefile_name;
    /s01/admin/G10R21/udump/g10r21_ora_6208.trc
        SO: 0x84f5b4a8, type: 4, owner: 0x84e5d4f8, flag: INIT/-/-/0x00
        (session) sid: 142 trans: (nil), creator: 0x84e5d4f8, flag: (41) USR/- BSY/-/-/-/-/-
                  DID: 0001-0010-00000027, short-term DID: 0000-0000-00000000
                  txn branch: (nil)
                  oct: 3, prv: 0, sql: 0x7bf10088, psql: 0x7bf582f0, user: 0/SYS
        O/S info: user: oracle, term: pts/1, ospid: 6159, machine: vrh8.oracle.com
                  program: [email protected] (TNS V1-V3)
        application name: [email protected] (TNS V1-V3), hash value=0
        waiting for 'library cache lock' blocking sess=0x(nil) seq=23 wait_time=0 seconds since wait started=17
                    handle address=7c3a5560, lock address=8003b350, 100*mode+namespace=c9
        Dumping Session Wait History
         for 'library cache lock' count=1 wait_time=2149666
                    handle address=7c3a5560, lock address=8003b350, 100*mode+namespace=c9
         for 'library cache lock' count=1 wait_time=2930643
                    handle address=7c3a5560, lock address=8003b350, 100*mode+namespace=c9
         for 'library cache lock' count=1 wait_time=2930300
                    handle address=7c3a5560, lock address=8003b350, 100*mode+namespace=c9
         for 'library cache lock' count=1 wait_time=2930715
                    handle address=7c3a5560, lock address=8003b350, 100*mode+namespace=c9
         for 'library cache lock' count=1 wait_time=2930545
                    handle address=7c3a5560, lock address=8003b350, 100*mode+namespace=c9
         for 'library cache lock' count=1 wait_time=2929985
    session 142 is  B  waiting for library cache lock
    the lock handle address is 7c3a5560
            SO: 0x8003b350, type: 53, owner: 0x84f98ba0, flag: INIT/-/-/0x00
            LIBRARY OBJECT LOCK: lock=8003b350 handle=7c3a5560 request=S
            call pin=(nil) session pin=(nil) hpc=0005 hlc=0000
            htl=0x8003b3d0[0x7d034330,0x7d034330] htb=0x7d034330 ssga=0x7e9f2168
            user=84f5b4a8 session=84f5b4a8 count=0 flags=RES/[0010] savepoint=0x1f9
            LIBRARY OBJECT HANDLE: handle=7c3a5560 mutex=0x7c3a5690(0)
            name=SYS.MACLEAN
            hash=458787ae49fd6f284ccb04a892b38231 timestamp=02-09-2012 21:32:36
            namespace=TABL flags=KGHP/TIM/SML/[02000000]
            kkkk-dddd-llll=0000-0701-0701 lock=X pin=X latch#=3 hpc=0006 hlc=0004
            lwt=0x7c3a5608[0x8003b380,0x8003b380] ltm=0x7c3a5618[0x7c3a5618,0x7c3a5618]
            pwt=0x7c3a55d0[0x7c3a55d0,0x7c3a55d0] ptm=0x7c3a55e0[0x7c3a55e0,0x7c3a55e0]
            ref=0x7c3a5638[0x7c3a5638,0x7c3a5638] lnd=0x7c3a5650[0x7bf75a18,0x7bf90650]
              LIBRARY OBJECT: object=7c1dec60
              type=TABL flags=EXS/LOC/UPD[0905] pflags=[0000] status=VALD load=0
              DATA BLOCKS:
              data#     heap  pointer    status pins change whr
                  0 7c3a54a0 7c1ded78 I/P/A/-/-    0 NONE   00
                  8 7c1de7f0 7e33ed48 I/P/A/-/-    1 UPDATE 00
                  9 7c1de8c0 7bf109e8 I/P/A/-/-    1 NONE   00
                 10 7c1de948 7bf10600 I/P/A/-/-    1 NONE   00
    关于session B的 library cache lock , 其原因是 add column 的session A 以 X mode lock SYS.MACLEAN, X mode pin  SYS.MACLEAN 且不释放, 所以session B的 library cache lock不用多解释
    session C:
        SO: 0x84f5dd18, type: 4, owner: 0x84e5dce0, flag: INIT/-/-/0x00
        (session) sid: 144 trans: (nil), creator: 0x84e5dce0, flag: (41) USR/- BSY/-/-/-/-/-
                  DID: 0001-0011-0000000A, short-term DID: 0000-0000-00000000
                  txn branch: (nil)
                  oct: 3, prv: 0, sql: 0x7bf10088, psql: 0x7bf582f0, user: 0/SYS
        O/S info: user: oracle, term: pts/2, ospid: 6183, machine: vrh8.oracle.com
                  program: [email protected] (TNS V1-V3)
        application name: [email protected] (TNS V1-V3), hash value=0
        waiting for 'library cache pin' blocking sess=0x(nil) seq=19 wait_time=0 seconds since wait started=17
                    handle address=7bf46e40, pin address=7f03f890, 100*mode+namespace=c8
        Dumping Session Wait History
         for 'library cache pin' count=1 wait_time=2568684
                    handle address=7bf46e40, pin address=7f03f890, 100*mode+namespace=c8
         for 'library cache pin' count=1 wait_time=2930677
                    handle address=7bf46e40, pin address=7f03f890, 100*mode+namespace=c8
         for 'library cache pin' count=1 wait_time=2929805
                    handle address=7bf46e40, pin address=7f03f890, 100*mode+namespace=c8
         for 'library cache pin' count=1 wait_time=2931420
                    handle address=7bf46e40, pin address=7f03f890, 100*mode+namespace=c8
         for 'library cache pin' count=1 wait_time=2930258
                    handle address=7bf46e40, pin address=7f03f890, 100*mode+namespace=c8
    session 144 is session C , waiting for library cache pin
    handle address 7bf46e40=>  指向 一个 child cursor namespace=CRSR, 而这个child cursor已经被 session B pin住了:
          SO: 0x7f03f890, type: 54, owner: 0x84f5dd18, flag: INIT/-/-/0x00
          LIBRARY OBJECT PIN: pin=7f03f890 handle=7bf46e40 request=S lock=0
          user=84f5dd18 session=84f5dd18 count=0 mask=0000 savepoint=0x3f flags=[00]
          SO: 0x7ec4cc80, type: 53, owner: 0x84f5dd18, flag: INIT/-/-/0x00
          LIBRARY OBJECT LOCK: lock=7ec4cc80 handle=7bf46e40 mode=N
          call pin=(nil) session pin=(nil) hpc=0000 hlc=0000
          htl=0x7ec4cd00[0x7e449348,0x80c35108] htb=0x80c35108 ssga=0x80c34ff0
          user=84f5dd18 session=84f5dd18 count=1 flags=[0000] savepoint=0x0
          LIBRARY OBJECT HANDLE: handle=7bf46e40 mutex=0x7bf46f70(0)
          namespace=CRSR flags=RON/KGHP/PN0/[10010000]
          kkkk-dddd-llll=0000-0001-0000 lock=N pin=X latch#=3 hpc=0004 hlc=0004
          lwt=0x7bf46ee8[0x7bf46ee8,0x7bf46ee8] ltm=0x7bf46ef8[0x7bf46ef8,0x7bf46ef8]
          pwt=0x7bf46eb0[0x7f03f8c0,0x7f03f8c0] ptm=0x7bf46ec0[0x7bf46ec0,0x7bf46ec0]
          ref=0x7bf46f18[0x7bf7bfe0,0x7bf7bfe0] lnd=0x7bf46f30[0x7bf46f30,0x7bf46f30]
            LIBRARY OBJECT: object=7bf29018
            type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
            READ ONLY DEPENDENCIES: count=1 size=16
            DATA BLOCKS:
            data#     heap  pointer    status pins change whr
                0 7bf20060 7bf28ba8 I/P/A/-/-    0 NONE   00
                6 7bf77a20 7bf776f8 I/P/A/-/-    1 NONE   00
    我们可以找到 上面这个child cursor 的 parent cursor :
          SO: 0x7d03b620, type: 53, owner: 0x84f5b4a8, flag: INIT/-/-/0x00
          LIBRARY OBJECT LOCK: lock=7d03b620 handle=7bf10088 mode=N
          call pin=(nil) session pin=(nil) hpc=0000 hlc=0000
          htl=0x7d03b6a0[0x7d034030,0x7c03c9f8] htb=0x7d034030 ssga=0x7e9f2168
          user=84f5b4a8 session=84f5b4a8 count=1 flags=[0000] savepoint=0x1f7
          LIBRARY OBJECT HANDLE: handle=7bf10088 mutex=0x7bf101b8(0)
          name=select 1 from maclean where rownum=1
          hash=324793c639b13d0954bd5421eaed6701 timestamp=03-08-2012 02:29:24
          namespace=CRSR flags=RON/KGHP/TIM/KEP/PN0/SML/DBN/[12010044]
          kkkk-dddd-llll=0001-0001-0001 lock=N pin=0 latch#=3 hpc=0004 hlc=0004
          lwt=0x7bf10130[0x7bf10130,0x7bf10130] ltm=0x7bf10140[0x7bf10140,0x7bf10140]
          pwt=0x7bf100f8[0x7bf100f8,0x7bf100f8] ptm=0x7bf10108[0x7bf10108,0x7bf10108]
          ref=0x7bf10160[0x7bf10160,0x7bf10160] lnd=0x7bf10178[0x82f4f2f8,0x7bf4d608]
            LIBRARY OBJECT: object=7bf7c8a8
            type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
            CHILDREN: size=16
            child#    table reference   handle
                 0 7bf7c370  7bf7bfe0 7bf46e40                           => 只有一个child  handle 7bf46e40                          
            DATA BLOCKS:
            data#     heap  pointer    status pins change whr
                0 7bf2a428 7bf7c9c0 I/P/A/-/-    0 NONE   00即在session B parse SQL "select 1 from maclean where rownum=1" 的时候, 会生成一个child cursor 并 X mode pin住这个child cursor , 而session C 同时发起 一样的SQL语句 "select 1 from maclean where rownum=1" 时 需要 share 这个child cursor , 即以 S mode pin 这个child cursor , 但是session B 还没有完成 optimize 没有生成完整的child cursor , 需要等待 session A 释放 library cache lock才能 完成, 所以 session C 要等 session B build child cursor , 此时session C等" library cache pin" ;
    如果 session C 执行的是不一样的SQL,那么 session C 不share 同一个child cursor , session C 会wait for library cache lock.
    since 10.2.0.3 "_kks_use_mutex_pin"=TRUE or 11g 开始 使用mutex 保护cursor pin ,所以 session C 若执行 与session B 一样的SQL,那么 wiat for cursor pin S on X
    SQL> select * from V$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    PL/SQL Release 11.2.0.3.0 - Production
    CORE 11.2.0.3.0 Production
    TNS for Linux: Version 11.2.0.3.0 - Production
    NLSRTL Version 11.2.0.3.0 - Production
    session A:
    SQL> alter table test add t11 char(2000) default 'maclean';
    session B:
    SQL> select * from test where rownum=1;
    session C:
    SQL> select * from test where rownum=1;
    SQL> select event from v$session where wait_class='Concurrency';
    EVENT
    cursor: pin S wait on X
    library cache lock
    SQL> oradebug setmypid;
    Statement processed.
    SQL> oradebug dump systemstate 266;
    Statement processed.
    session C:
    SO: 0x9e2256b8, type: 4, owner: 0x9e59a1c0, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
    proc=0x9e59a1c0, name=session, file=ksu.h LINE:12624, pg=0
    (session) sid: 179 ser: 41307 trans: (nil), creator: 0x9e59a1c0
    flags: (0x41) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
    flags2: (0x40009) -/-/INC
    DID: , short-term DID:
    txn branch: (nil)
    oct: 3, prv: 0, sql: 0x956e18b8, psql: 0x956e18b8, user: 0/SYS
    ksuxds FALSE at location: 0
    service name: SYS$USERS
    client details:
    O/S info: user: oracle, term: pts/3, ospid: 26823
    machine: vrh1.oracle.com program: [email protected] (TNS V1-V3)
    application name: [email protected] (TNS V1-V3), hash value=1481565533
    Current Wait Stack:
    0: waiting for 'cursor: pin S wait on X'
    idn=0xe76d0d8c, value=0xca00000000, where=0x500000000
    wait_id=17 seq_num=18 snap_id=1
    wait times: snap=12.671273 sec, exc=12.671273 sec, total=12.671273 sec
    wait times: max=infinite, heur=12.671273 sec
    wait counts: calls=1148 os=1148
    in_wait=1 iflags=0x15b2
    There is at least one session blocking this session.
    Dumping 1 direct blocker(s):
    inst: 1, sid: 202, ser: 15511
    Dumping final blocker:
    inst: 1, sid: 9, ser: 1
    Wait State:
    fixed_waits=0 flags=0x22 boundary=(nil)/-1
    idn=0xe76d0d8c=> 这个是mutex的标示
    KGX Atomic Operation Log 0x94aa8ca8
    Mutex 0x8a328978(202, 0) idn e76d0d8c oper GET_SHRD
    Cursor Pin uid 179 efd 0 whr 5 slp 1148
    opr=2 pso=0x8b5a8c48 flg=0
    pcs=0x8a3288e0 nxt=(nil) flg=35 cld=1 hd=0x93d4bbb8 par=0x8a328048
    ct=1 hsh=0 unp=(nil) unn=0 hvl=8a328ef0 nhv=1 ses=0x9e1e0ea0
    hep=0x8a328978 flg=80 ld=1 ob=0x939a30b0 ptr=0x935e0348 fex=0x935df6f0
    这个mutex的 oper是 GET_SHRD 即 pin S 它指向 0x93d4bbb8 是一个child cursor
    以下是parent cursor:
    SO: 0x957fa9d8, type: 78, owner: 0x9e1e0ea0, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
    proc=0x9e593da0, name=LIBRARY OBJECT LOCK, file=kgl.h LINE:8547, pg=0
    LibraryObjectLock: Address=0x957fa9d8 Handle=0x956e18b8 Mode=N CanBeBrokenCount=1 Incarnation=1 ExecutionCount=0
    User=0x9e1e0ea0 Session=0x9e1e0ea0 ReferenceCount=1 Flags=CNB/[0001] SavepointNum=4f5864b8
    LibraryHandle: Address=0x956e18b8 Hash=e76d0d8c LockMode=N PinMode=0 LoadLockMode=0 Status=VALD
    ObjectName: Name=select * from test where rownum=1
    FullHashValue=7e277fabf95d7c80e8924ed6e76d0d8c Namespace=SQL AREA(00) Type=CURSOR(00) Identifier=3882683788 OwnerIdn=0
    Statistics: InvalidationCount=1 ExecutionCount=2 LoadCount=3 ActiveLocks=2 TotalLockCount=4 TotalPinCount=1
    Counters: BrokenCount=1 RevocablePointer=1 KeepDependency=1 BucketInUse=3 HandleInUse=3 HandleReferenceCount=0
    Concurrency: DependencyMutex=0x956e1968(0, 2, 0, 0) Mutex=0x956e19e8(0, 45, 0, 0)
    Flags=RON/PIN/TIM/PN0/DBN/[10012841]
    WaitersLists:
    Lock=0x956e1948[0x956e1948,0x956e1948]
    Pin=0x956e1928[0x956e1928,0x956e1928]
    LoadLock=0x956e19a0[0x956e19a0,0x956e19a0]
    Timestamp: Current=03-08-2012 02:45:45
    HandleReference: Address=0x956e1a78 Handle=(nil) Flags=[00]
    LibraryObject: Address=0x8a327fa8 HeapMask=0000-0001-0001-0000 Flags=EXS[0000] Flags2=[0000] PublicFlags=[0000]
    ChildTable: size='16'
    Child: id='0' Table=0x8a328e58 Reference=0x8a3288b8 Handle=0x956db988
    Child: id='1' Table=0x8a328e58 Reference=0x8a328b80 Handle=0x93d4bbb8
    NamespaceDump:
    Parent Cursor: sql_id=fj4kfuvmqu3cc parent=0x8a328048 maxchild=2 plk=y ppn=n
    但是很可惜 0x93d4bbb8 这个 child cursor 被 session B pin住了:
    SO: 0x957fa8d8, type: 78, owner: 0x9e1e0ea0, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
    proc=0x9e593da0, name=LIBRARY OBJECT LOCK, file=kgl.h LINE:8547, pg=0
    LibraryObjectLock: Address=0x957fa8d8 Handle=0x93d4bbb8 Mode=N CanBeBrokenCount=1 Incarnation=1 ExecutionCount=0
    ClusterLock=0x8f1945f8 Context=0x7fd379518308 User=0x9e1e0ea0 Session=0x9e1e0ea0 ReferenceCount=1
    Flags=CBK/[0020] SavepointNum=0
    LibraryHandle: Address=0x93d4bbb8 Hash=0 LockMode=N PinMode=X LoadLockMode=0 Status=VALD
    Name: Namespace=SQL AREA(00) Type=CURSOR(00)
    Statistics: InvalidationCount=0 ExecutionCount=0 LoadCount=1 ActiveLocks=2 TotalLockCount=2 TotalPinCount=3
    Counters: BrokenCount=1 RevocablePointer=1 KeepDependency=0 BucketInUse=0 HandleInUse=0 HandleReferenceCount=0
    Concurrency: DependencyMutex=0x93d4bc68(0, 0, 0, 0) Mutex=0x956e19e8(0, 45, 0, 0)
    Flags=RON/PIN/PN0/EXP/CHD/[10012111]
    WaitersLists:
    Lock=0x93d4bc48[0x93d4bc48,0x93d4bc48]
    Pin=0x93d4bc28[0x93d4bc28,0x93d4bc28]
    LoadLock=0x93d4bca0[0x93d4bca0,0x93d4bca0]
    LibraryObject: Address=0x939a30b0 HeapMask=0000-0001-0001-0000 Flags=EXS[0000] Flags2=[0000] PublicFlags=[0000]
    DataBlocks:
    Block: #='0' name=KGLH0^e76d0d8c pins=0 Change=NONE
    Heap=0x93d1a808 Pointer=0x939a3150 Extent=0x939a3030 Flags=I/-/P/A/-/-
    FreedLocation=0 Alloc=1.546875 Size=4.000000 LoadTime=4385736620
    Block: #='6' name=SQLA^e76d0d8c pins=0 Change=NONE
    Heap=0x8a328a20 Pointer=0x935e0348 Extent=0x935df6f0 Flags=I/-/P/A/-/E
    FreedLocation=0 Alloc=0.000000 Size=0.000000 LoadTime=0
    NamespaceDump:
    Child Cursor: Heap0=0x939a3150 Heap6=0x935e0348 Heap0 Load Time=03-08-2012 02:50:16 Heap6 Load
    PinMode=X
    保持这个 X mode pin的是另外一个 mutex , 这个mutex的 oper是 LONG_EXCL
    Time=03-08-2012 02:50:16 ----------------------------------------
    KGX Atomic Operation Log 0x8f1945f8
    Mutex 0x8a328978(202, 0) idn e76d0d8c oper LONG_EXCL
    Cursor Pin uid 202 efd 0 whr 1 slp 0
    opr=3 pso=0x957fa8d8 flg=0
    pcs=0x8a3288e0 nxt=(nil) flg=35 cld=1 hd=0x93d4bbb8 par=0x8a328048
    ct=1 hsh=0 unp=(nil) unn=0 hvl=8a328ef0 nhv=1 ses=0x9e1e0ea0
    hep=0x8a328978 flg=80 ld=1 ob=0x939a30b0 ptr=0x935e0348 fex=0x935df6f0

  • 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).

  • Sessions hangs with library cache lock

    Der all,
    11.1.0.7 rac on solaris 10
    Our workflow session yesterday hanged on a particular step the session was waiting on a library cache lock (by using query select event,p1,p2 from v$session where sid=<my_sid>;)
    when I checked the blocking session , using the note 122793.1 and http://oracle-study-notes.blogspot.com/2009/05/resolving-library-cache-lock-issue.html and http://oracle-study-notes.blogspot.com/2009/05/find-session-holding-library-cache-lock.html .
    I found that
    SQL> SELECT SID,USERNAME,TERMINAL,PROGRAM FROM V$SESSION
      2   WHERE SADDR in
      3    (SELECT KGLLKSES FROM X$KGLLK LOCK_A
      4     WHERE KGLLKREQ > 0
      5       AND EXISTS (SELECT LOCK_B.KGLLKHDL FROM X$KGLLK LOCK_B
                     WHERE KGLLKSES = '&SADDR_OF_BLKING_SESS'
      6    7                   AND LOCK_A.KGLLKHDL = LOCK_B.KGLLKHDL
      8                   AND KGLLKREQ = 0)
      9    );
    Enter value for saddr_of_blking_sess: 0000000770E494E0
    old   6:                  WHERE KGLLKSES = '&SADDR_OF_BLKING_SESS'
    new   6:                  WHERE KGLLKSES = '0000000770E494E0'
      SID USERNAME        TERMINAL   PROGRAM
      817 SYS             UNKNOWN    oracle@tabsdb07
                                      (J002)
      828 SYS             UNKNOWN    oracle@tabsdb07
                                      (J001)after killing the session, the library cache locks still remained.when I ran trace on the session
    select /*+ all_rows ordered */ A.rowid, :1, :2, :3
    from
    "DBMRPT"."DBM_BIAUTO_SUSP" A , "DBMRPT"."DBM_CDR_FILE_HEAD" B where(
      "A"."CDR_TYPE" is not null and "A"."FILE_ID" is not null) and(
      "B"."CDR_TYPE" (+)= "A"."CDR_TYPE" and "B"."FILE_ID" (+)= "A"."FILE_ID")
      and( "B"."CDR_TYPE" is null or "B"."FILE_ID" is null)
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.01       0.01          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.01       0.01          0          0          0           0
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: SYS   (recursive depth: 3)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      row cache lock                                  5        0.00          0.00
      db file sequential read                   295932636        0.07       5066.63
      gc cr grant 2-way                          727813        0.02        233.95
      latch: gc element                              80        0.00          0.00
      latch: gcs resource hash                      870        0.00          0.00
      latch free                                      2        0.00          0.00
      gc remaster                                     9        2.00         12.91
      gcs drm freeze in enter server mode             9        0.54          2.08
      latch: object queue header operation           66        0.00          0.05
      latch: cache buffers chains                    15        0.03          0.20
      resmgr:internal state change                   63        0.10          5.30
      latch: cache buffers lru chain               1260        0.00          0.01
    ********************************************************************************Please guide
    Kai
    all this time sql_id for the session remanined in the sql :
    ALTER TABLE DBMRPT.DBM_BIAUTO_SUSP ENABLE CONSTRAINT DBS1_DCFH_FK ..

    hi..
    Go through [http://orainternals.wordpress.com/2009/06/02/library-cache-lock-and-library-cache-pin-waits/]
    Anand

  • Library cache lock wait event

    Hi,
    I am experience hanging in my database. I am using 10.2.0.3 on Solaris 5.10.
    I am having automatic processes that drop the schema and recreate the schema and upload the new data. Since the last few days i am facing in hanging while dropping the schema. I checked and found "Library cache lock" event that caused other processes also in the hanged state. I am trying to find out the reason but not able to crack.
    Can some one advice me?
    Thanks

    Hi,
    There exists an concurrency problem with respect to the object - resource utilization.
    - One client can prevent other clients from accessing the same object
    - The client can maintain a dependency for a long time (for example, no other client can change the object)
    check the from v$session_wait (query taken from the http://www.dba-oracle.com/m_library_cache_pin.htm - for your reference)
    select decode(lob.kglobtyp, 0, 'NEXT OBJECT', 1, 'INDEX', 2, 'TABLE', 3, 'CLUSTER',
    4, 'VIEW', 5, 'SYNONYM', 6, 'SEQUENCE',
    7, 'PROCEDURE', 8, 'FUNCTION', 9, 'PACKAGE',
    11, 'PACKAGE BODY', 12, 'TRIGGER',
    13, 'TYPE', 14, 'TYPE BODY',
    19, 'TABLE PARTITION', 20, 'INDEX PARTITION', 21, 'LOB',
    22, 'LIBRARY', 23, 'DIRECTORY', 24, 'QUEUE',
    28, 'JAVA SOURCE', 29, 'JAVA CLASS', 30, 'JAVA RESOURCE',
    32, 'INDEXTYPE', 33, 'OPERATOR',
    34, 'TABLE SUBPARTITION', 35, 'INDEX SUBPARTITION',
    40, 'LOB PARTITION', 41, 'LOB SUBPARTITION',
    42, 'MATERIALIZED VIEW',
    43, 'DIMENSION',
    44, 'CONTEXT', 46, 'RULE SET', 47, 'RESOURCE PLAN',
    48, 'CONSUMER GROUP',
    51, 'SUBSCRIPTION', 52, 'LOCATION',
    55, 'XML SCHEMA', 56, 'JAVA DATA',
    57, 'SECURITY PROFILE', 59, 'RULE',
    62, 'EVALUATION CONTEXT',
    'UNDEFINED') object_type,
    lob.KGLNAOBJ object_name,
    pn.KGLPNMOD lock_mode_held,
    pn.KGLPNREQ lock_mode_requested,
    ses.sid,
    ses.serial#,
    ses.username
    FROM
    x$kglpn pn,
    v$session ses,
    x$kglob lob,
    v$session_wait vsw
    WHERE
    pn.KGLPNUSE = ses.saddr and
    pn.KGLPNHDL = lob.KGLHDADR
    and lob.kglhdadr = vsw.p1raw
    and vsw.event = 'library cache pin'
    order by lock_mode_held desc
    Resolution might - you need to check the time it takes (the script to drop the schema) and it loads - either doing from parallel sessions or in serial order. I doubt it, till the schema get dropped completely it should not be accessible to any other applications - either objects too, that makes the rise to concurrency Issue with respect to library cache waits - the other sessions are trying access the object.
    - Pavan Kumar N
    - ORACLE 9i/10g - OCP
    http://www.oracleinternals.blogspot.com

  • 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

  • 11g - 11.1.0.7.0 - 64bit PL/SQL library cahce pin issue

    We just upgraded our production a couple of months ago to 11.1.0.7.0 - 64bit and having a lots of fun :) The main issue we started to see is that we tried compiling the package the other day (the package which doesn't have any dependency at all) and it just got hung. We tried again the same thing again later and it just didn't compile and just got hung. Then later DBA called us saying that database had about 100 copies of the PL/SQL block in the memory that are trying to do library pin. At this point of time the database started to reject new connections therefore the application started to fail. Then we looked at the library pin and found 100s of the statement below - basically for the same package that we are trying to compile - we use the HTP package call to present the web page from PL/SQL. Any hint on what might have happened:
    - call that is generating the library cache pin wait events:
    declare
    rc__ number;
    simple_list__ owa_util.vc_arr;
    complex_list__ owa_util.vc_arr;
    begin
    owa.init_cgi_env(:n__,:nm__,:v__);
    htp.HTBUF_LEN := 255;
    null;
    null;
    simple_list__(1) := 'sys.%';
    simple_list__(2) := 'dbms\_%';
    simple_list__(3) := 'utl\_%';
    simple_list__(4) := 'owa\_%';
    simple_list__(5) := 'owa.%';
    simple_list__(6) := 'htp.%';
    simple_list__(7) := 'htf.%';
    simple_list__(8) := 'wpg_docload.%';
    if ((owa_match.match_pattern('cms.era_data_view.show', simple_list__, complex_list__, true))) then
    rc__ := 2;
    else
    null;
    null;
    cms.era_data_view.show(p_page=>:p_page);
    if (wpg_docload.is_file_download) then
    rc__ := 1;
    wpg_docload.get_download_file(:doc_info);
    null;
    null;
    null;
    commit;
    else
    rc__ := 0;
    null;
    null;
    null;
    commit;
    owa.get_page(:data__,:ndata__);
    end if;
    end if;
    :rc__ := rc__;
    end;

    Yes, and the SR# is 7592995.992 .. Please let me know if you have any ideas on this.

  • Library cache lock in statspack report

    Hi,
    We have some production issues on my database from long back. So i had taken snapshot and applied in one of analyzer tool.
    In the TOP 5 Events they mentioned that library cache lock is 94.46 % , i am afraiding by seeing this number. And in there analyzing report they didn't populate the recommendations.
    Please suggest me why the library cache lock showing 94.46%.
    And i am also adding the other statistics as well.
    Please go though and suggest me into right way.
    Top 5 Events
    Event     Percentage of Total Timed Events
    library cache lock      94.46%
    PX Deq: Table Q Normal      1.51%
    db file sequential read      1.23%
    direct path read      1.06%
    PX Deq Credit: send blkd      .55%
    Wait Events
    Event     Waits     Wait Time (s)     Avg Wait (ms)     Waits/txn
    library cache lock      45,777     137,044.09     2994     10.6
    PX Deq: Table Q Normal      1,263,860     2,196.88     2     292.2
    db file sequential read      80,826     1,780.39     22     18.7
    direct path read      244,968     1,543.45     6     56.6
    PX Deq Credit: send blkd      3,200,312     794.01     0     739.8
    PX Deq: Execute Reply      529     570.82     1079     0.1
    db file scattered read      42,356     524.47     12     9.8
    library cache pin      93     286.44     3080     0.0
    PX qref latch      96     90.05     938     0.0
    log file sync      4,685     71.9     15     1.1
    Instance Activity Stats
    Statistic     Total     per Second     per Trans
    SQL*Net roundtrips to/from client     277,935     975.2     64.3
    consistent gets      8,112,050     28,463.3     1,875.2
    db block changes      446,986     1,568.4     103.3
    execute count      31,369     110.1     7.3
    parse count (hard)      65     0.2     0.0
    parse count (total)      30,083     105.6     7.0
    physical reads      3,041,562     10,672.2     703.1
    physical reads direct      2,624,892     9,210.2     606.8
    physical writes      151,245     530.7     35.0
    physical writes direct      77,161     270.7     17.8
    redo writes      4,933     17.3     1.1
    session cursor cache hits      17,868     62.7     4.1
    sorts (disk)      2     0.0     0.0
    sorts (memory)      2,006     7.0     0.5
    table fetch continued row      72,024     252.7     16.7
    table scans (long tables)      323     1.1     0.1
    table scans (short tables)      3,371     11.8     0.8
    8 Recommendations:

    You need to figure out what session is holding the blocking library cache lock.
    Here's a script that will help you do that:
    select decode(lob.kglobtyp, 0, 'NEXT OBJECT', 1, 'INDEX', 2, 'TABLE', 3, 'CLUSTER',
    4, 'VIEW', 5, 'SYNONYM', 6, 'SEQUENCE',
    7, 'PROCEDURE', 8, 'FUNCTION', 9, 'PACKAGE',
    11, 'PACKAGE BODY', 12, 'TRIGGER',
    13, 'TYPE', 14, 'TYPE BODY',
    19, 'TABLE PARTITION', 20, 'INDEX PARTITION', 21, 'LOB',
    22, 'LIBRARY', 23, 'DIRECTORY', 24, 'QUEUE',
    28, 'JAVA SOURCE', 29, 'JAVA CLASS', 30, 'JAVA RESOURCE',
    32, 'INDEXTYPE', 33, 'OPERATOR',
    34, 'TABLE SUBPARTITION', 35, 'INDEX SUBPARTITION',
    40, 'LOB PARTITION', 41, 'LOB SUBPARTITION',
    42, 'MATERIALIZED VIEW',
    43, 'DIMENSION',
    44, 'CONTEXT', 46, 'RULE SET', 47, 'RESOURCE PLAN',
    48, 'CONSUMER GROUP',
    51, 'SUBSCRIPTION', 52, 'LOCATION',
    55, 'XML SCHEMA', 56, 'JAVA DATA',
    57, 'SECURITY PROFILE', 59, 'RULE',
    62, 'EVALUATION CONTEXT',
    'UNDEFINED') object_type,
    lob.KGLNAOBJ object_name,
    lk.KGLLKMOD lock_mode_held, lk.KGLLKREQ lock_mode_requested,
    ses.sid,
    ses.serial#,
    ses.username
    FROM
    x$kgllk lk,
    v$session ses,
    x$kglob lob,
    v$session_wait vsw
    WHERE
    lk.KGLLKUSE = ses.saddr and
    lk.KGLLKHDL = lob.KGLHDADR
    and lob.kglhdadr = vsw.p1raw
    and vsw.event = 'library cache lock'
    order by lock_mode_held desc
    -Mark

  • GATHER_STATS_JOB is causing library cache lock events (blocking)

    Hi,
    I am running an Oracle 10g (2.0.3) RAC configuration on a Solaris 5.10 SPARC-64 box, and a couple of days ago I started to receive blocking alert due a library cache lock even caused by the scheduled GATHER_STATS_JOB. Is there any way to identify which is the table/object that is not being able to be process by the GATHER_STATS_JOB?
    Regards,
    Alberto

    I found this on metalink:
    How to find the blocker
    a. find the p1raw value of the 'library cache pin', e.g.
    select sid, event, p1raw from v$session_wait where event = 'library cache pin';
    SID EVENT P1RAW
    150 library cache pin 288822D4
    select * from dba_kgllock where kgllkreq > 0;
    KGLLKUSE KGLLKHDL KGLLKMOD KGLLKREQ KGLL
    2CB1F978 288822D4 0 3 Pin
    b. find the locked object via x$kglob, e.g.
    select kglnaown, kglnaobj from x$kglob where kglhdadr = '288822D4';
    KGLNAOWN KGLNAOBJ
    SYS DUMMY

  • Library cache pi

    Hi All,
    DB :- 8.1.7.4.0
    OS HPUX
    I am using a dblink to query from remote session , but my query hangs and I just discovered that it is waiting for library cache pin. Any idea, why this is happening?
    and how can we resolve this issue. From my side, it seems , the target server cpu is fully exausted. I am not sure on this. One interesting thing is that tnsping is also hanging in that case. Also the target server in AS400 series
    13:24:43 SQL> select * from [email protected] ;
          1155 library cache pin                                                WAITING                         125
    13:45:53 SQL> /
           SID EVENT                                                            STATE               SECONDS_IN_WAIT
          1155 library cache pin                                                WAITING                         428
    13:50:47 SQL> /
           SID EVENT                                                            STATE               SECONDS_IN_WAIT
          1155 library cache pin                                                WAITING                         690
    prod01> tnsping S65C5DED.AP.ELCOMPANIES.NET
    TNS Ping Utility for HPUX: Version 8.1.7.4.0 - Production on 13-JUL-2011 12:28:02
    (c) Copyright 1997 Oracle Corporation.  All rights reserved.
    Attempting to contact (ADDRESS=(PROTOCOL=TCP)(HOST=10.81.1.1)(Port=1521))

    According to this document, does this mean, someone did a control c and that caused the scenario to occur. I am still wondering, why tnsping is falling apart?
    thankf for sharing this document. Now, everything goes to normal.
    14:00:22 SQL>  select * from [email protected] ;
    D
    X
    14:14:13 SQL> !tnsping S65C5DED.AP.ELCOMPANIES.NET
    TNS Ping Utility for HPUX: Version 8.1.7.4.0 - Production on 13-JUL-2011 14:15:15
    (c) Copyright 1997 Oracle Corporation.  All rights reserved.
    Attempting to contact (ADDRESS=(PROTOCOL=TCP)(HOST=10.81.1.1)(Port=1521))
    OK (400 msec)Edited by: user12021994 on Jul 13, 2011 11:15 AM

  • How can I access deleted photos from my iPhoto Library Cache?

    My Macbook Pro broke about a year ago and I recently took the hard drive out to access the files. I have a hard drive enclosure to USB to my Acer (Windows) Laptop. I was looking through all the folders when I came across this: D:\Users\Lizee\Library\Caches\Desktop\iPhoto Albums
    In this folder is a list of different albums I have had over the years and in the albums there are photo files, but I cannot view them! This gives me hope that maybe there is a way to salvage and get back some of the photos I once deleted! Please let me know if you know ANY way I can get any of these photos back... I will do anything!

    I don't believe there is any way to do what you want. These are not your photos.
    Regards
    TD

  • How can I access the iTunes store?  When I click on iTunes, my library appears but when I try to connect to the store I get a window saying Error -3221 has occured and cannot connect to the store.

    Can anyone please help!  I haven't been able to connect to the iTunes store to purchase music for some time now.  When I click on the iTunes icon my music library appears, but when I try to connect to the store (top RH side of window) I get a new window saying cannot connect to the store an erroe -3221 has occured.

    Baseal wrote:
    When I use her Earthlink email address to download apps or whatnot, it says I can't access teh itunes store. 
    When you say "her email address" do you mean that you set up a separate Apple ID for her using her email address as her Apple ID? If so, was it ever verified by Apple? Did she get the email verification?
    You might look here for some help.
    http://www.apple.com/support/appleid/

Maybe you are looking for

  • Printing contents are displayed in Adobe Reader for iOS

    Hello, I am currently generating PDF with Adobe LiveCycle ES2. I use Assembly Descriptor to add content in my documents. According to this descriptor, I insert PageContent with the attributes showOnScreen=false and showWhenPrinting=true to finally ha

  • I've deleted all my applications... how do I get them back?

    Well, after an overnight red-eye, a long day then an early start I managed to do something weird to my Pearl. Basically all my applications have gone... when I press the applications button I get a blank screen, all the applications down the lefthand

  • Diffrence in running oracle on 32 bit OS and 64 bit OS ?

    Hi , I am new to oracle , i would like to know what's the diffrence running oracle under 32 bit OS and 64 bit OS

  • Cannot download new order

    I ordered Elements and Premiere about 52 hours ago (2 days) and the refreshed order page still says "processing your order".  No way to get support here, so my next step if Adobe can't get their act together is to make a FRAUD claim with my credit ca

  • 3-D or Shadow effect

    I'm trying to either create a 3-D or Shadow effect on a table using either Dreamweaver or Fireworks. A good example of the shadow effect can be seen here - http://www.smartaffiliatesecrets.com/. Any help would be much appreciated. Thanks in advance,