IOS - Library/Cache - Database question

Hello there,
Some time ago I've read on this forum that the correct directory to use on iOS for storing data is Library/Cache and since then I've fixed my app to use that directory.
Here it is the link to an article written by "our" Saumitra:
http://www.saumitrabhave.com/2011/11/air-ios-solving-apps-must-follow-ios.html
My app has 2 db files (and some xml files).
The struct looks like this:
[root] my main app
├──data
│  └──dbtemplates  (this dir contains my two db files)
└──xml
   ├──en (this dir contains english localization)
   └──it (this dir contains italian localization)
When my app starts, it copies these 2 db files in Library/Cache directory and then the app fills them with data generated on the fly: from that moment my app will use these two new databases for reading and saving datas.
My questions are:
1) With this struct, is it true that my app won't be rejected by Apple? (I mean with data/dbtemplates, xml/it and xml/en subdirectories)
2) Is the Library/Cache the right directory to copy my new db in?
3) If Apple accepts my app, sooner or later I will develop an update to my app: in that case, if the user has not uninstalled my app, when he updates the app from the apple store, the db files that I stored in Library/Cache won't be deleted from the update process, true?
Unilt today I was pretty sure that the answers to my questions were "yes", "yes" and "yes" but today I've spoken with a friend of mine that told me that I need also to flag my dbfiles as "do not backup" and the only wat to accomplish this is to use a native extension:
http://www.jampot.ie/ane/ane-ios-data-storage-set-donotbackup-attribute-for-ios5-native-ex tension/
Can someone clear my doubts?
Thanks in advance

1) With this struct, is it true that my app won't be rejected by Apple? (I mean with data/dbtemplates, xml/it and xml/en subdirectories)
     Its seems absolutely fine. data and xml are the folders you package as assets right?
2) Is the Library/Cache the right directory to copy my new db in?
     As I see your use case, I think you should rather use the applicationStorageDirectory. Because thes files are essential for your application to work.
3) If Apple accepts my app, sooner or later I will develop an update to my app: in that case, if the user has not uninstalled my app, when he updates the app from the apple store, the db files that I stored in Library/Cache won't be deleted from the update process, true?
     No. As per Apple QnA "the entire <Application_Home>/Library directory has always been preserved during updates and backups, except for <Application_Home>/Library/Caches." See this . So if you store the XMLs in Caches they will be deleted but Not if you store them in applicationStorageDirectory which is (Library/Application Support/....) See recommended usage of this directory here
About "Do Not Backup Attribute".
As you can see that above link mentions adding the do not backup extended attribute to "Application Support". You should set it if you dont need those files to be backed up but, You should not set this attribute if it is essential for your application to have those files when restored from backup to function properly or get "restored" completely.

Similar Messages

  • Cleaning Media Cache Database Questions

    Does cleaning the Media Cache Database only delete the cache and database links for missing files in the current project? Or does it do it for all of your PPro projects located on your computer except the current project you have open?
    How do I delete the cache and database links on my Mac for projects that no longer exist? Apparently I can't see the Library directory to where PPro has my Media Cache pointing to. Can only see it if I go through Admin profile.
    Many thanks

    Bridge's database CAN be quite large, especially if one has a lot of material on the system, that goes into Bridge. I am always a bit surprised at how large those database files can be, over a year's usage.
    As I am using Bridge more on a Project basis, with the original Asset files on my NAS, or elsewhere, I can usually safely purge those, when they grow very large - I no longer need those, when the Projects are completed, and the Copies of my Assets are also Deleted from the system.
    Good luck,
    Hunt

  • Database buffer cache and library cache (order)

    hi
    after I issue:
    select * from employees where employee_id=98
    which one is performed by oracle first?
    Oracle looks database buffer cache for any block it needs.
    If block not found in database buffer cache ;server reads block from datafile and places copy in database buffer cache
    OR
    parse the sql and look in library cache for same execution plan ,.....

    Hi Ricardinho
    How does Oracle know which blocks it might need ? Does it need blocks from any indexes or does it only need blocks from a table ?
    Do you think it even remotely likely that Oracle will somehow get all the blocks it needs first and then worry about determining an execution plan at some later point in time ?
    Cheers
    Richard Foote
    http://richardfoote.wordpress.com/

  • SUP - 2 questions about the CDB (cache database)

    Hi,
    I have 2 questions about the cache database and the cache groups:
    1 - How does the "On demand" cache group policy exactly works? I know that online cache group is without storing any data on the CDB making direct requests to de backend from the device, the DCN is based on updating from the backend, the scheduled is based on a time period, but I don't understand how the "on demand" exactly works, and why it has a time period too.
    2 - Is it possible to query the cache database table to check the data that SUP has stored? How can I do this?
    Thank you!

    I posted a similar question in SUP Apps project not too long ago and  Paul Horan provided this useful reply:
    Create a "Sybase ASA v12.x for Unwired Server" connection profile in the Enterprise Explorer.  I named mine CDB.
    : Host = localhost (or whatever the machine name is)
    : Port = 5200
    : Database name = "default"
    : User Name = "dba"
    : Password = "sql"
    Obviously, change the userid/password to match, if you changed them during install time.
    Connect, and you'll see the "default" database displayed.
    Navigate down through the Tables folder, and the first subfolder is labeled something like [#should_delete_sk ...]  Start there.
    You'll see a bunch of tables with the naming convention "D1" + package name + package version + MBO name.  These are the cache tables for the MBOs.

  • 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

  • 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

  • To know if parsed SQL is in library cache and parse count

    hello,
    i want to know if a sql that was fired has its parsed code still in library cache. How do i know? One more question. I would also like to know how many times a sql is parsed and loaded onto library cache (assuming that I have its hash value)
    thank you in advance.

    V$DB_OBJECT_CACHE: To view displays database objects that are cached in the library cache.
    http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_1083.htm
    V$SQLAREA lists statistics on shared SQL area and contains one row per SQL string. It provides statistics on SQL statements that are in memory, parsed, and ready for execution.
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2129.htm
    select sql_text from v$sqlarea where users_executing > 0;

  • Library Cache Locks in 10g

    Hi,
    This is a question for Oracle 10g database -
    Does anyone know of a foolproof way of finding the session that is blocking another session with 'library cache lock'?
    It needs to work for RAC and non-RAC and the quicker the better :-)
    Thanks,
    Kevin

    Per Metalink Note 122793.1
    SELECT SID,USERNAME,TERMINAL,PROGRAM FROM V$SESSION
    WHERE SADDR in
      (SELECT KGLLKSES FROM X$KGLLK LOCK_A
       WHERE KGLLKREQ = 0
         AND EXISTS (SELECT LOCK_B.KGLLKHDL FROM X$KGLLK LOCK_B
                     WHERE KGLLKSES = 'saddr_from_v$session' /* BLOCKED SESSION */
                     AND LOCK_A.KGLLKHDL = LOCK_B.KGLLKHDL
                     AND KGLLKREQ > 0)
      );

  • 先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

  • How can I increase my Library Cache Hit Ratio?

    I was wondering if anyone can help me out regarding the values that I am getting for my Library Cache hits stats
    Half of the samples that I have taken on a periodic interval today have ranged from 89% to 96%.
    The SQL that I have used is,
    SELECT
    sysdate,
    SUM(PINS-RELOADS)/SUM(PINS)*100
    from v\$librarycache
    Also, Running the AWR report for 4am to 4pm, see below
    Shared Pool Statistics AWR report
                        Begin      End
    Memory Usage %:           50.83      42.43
    % SQL with executions>1:      55.56      77.13
    % Memory for SQL w/exec>1:      74.12
    Regarding the current SGA settings,
    SQL> show parameter sga_target;
    NAME TYPE VALUE
    sga_target big integer 1184M
    SQL>
    SQL> select pool,name,bytes/1048576 "Size in MB" from v$sgastat where name = 'free memory';
    POOL NAME Size in MB
    shared pool free memory 135.742641
    large pool free memory 15.9389648
    java pool free memory 16
    The main questions are,
    a) is the low Library cache hit ration particularly low?
    b) if I want to improve this figure, it is advised that the 'SHARED_POOL_SIZE' parameter should be increased.
    Obviously Oracle itself is in charge of this at present, so what can I do to improve?
    c) Are there any really good links to help me to understand the figures that appear in the AWR report.

    a) is the low Library cache hit ration particularly low?
    I didnt understand this.Can you please rephrase?
    b)
    Well indeed that shared pool controls the allocation and everything about Library Cache but it doesnt mean that increasing the value will stop all the issues.Its among the hardest parameters to be tuned infact for the reason that what primarly comes into it,sql statements,code and all that,that is not written entirely by a dba/tuner.Its by developers who does some times not so good things that are required to make shared pool work properly.Very commonly occuring mistake can be quoted as the lack of use of bind variabls and constant use of literals.In that case,eventualy we will have a hard parse of all the statements which will eat up the shared pool some time or the other.No matter what size it may be,it will end to the same result.Hit ratio is a guiding factor,not the end goal of tuning.Its been documented so many places,here,other forums,even in OU books also that looking and tuning alone the hit ratio may not end up at the expected or right results.You should look for the Parse statistics in the AWR report how they are working.How many are Parse(hard),Parse(total) statistics coming up?What is the sql execute to parse time,elapsed time and the related statistics.They will be helpful in getting things sorted out more nicely and correctly.
    I am sure I have missed so much than I said.Surely you will get more better advice on this.Have patience and wait.
    b)Documentation will be a good point.Performance tuning in that is a good resource.
    http://www.oracle.com/pls/db102/to_toc?pathname=server.102%
    2Fb14211%2Ftoc.htm&remark=portal+%28Getting+Started%29
    I am not sure about a specific book about AWR but this one is good for over all knowledge about tuning of Oracle.
    http://www.mcgraw-hill.co.uk/html/007222729X.html
    Aman....

  • Could not load library for database connection LCA

    Hi,
    I am facing RFC connection prblem while connectiong to database. I have installed SCM5.1 and live cache in single server
    Please find the logs.
    Work process log:
    B Mon Jul 20 11:19:13 2009
    B  create_con (con_name=LCA)
    B  Loading DB library 'E:\usr\sap\SC7\DVEBMGS03\exe\dbsdbslib.dll' ...
    M  *** ERROR => DlLoadLib: LoadLibrary(E:\usr\sap\SC7\DVEBMGS03\exe\dbsdbslib.dll) Error 126 [dlnt.c       241]
    M          Error 126 = "The specified module could not be found."
    B  *** ERROR => Couldn't load library 'E:\usr\sap\SC7\DVEBMGS03\exe\dbsdbslib.dll'
    [dbcon.c      4731]
    B  ***LOG BYG=> could not load library for database connection LCA        [dbds#1 @ 1035] [dbds    1035 ]
    A
    A Mon Jul 20 11:21:58 2009
    A  GENER starting remote generation: /SAPAPO/OM_SYNC_LC_DB (requested by W1).
    B
    SM21:
    No shared library found for the database with ID LCA|
    No shared library found for the database with ID LCA
    /SAPAPO/OM17|/SAPAPO/OM_SYNC_LC_DB|K |SAP Web AS Problem|SBAC   |
    Documentation for system log message BY G :
    As well as the standard connection, an attempt was made to set up
    another database connection, under the specified ID. The Shared Library
    for this second database could not be found.
    The Shared Library is usually found in the the Executable
    directory (profile parameter DIR_LIBRARY) under the name dbs
    <dbs>slib<os_ext>. <dbs> stands for the database type and <os_ext>
    stands for the operating system-specific extension of the Shared
    Libraries.
    The database type is determined from the entry that corresponds to the
    specified DB ID in the table DBDCON. Check whether the data in this
    entry is correct.
    ST22
    Runtime Errors         DBIF_DSQL2_CONNECTERR
    Exception              CX_SY_NATIVE_SQL_ERROR
    Date and Time          20.07.2009 11:22:21
    Short text
    Error setting up a secondary database connection
    What happened?
    Connection to database system not possible with identifier "LCA".
    |----
    System environment
    SAP-Release 700
    Application server... "
    Network address...... "
    Operating system..... "Windows NT"
    Release.............. "5.2"
    Hardware type........ "8x AMD64 Level"
    Character length.... 16 Bits
    Pointer length....... 64 Bits
    Work process number.. 8
    Shortdump setting.... "full"
    Database server... "
    Database type..... "ORACLE"
    Database name..... "SC7"
    Database user ID.. "SAPSC7"
    Terminal................. " "
    Char.set.... "C"
    SAP kernel....... 701
    created (date)... "Jul 6 2009 23:47:55"
    create on........ "NT 5.2 3790 Service Pack 1 x86 MS VC++ 14.00"
    Database version. "OCI_10201_SHARE (10.2.0.2.0) "
    Patch level. 50
    Patch text.. " "
    Database............. "ORACLE 9.2.0.., ORACLE 10.1.0.., ORACLE 10.2.0.."
    SAP database version. 701
    Operating system..... "Windows NT 5.0, Windows NT 5.1, Windows NT 5.2, Windows
    NT 6.0"
    Information on where terminated
    Termination occurred in the ABAP program "SAPLSLCAPPS" - in
    "LCA_EXISTS_LCA_ROUTINE".
    The main program was "/SAPAPO/TS_BATCH_RUN ".
    In the source code you have the termination point in line 23
    of the (Include) program "LSLCAPPSU05".
    The program "SAPLSLCAPPS" was started as a background job.
    Job Name....... "MACROS"
    Job Initiator.. "SC7GEN"
    Job Number..... 10222002
    The termination is caused because exception "CX_SY_NATIVE_SQL_ERROR" occurred
    in
    procedure "LCA_EXISTS_LCA_ROUTINE" "(FUNCTION)", but it was neither handled
    locally nor declared
    in the RAISING clause of its signature.
    The procedure is in program "SAPLSLCAPPS "; its source code begins in line
    1 of the (Include program "LSLCAPPSU05 ".
    Please help me to resolve the issue.
    Suraj

    Hi Natalia Khlopina,
    I have raised OSS message to SAP.
    Below is the information
    E:\usr\sap\SC7\SYS\exe\uc\Copy_ of_NTAMD64_15062009>sdbregview -l
    Server Utilities    e:/sapdb/programs      7.7.02.08     64 bit    valid
    DB Analyzer         e:/sapdb/programs      7.7.02.08     64 bit    valid
    PCR 7301            e:/sapdb/programs      7.3.01.21               valid
    PCR 7500            e:/sapdb/programs      7.5.00.42     64 bit    valid
    SAP Utilities       e:/sapdb/programs      7.7.02.08     64 bit    valid
    APO LC APPS         f:/sapdb/lcs/db/sap    6.00.004      64 bit    valid
    Redist Python       e:/sapdb/programs      7.7.02.08     64 bit    valid
    Base                e:/sapdb/programs      7.7.02.08     64 bit    valid
    JDBC                e:/sapdb/programs      7.6.03.02               valid
    Messages            e:/sapdb/programs      MSG 0.5010              valid
    ODBC                e:/sapdb/programs      7.7.02.08     64 bit    valid
    SQLDBC 77           e:/sapdb/programs      7.7.02.08     64 bit    valid
    Database Kernel     f:/sapdb/lcs/db        7.7.02.08     64 bit    valid
    Loader              e:/sapdb/programs      7.7.02.08     64 bit    valid
    SQLDBC              e:/sapdb/programs      7.7.02.08     64 bit    valid
    SQLDBC 76           e:/sapdb/programs      7.6.01.15     64 bit    valid
    Fastload API        e:/sapdb/programs      7.7.02.08     64 bit    valid
    C:\Documents and Settings\sc7adm>disp+work
    disp+work information
    kernel release                701
    kernel make variant           701_REL
    compiled on                   NT 5.2 3790 Service Pack 1 x86 MS VC++ 14.00
    compiled for                  64 BIT
    compilation mode              UNICODE
    compile time                  Jul  6 2009 23:47:55
    update level                  0
    patch number                  50
    source id                     0.050
    supported environment
    database (SAP, table SVERS)   700
                                  701
    operating system
    Windows NT 5.0
    Windows NT 5.1
    Windows NT 5.2
    Windows NT 6.0
    Thanks for quick responce.
    Suraj

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

  • Hi I would like to know if I can delete my file fpsaud (Library Cache) because my app Clean my mac cannot do it. Is this operation dangerous? Thanks

    Hi I would like to know if I can delete my file psaud (Library Cache) because my App Mac Cleanse cannot do it. Can I move this this manually into the trash? Is it dangerous? Thanks

    You should have stopped after the first paragraph, because that was the only helpful part. You managed to sarcastically tell the questioner that he or she is dumb, throw in a couple of tidbits to convince any reader how smart you must be, and discourage any further learning.
    I saw nowhere in the original question where marcozroberto was complaining about speed.
    Caches, to us lesser mortals, are one of the first culprits that come to mind when all the cookies (including smart cookies) and browser cache have been erased, yet the ads on Web pages still want to know if I'd like to find a date tonight in my specific area code. So, I turn to sites like the Apple discussion pages to find out what other pieces of memory I have to flush to feel less stalked.  According to you, I shouldn't bother my poor head learning about this machine I bought, I should just trust  manufacturers and programmers to manage everything.
    I doubt fpsaud is really the problem with my browsing (my next guess is the IP address), but I won't learn that here.

  • Oracle 10.2.0.4 library cache contention,every event wait 64s! strange

    my database suddently very slow in a few seconds.After a while, all become normal.
    In awr report,I find no special sql.
    I paste two trouble time awr report here.
    If you have any more information for troubleshooting ,I will paste if you require.
    Thanks.
    AWR report1:
    WORKLOAD REPOSITORY report for
    DB Name DB Id Instance Inst Num Release RAC Host
    DB 3594421410 db2 2 10.2.0.4.0 YES db2
    Snap Id Snap Time Sessions Curs/Sess
    Begin Snap: 2342 17-Mar-09 21:30:23 521 1.1
    End Snap: 2344 17-Mar-09 22:30:25 498 1.0
    Elapsed: 60.03 (mins)
    DB Time: 750.95 (mins)
    Cache Sizes
    ~~~~~~~~~~~ Begin End
    Buffer Cache: 3,504M 3,504M Std Block Size: 8K
    Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
    Load Profile
    ~~~~~~~~~~~~ Per Second Per Transaction
    Redo size: 18,182.64 2,754.51
    Logical reads: 326.19 49.41
    Block changes: 123.54 18.72
    Physical reads: 21.33 3.23
    Physical writes: 7.29 1.10
    User calls: 178.46 27.03
    Parses: 62.04 9.40
    Hard parses: 0.09 0.01
    Sorts: 2.00 0.30
    Logons: 0.20 0.03
    Executes: 63.12 9.56
    Transactions: 6.60
    % Blocks changed per Read: 37.87 Recursive Call %: 17.93
    Rollback per transaction %: 14.26 Rows per Sort: 44.63
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 99.99 Redo NoWait %: 99.95
    Buffer Hit %: 93.46 In-memory Sort %: 100.00
    Library Hit %: 99.52 Soft Parse %: 99.86
    Execute to Parse %: 1.70 Latch Hit %: 99.97
    Parse CPU to Parse Elapsd %: 0.82 % Non-Parse CPU: 98.60
    Shared Pool Statistics Begin End
    Memory Usage %: 78.60 78.77
    % SQL with executions>1: 99.38 99.27
    % Memory for SQL w/exec>1: 99.00 98.78
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time Wait Class
    latch: library cache 736 47,078 63965 104.5 Concurrenc
    CPU time 236 0.5
    rdbms ipc reply 360 219 608 0.5 Other
    log file sync 20,469 137 7 0.3 Commit
    gc cr block 2-way 35,641 102 3 0.2 Cluster
    AWR report 2:
    DB Name DB Id Instance Inst Num Release RAC Host
    db 3594421410 db2 2 10.2.0.4.0 YES yt-db2
    Snap Id Snap Time Sessions Curs/Sess
    Begin Snap: 2364 18-Mar-09 08:30:29 497 1.1
    End Snap: 2365 18-Mar-09 08:42:28 511 1.0
    Elapsed: 11.99 (mins)
    DB Time: 277.14 (mins)
    Cache Sizes
    ~~~~~~~~~~~ Begin End
    Buffer Cache: 3,504M 3,504M Std Block Size: 8K
    Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
    Load Profile
    ~~~~~~~~~~~~ Per Second Per Transaction
    Redo size: 23,306.73 2,556.74
    Logical reads: 337.31 37.00
    Block changes: 159.74 17.52
    Physical reads: 0.72 0.08
    Physical writes: 9.74 1.07
    User calls: 274.07 30.06
    Parses: 95.29 10.45
    Hard parses: 0.04 0.00
    Sorts: 2.52 0.28
    Logons: 0.19 0.02
    Executes: 95.71 10.50
    Transactions: 9.12
    % Blocks changed per Read: 47.36 Recursive Call %: 9.14
    Rollback per transaction %: 11.13 Rows per Sort: 32.48
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 98.81 Redo NoWait %: 100.00
    Buffer Hit %: 99.79 In-memory Sort %: 100.00
    Library Hit %: 99.86 Soft Parse %: 99.95
    Execute to Parse %: 0.44 Latch Hit %: 99.94
    Parse CPU to Parse Elapsd %: 40.91 % Non-Parse CPU: 81.90
    Shared Pool Statistics Begin End
    Memory Usage %: 79.91 80.01
    % SQL with executions>1: 99.52 99.52
    % Memory for SQL w/exec>1: 98.83 98.77
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time Wait Class
    latch free 176 4,391 24950 26.4 Other
    gc buffer busy 3,726 3,335 895 20.1 Cluster
    gc cr multi block request 4,165 2,204 529 13.3 Cluster
    gc current grant busy 3,938 1,798 457 10.8 Cluster
    latch: cache buffers chains 124 1,548 12487 9.3 Concurrenc
    ^LRAC Statistics DB/Inst: db/db2 Snaps: 2364-2365
    Begin End
    Number of Instances: 2 2
    Global Cache Load Profile
    ~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
    Global Cache blocks received: 19.36 2.12
    Global Cache blocks served: 19.39 2.13
    GCS/GES messages received: 63.76 6.99
    GCS/GES messages sent: 63.64 6.98
    DBWR Fusion writes: 2.58 0.28
    Estd Interconnect traffic (KB) 334.84
    Edited by: gaoyafang on 2009-3-18 上午12:46

    my database suddently very slow in a few seconds.After a while, all become normal.
    In awr report,I find no special sql.
    I paste two trouble time awr report here.
    If you have any more information for troubleshooting ,I will paste if you require.
    Thanks.
    AWR report1:
    WORKLOAD REPOSITORY report for
    DB Name DB Id Instance Inst Num Release RAC Host
    DB 3594421410 db2 2 10.2.0.4.0 YES db2
    Snap Id Snap Time Sessions Curs/Sess
    Begin Snap: 2342 17-Mar-09 21:30:23 521 1.1
    End Snap: 2344 17-Mar-09 22:30:25 498 1.0
    Elapsed: 60.03 (mins)
    DB Time: 750.95 (mins)
    Cache Sizes
    ~~~~~~~~~~~ Begin End
    Buffer Cache: 3,504M 3,504M Std Block Size: 8K
    Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
    Load Profile
    ~~~~~~~~~~~~ Per Second Per Transaction
    Redo size: 18,182.64 2,754.51
    Logical reads: 326.19 49.41
    Block changes: 123.54 18.72
    Physical reads: 21.33 3.23
    Physical writes: 7.29 1.10
    User calls: 178.46 27.03
    Parses: 62.04 9.40
    Hard parses: 0.09 0.01
    Sorts: 2.00 0.30
    Logons: 0.20 0.03
    Executes: 63.12 9.56
    Transactions: 6.60
    % Blocks changed per Read: 37.87 Recursive Call %: 17.93
    Rollback per transaction %: 14.26 Rows per Sort: 44.63
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 99.99 Redo NoWait %: 99.95
    Buffer Hit %: 93.46 In-memory Sort %: 100.00
    Library Hit %: 99.52 Soft Parse %: 99.86
    Execute to Parse %: 1.70 Latch Hit %: 99.97
    Parse CPU to Parse Elapsd %: 0.82 % Non-Parse CPU: 98.60
    Shared Pool Statistics Begin End
    Memory Usage %: 78.60 78.77
    % SQL with executions>1: 99.38 99.27
    % Memory for SQL w/exec>1: 99.00 98.78
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time Wait Class
    latch: library cache 736 47,078 63965 104.5 Concurrenc
    CPU time 236 0.5
    rdbms ipc reply 360 219 608 0.5 Other
    log file sync 20,469 137 7 0.3 Commit
    gc cr block 2-way 35,641 102 3 0.2 Cluster
    AWR report 2:
    DB Name DB Id Instance Inst Num Release RAC Host
    db 3594421410 db2 2 10.2.0.4.0 YES yt-db2
    Snap Id Snap Time Sessions Curs/Sess
    Begin Snap: 2364 18-Mar-09 08:30:29 497 1.1
    End Snap: 2365 18-Mar-09 08:42:28 511 1.0
    Elapsed: 11.99 (mins)
    DB Time: 277.14 (mins)
    Cache Sizes
    ~~~~~~~~~~~ Begin End
    Buffer Cache: 3,504M 3,504M Std Block Size: 8K
    Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
    Load Profile
    ~~~~~~~~~~~~ Per Second Per Transaction
    Redo size: 23,306.73 2,556.74
    Logical reads: 337.31 37.00
    Block changes: 159.74 17.52
    Physical reads: 0.72 0.08
    Physical writes: 9.74 1.07
    User calls: 274.07 30.06
    Parses: 95.29 10.45
    Hard parses: 0.04 0.00
    Sorts: 2.52 0.28
    Logons: 0.19 0.02
    Executes: 95.71 10.50
    Transactions: 9.12
    % Blocks changed per Read: 47.36 Recursive Call %: 9.14
    Rollback per transaction %: 11.13 Rows per Sort: 32.48
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 98.81 Redo NoWait %: 100.00
    Buffer Hit %: 99.79 In-memory Sort %: 100.00
    Library Hit %: 99.86 Soft Parse %: 99.95
    Execute to Parse %: 0.44 Latch Hit %: 99.94
    Parse CPU to Parse Elapsd %: 40.91 % Non-Parse CPU: 81.90
    Shared Pool Statistics Begin End
    Memory Usage %: 79.91 80.01
    % SQL with executions>1: 99.52 99.52
    % Memory for SQL w/exec>1: 98.83 98.77
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time Wait Class
    latch free 176 4,391 24950 26.4 Other
    gc buffer busy 3,726 3,335 895 20.1 Cluster
    gc cr multi block request 4,165 2,204 529 13.3 Cluster
    gc current grant busy 3,938 1,798 457 10.8 Cluster
    latch: cache buffers chains 124 1,548 12487 9.3 Concurrenc
    ^LRAC Statistics DB/Inst: db/db2 Snaps: 2364-2365
    Begin End
    Number of Instances: 2 2
    Global Cache Load Profile
    ~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
    Global Cache blocks received: 19.36 2.12
    Global Cache blocks served: 19.39 2.13
    GCS/GES messages received: 63.76 6.99
    GCS/GES messages sent: 63.64 6.98
    DBWR Fusion writes: 2.58 0.28
    Estd Interconnect traffic (KB) 334.84
    Edited by: gaoyafang on 2009-3-18 上午12:46

  • A lot of  'library cache lock'

    Hi there,
    My database has a lot of contention in 'library cache lock', more than 90% of all events.
    I'm trying to find the query that is waiting for this event, but the sql_id in v$session not exist in v$sql.
    SQL> select sql_id, count(*)
    2 from gv$session
    3 where EVENT ='library cache lock'
    4 group by sql_id;
    SQL_ID COUNT(*)
    4gd6b1r53yt88 49
    47
    SQL> select *
    2 from gv$sql
    3 where sql_id = '4gd6b1r53yt88';
    no rows selected
    The oracle version is 10.2.0.3 RAC.
    Can somebody help me?
    Thanks,
    Everson

    Hi rjaf
    Following this post, I got the table SYS.KOTTD$.
    I think this is some kind of Oracle internal problem, but I don't know what.

Maybe you are looking for

  • Need Help In Returning to Mail; Thunderbird Creates Disaster!

    What I love about Mail is that I use multiple Macs and can keep all my .Mac and other email on the respective email servers, thus having access to all my email on all my machines wherever I might be. What I don't like about Mail is the weak spam filt

  • If i update my itunes ill i lose my music and apps?

    i cant download books and some other apps unless i update but am worried if i update i will lose my whole library of songs and also apps??? any able to help???

  • Google Music Beta uploader program (wine)

    I've created a package for the Google Music Beta uploader. http://aur.archlinux.org/packages.php?ID=49659 It's a wine package, but I wasn't sure how to tell if it was "clean" or "portable". I'm just launching it without any environment preparation an

  • Soft photos in slideshow

    I have just made my first slideshow using Aperture 3 and although I exported using HD 1080p (whatever that means), the slides in the show are soft. Anyone with experience with creating DVDs using Aperture out there that can tell me how to export the

  • Having trouble with array formula in Numbers

    I should start right away by stating that I am very new to using numbers and array formulas, so potentially I am missing something very basic. But, I am having trouble creating a progessive array formula that will allow me to charge users of a system