Library Cache lock - sequence

Similar Questions

• Library Cache lock when re-register a XSD

  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
  
  

  If I 'use' a xsd in a single session, and then if I try to re - register the xsd in another session, the session of re - record indefinitely waiting on a library cache lock:

  "use" the xsd is one session: 
  
  create or replace procedure sp_schema_validate_xml(pi_xml IN XMLType, 
                                                     pi_xml_schema IN VARCHAR2) 
  is 
    v_count number; 
    v_err_msg varchar2(4000); 
    v_xml xmltype; 
  begin 
        --do level 1 schema validation 
        if pi_xml.isSchemaValid(pi_xml_schema) = 0 then --level 1 vldtn failed. do level 2 
  
          begin --do level 2 vldtn 
            v_xml := pi_xml.createSchemaBasedXML(pi_xml_schema); 
  
            v_xml.schemaValidate(); 
           
          end; 
        
        end if; 
  
  end sp_schema_validate_xml; 
  / 
  
  
  create or replace directory pipedoc as '/home/oracle/testfiles/HUD/ERS_HUD_VM01/PIPE'; 
  
  begin 
    sp_schema_validate_xml(pi_xml => xmltype(bfilename('PIPEDOC', 'DecryptedFile-36805759.xml'),0), 
                           pi_xml_schema => 'PIPE/Power/V4.0/PIPEDocument.xsd' 
                          ); 
  end; 
  / 
  
  Now try to re-register the XSD in another session: 
  
  create or replace directory XSD as '/home/oracle/testfiles/HUD/ERS_HUD_VM01/PIPE/XSDs/Power'; 
  
  create or replace function f_exists_xsd(pi_list_item IN varchar2) return boolean 
    is 
      v_count pls_integer; 
    begin 
       
      select count(1) into v_count 
      from user_xml_schemas 
      where schema_url = pi_list_item; 
       
      if v_count = 0 then 
        return false; 
      else 
        return true; 
      end if; 
     
    end f_exists_xsd; 
  / 
  
  
  
  declare 
    v_xsd varchar2(100) := 'PIPE/Power/V4.0/PIPEDocument.xsd'; 
  begin 
    if f_exists_xsd(v_xsd) = true then 
       dbms_xmlschema.deleteschema(v_xsd, 
                                       dbms_xmlschema.DELETE_CASCADE_FORCE); 
    end if; 
                  
    dbms_xmlschema.registerSchema(schemaURL => v_xsd, 
                                     schemaDoc => xmltype(bfilename('XSD', 'PIPEDocument.xsd'), 0), 
                                     local => TRUE, 
                                     genTypes => FALSE, 
                                     genbean => FALSE, 
                                     genTables => FALSE, 
                                     force => FALSE, 
                                     owner => user); 
  end; 
  / 
  
  The session which is trying to re-register the XSD will wait indefinitely with a "library cache lock", regardless of whether the other session issues a commit or not. The lock only gets released when the other session disconnects. 
  
  I consider this to be an Oracle product defect but of course we'll have to workaround this because Oracle Support hasn't been forthcoming with help recently.
  

  I found a query previously that helped identify the blocking session so that we can complete the process:

  select 
  distinct 
     ses.ksusenum sid, ses.ksuseser serial#, ses.ksuudlna username,KSUSEMNM module, 
     ob.kglnaown obj_owner, ob.kglnaobj obj_name 
     ,lk.kgllkcnt lck_cnt, lk.kgllkmod lock_mode, lk.kgllkreq lock_req 
     , w.state, w.event, w.wait_Time, w.seconds_in_Wait 
  from 
   x$kgllk lk, x$kglob ob,x$ksuse ses 
    , v$session_wait w 
  where lk.kgllkhdl in 
  (select kgllkhdl from x$kgllk where kgllkreq >0 ) 
  and ob.kglhdadr = lk.kgllkhdl 
  and lk.kgllkuse = ses.addr 
  and w.sid = ses.indx 
  order by seconds_in_wait desc
  

  My question is twofold:

  1. The query above works only on instances that had put 10 gr 2 and not on those that have been built in charges on 11 GR 2 as apparently tit x$ kgllk view and related synonyms are removed in 11G (see Oracle support Doc ID 878623.1).
  2. Even if I can find other views to use, I don't like the thought of my deployment/upgrade script, through "blindly" to kill a session in order to succeed in restoring the XSD.

  How can I do for correctly locking and releasing the XSD to avoid library cache lock? If not, is it possible to clear the cache of library?

  Hmm - I think I myself have solved taking into account something that Odie_63 or Marco Gralike had mentioned earlier...

  I modified my diagram procedure to release all resources to validate and I no longer get the library cache lock:

  create or replace procedure sp_schema_validate_xml(pi_xml         IN XMLType,
                                                     pi_xml_schema  IN VARCHAR2)
  is
    v_count number;
    v_err_msg varchar2(4000);
    v_xml xmltype;
  begin
        --do level 1 schema validation
        if  pi_xml.isSchemaValid(pi_xml_schema) = 0 then --level 1 vldtn failed. do level 2
  
          begin --do level 2 vldtn
            v_xml := pi_xml.createSchemaBasedXML(pi_xml_schema);
  
            v_xml.schemaValidate();                            
  
          end;
  
        end if;          
  
        dbms_session.modify_package_state(dbms_session.free_all_resources);
  
  end sp_schema_validate_xml;
  /
  

• High library cache locks

  Snapper shows (Oracle 11.2.0.2 on Linux SLES)
  

  @snapper ash 5 1 all
  Sampling SID all with interval 5 seconds, taking 1 snapshots...
  
  -- Session Snapper v3.52 by Tanel Poder @ E2SN ( http://tech.e2sn.com )
  
  
  -----------------------------------------------------------------------
  Active% | SQL_ID          | EVENT                     | WAIT_CLASS
  -----------------------------------------------------------------------
     849% | 6k5p0akvc7b42   | library cache lock        | Concurrency
     100% | 6k5p0akvc7b42   | ON CPU                    | ON CPU
      93% | 2byjh4h8u2xz0   | ON CPU                    | ON CPU
      73% | 2qn7pc3c09cyr   | ON CPU                    | ON CPU
      24% | 9k3y572frxzys   | db file scattered read    | User I/O
      17% | b698xf4hs173p   | ON CPU                    | ON CPU
       7% |                 | ON CPU                    | ON CPU
       7% | 6k5p0akvc7b42   | cursor: pin S wait on X   | Concurrency
       5% | 6k5p0akvc7b42   | kksfbc child completion   | Other
       5% | bxud62qj6yjx1   | db file scattered read    | User I/O
  
  --  End of ASH snap 1, end=2012-03-07 09:40:58, seconds=5, samples_taken=41

  Currently a lot of statements (sql_id 6k5p0akvc7b42) run in several parallel sessions
  INSERT INTO xxx (...)
  (SELECT...
  Of yyy)
  
  
  Now I wonder how to reduce library cache locks
  
  Can be more (currentyl 50) session_cached_cursors approach?

  Hello

  Please share us with AWR report for 1 h. frequency and show us the load for this profile.

  Also check

  SQL > show parameter cursor_sharing
  SQL > show parameter sessio_cached_cursor
  SQL > show parameter optimizer

  It looks like not to suffer from analysis which is originally high library cache lock event. Yes sometimes increase session_cached_cursor helps us to reduce the soft analysis. But you need to check if its soft or hard analysis.

  See also
  Troubleshooting Cache library: lock, PIN and load Lock [ID 444560.1]
  Library Cache lock Held for a long time for queries involving too much Lie [ID 1315929.1]

  bottom

• Shared lock library pool - Cache lock

  Hello
  
  I have a blocking session has worked 100% of the CPU for a long time.
  Session blocking is latch: shared pool
  The other session = Library Cache lock
  
  
  Module DBMS_SCHEDULER
  Action UTL_RECOMP_SLAVE_2
  Forward class is Concerrency.
  
  
  SQL = TEXT
  

  BEGIN
  
  dbms_utility.validate(:1, :2, :3);
  
  END;

  select spid from v$process where
  addr = (select paddr from v$session where sid = )
  

  Concerning

• DB 9.2.0.8 high library cache latch

  We have AIX 5 L (5.3) server with 8 power 6 CORES 4200 MHz (hyperthreading enabled, so 16 CPU virtual) and database Oracle 9.2.0.8 (migration to 11 GR 2 will next year occur). Database is part of the configuration of dataguard with 1 expectation of maximum availability mode database.
  
  Our night work (use to run in 30 parallel sessions in PL/SQL) suffers a statement cache large library (11% free, but sometimes he goes over 20%, then divide by two locking latches are cache library and library cache pins). Database and SQL, we have resolved several times, we have reduced the random disk operations, events, affirmation of channels cache buffer, removed waiting buffer busy but after each issue of optimization of the library cache locks grew (we just found another bottleneck). DB used to analyze the 3 500-4500 per second during this work (due to a bug SYS_CONTEXT), now it's just 45 per second, so we have reduced the number of library cache searches, too.
  
  In the following report statspack (I na not paste entire file, just gerenal information, wait events, statistics, locks and TOP SQL by analysis of calls) we have:
  
  < li > analysis count (total) 117 058
  < Li > TOP SQL by parsed (this is recursive SQL, hv = 3286148528) 70 187
  
  In fact, more than 70% of searches of library cache are caused by recursive 2 SQL (like many, I know, recursive SQL is still ignoring session_cached_cursors). I have 8 physical CŒURS, Oracle has created in 9i 17 latches cache library at the start of the instance. I thought most waits on research of library cache were caused by a lock child (because of SQL hv = 3286148528), but I was definitely wrong. Snapshot of v$ latch_children, I've done every 3 minutes and wait were evenly distributed between all the 17 locks .
  I don't understand why I expected "library cache" upper 3times then "pine cache library" (WHERE kglupc: child and kglpnc: child). In most our databases (with research in lc low and high run count), we have the two latches at the same level.  . Any ideas would be appreciated
  
  It is also good to mention that srver is 0 inactive when the job is running (but our goal is to complete the process as soon as possible). There are no other database on the server, of course.
  
  Pavol Babel
  Oracle Certified Master
  

  STATSPACK report for
  
  DB Name         DB Id    Instance     Inst Num Release     Cluster Host
  ------------ ----------- ------------ -------- ----------- ------- ------------
  CTP           3761805420 CTPO                1 9.2.0.8.0   NO      sd3test
  
                Snap Id     Snap Time      Sessions Curs/Sess Comment
              --------- ------------------ -------- --------- -------------------
  Begin Snap:    196615 18-Jun-11 22:43:43      130      93.2
    End Snap:    196622 18-Jun-11 23:26:56      129     112.8
     Elapsed:               43.22 (mins)
  
  Cache Sizes (end)
  ~~~~~~~~~~~~~~~~~
                 Buffer Cache:     3,072M      Std Block Size:          8K
             Shared Pool Size:     1,200M          Log Buffer:     16,384K
  
  Load Profile
  ~~~~~~~~~~~~                            Per Second       Per Transaction
                                     ---------------       ---------------
                    Redo size:          3,312,111.10             23,670.00
                Logical reads:            233,724.40              1,670.31
                Block changes:             18,297.28                130.76
               Physical reads:              1,102.05                  7.88
              Physical writes:              1,716.01                 12.26
                   User calls:                 27.51                  0.20
                       Parses:                 45.14                  0.32
                  Hard parses:                  0.13                  0.00
                        Sorts:              3,665.77                 26.20
                       Logons:                  0.10                  0.00
                     Executes:             42,748.58                305.50
                 Transactions:                139.93
  
    % Blocks changed per Read:    7.83    Recursive Call %:     99.97
   Rollback per transaction %:    1.42       Rows per Sort:      2.85
  
  Instance Efficiency Percentages (Target 100%)
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              Buffer Nowait %:   99.94       Redo NoWait %:    100.00
              Buffer  Hit   %:   99.57    In-memory Sort %:    100.00
              Library Hit   %:  100.04        Soft Parse %:     99.71
           Execute to Parse %:   99.89         Latch Hit %:     99.53
  Parse CPU to Parse Elapsd %:    2.90     % Non-Parse CPU:     99.99
  
   Shared Pool Statistics        Begin   End
                                 ------  ------
               Memory Usage %:   18.46   18.92
      % SQL with executions>1:   84.52   84.58
    % Memory for SQL w/exec>1:   74.23   74.95
  
  Top 5 Timed Events
  ~~~~~~~~~~~~~~~~~~                                                     % Total
  Event                                               Waits    Time (s) Ela Time
  -------------------------------------------- ------------ ----------- --------
  CPU time                                                       15,869    32.09
  db file sequential read                         2,255,519      10,374    20.98
  PL/SQL lock timer                                  13,010      10,085    20.39
  latch free                                        261,042       5,591    11.31
  buffer busy waits                                 381,101       2,244     4.54
            -------------------------------------------------------------
  Wait Events for DB: CTP  Instance: CTPO  Snaps: 196615 -196622
  -> s  - second
  -> cs - centisecond -     100th of a second
  -> ms - millisecond -    1000th of a second
  -> us - microsecond - 1000000th of a second
  -> ordered by wait time desc, waits desc (idle events last)
  
                                                                     Avg
                                                       Total Wait   wait    Waits
  Event                               Waits   Timeouts   Time (s)   (ms)     /txn
  ---------------------------- ------------ ---------- ---------- ------ --------
  db file sequential read         2,255,519          0     10,374      5      6.2
  PL/SQL lock timer                  13,010     13,003     10,085    775      0.0
  latch free                        261,042     55,202      5,591     21      0.7
  buffer busy waits                 381,101          0      2,244      6      1.1
  db file parallel write            703,144          0      1,142      2      1.9
  LGWR wait on LNS                1,943,337      3,507        984      1      5.4
  LGWR-LNS wait on channel          795,292      3,506        981      1      2.2
  LNS wait on SENDREQ               352,719          0        832      2      1.0
  direct path read                   89,263          0        351      4      0.2
  log file sync                      26,078          2        301     12      0.1
  LGWR wait for redo copy           225,228        457        250      1      0.6
  enqueue                             9,742          0         64      7      0.0
  db file scattered read             54,410          0         60      1      0.1
  library cache pin                     529          0         59    111      0.0
  inactive session                       60         60         59    977      0.0
  log file sequential read            8,505          0         50      6      0.0
  async disk IO                      17,970          0         41      2      0.0
  log file switch completion            973          0         39     40      0.0
  control file sequential read       59,062          0         35      1      0.2
  library cache load lock               114          0         10     84      0.0
  log file parallel write           352,205          0          9      0      1.0
  LNS wait on LGWR                2,619,701          0          8      0      7.2
  control file parallel write         4,431          0          5      1      0.0
  log buffer space                       11          0          3    300      0.0
  db file parallel read                 239          0          2      8      0.0
  process startup                        37          0          1     24      0.0
  wait list latch free                   52          0          1     13      0.0
  buffer deadlock                       206        206          0      1      0.0
  ARCH wait on SENDREQ                   43          0          0      5      0.0
  direct path write                  10,377          0          0      0      0.0
  library cache lock                      1          0          0    179      0.0
  row cache lock                          6          0          0     16      0.0
  log file single write                  34          0          0      2      0.0
  SQL*Net more data to client         2,265          0          0      0      0.0
  local write wait                        1          0          0     21      0.0
  SQL*Net break/reset to clien           25          0          0      1      0.0
  db file single write                    3          0          0      3      0.0
  SQL*Net message from client        57,311          0    165,393   2886      0.2
  pipe get                           91,560      2,334      7,523     82      0.3
  jobq slave wait                       782        770      2,280   2915      0.0
  SQL*Net message to client          57,343          0          0      0      0.2
  SQL*Net more data from clien          255          0          0      0      0.0
            -------------------------------------------------------------
  Background Wait Events for DB: CTP  Instance: CTPO  Snaps: 196615 -196622
  -> ordered by wait time desc, waits desc (idle events last)
  
                                                                     Avg
                                                       Total Wait   wait    Waits
  Event                               Waits   Timeouts   Time (s)   (ms)     /txn
  ---------------------------- ------------ ---------- ---------- ------ --------
  db file parallel write            703,148          0      1,142      2      1.9
  LGWR wait on LNS                1,943,340      3,507        984      1      5.4
  LGWR-LNS wait on channel          795,293      3,506        981      1      2.2
  LNS wait on SENDREQ               352,720          0        832      2      1.0
  LGWR wait for redo copy           225,228        457        250      1      0.6
  log file sequential read            8,505          0         50      6      0.0
  async disk IO                      16,789          0         38      2      0.0
  latch free                          2,655         85         26     10      0.0
  log file parallel write           352,206          0          9      0      1.0
  LNS wait on LGWR                2,619,702          0          8      0      7.2
  control file sequential read       12,133          0          7      1      0.0
  control file parallel write         4,425          0          5      1      0.0
  db file scattered read                307          0          3     10      0.0
  db file sequential read               274          0          1      2      0.0
  direct path read                   24,738          0          0      0      0.1
  ARCH wait on SENDREQ                   43          0          0      5      0.0
  enqueue                                45          0          0      2      0.0
  log file single write                  34          0          0      2      0.0
  rdbms ipc reply                       129          0          0      0      0.0
  direct path write                  10,258          0          0      0      0.0
  wait list latch free                    3          0          0     10      0.0
  buffer busy waits                       2          0          0      0      0.0
  rdbms ipc message               2,173,078      2,976     30,391     14      6.0
  pmon timer                            868        862      2,528   2913      0.0
  smon timer                             64          0      2,461  38446      0.0
            -------------------------------------------------------------
  SQL ordered by Gets for DB: CTP  Instance: CTPO  Snaps: 196615 -196622
  -> End Buffer Gets Threshold:     10000
  -> Note that resources reported for PL/SQL includes the resources used by
     all SQL statements called within the PL/SQL code.  As individual SQL
     statements are also reported, it is possible and valid for the summed
     total % to exceed 100
  
  
  .
  .
  .
  .
  
  SQL ordered by Parse Calls for DB: CTP  Instance: CTPO  Snaps: 196615 -196622
  -> End Parse Calls Threshold:      1000
  
                             % Total
   Parse Calls  Executions   Parses  Hash Value
  ------------ ------------ -------- ----------
        70,187       70,186    59.96 3286148528
  select c.name, u.name from con$ c, cdef$ cd, user$ u  where c.co
  n# = cd.con# and cd.enabled = :1 and c.owner# = u.user#
  
         8,686        8,686     7.42 3716207873
  update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,
  order$=:6,cache=:7,highwater=:8,audit$=:9,flags=:10 where obj#=:
  1

  Published by: Pavol Babel June 21, 2011 23:29
  
  Published by: Pavol Babel June 21, 2011 23:37
  
  Published by: Pavol Babel June 21, 2011 23:46
  
  Published by: Pavol Babel on June 22, 2011 17:22

  Pavol Babel wrote:
  We have AIX 5 L (5.3) server with 8 power 6 CORES 4200 MHz (hyperthreading enabled, so 16 CPU virtual) and database Oracle 9.2.0.8 (migration to 11 GR 2 will next year occur). Database is part of the configuration of dataguard with 1 expectation of maximum availability mode database.

  In the following report statspack (I na not paste entire file, just gerenal information, wait events, statistics, locks and TOP SQL by analysis of calls) we have:

  analysis count (total) 117 058
  

  TOP SQL by parsed (this is recursive SQL, hv = 3286148528) 70 187

  Load Profile
  ~~~~~~~~~~~~                            Per Second       Per Transaction
  ---------------       ---------------
  Redo size:          3,312,111.10             23,670.00
  Logical reads:            233,724.40              1,670.31
  Block changes:             18,297.28                130.76
  Physical reads:              1,102.05                  7.88
  Physical writes:              1,716.01                 12.26
  User calls:                 27.51                  0.20
  Parses:                 45.14                  0.32
  Hard parses:                  0.13                  0.00
  Sorts:              3,665.77                 26.20
  Logons:                  0.10                  0.00
  Executes:             42,748.58                305.50
  Transactions:                139.93
  

Your library cache issue relates to your 42 000 executions per second, not your 45 analysis per second.
Looks like you need to find a way to keep some run very frequently statements in a pinned - what is in your Top SQL by executions, and state how it is called the pl/SQL? I wouldn't hire me what anyone at the moment, but cursor_space_for_time setting to true may be relevant to your case.

Concerning
Jonathan Lewis

• library cache contention

  Hello
  
  Asked me to take a look at an application where recently they began to experience performance issues. They weren't particularly accurate on their complaints and the AWR report for the duration of their latest issue of prod was not particularly revealing with the exception of a few obvious things. However, I received another AWR report, of a previous issue of the prod, and seems to be quite interesting. Here is the wait events section:
  
  row cache lock 218 154 635 980 2 915 32.9 Concurrency
  cursor: hand S wait on X 54,564,003 11 582 002 30.1 Concurrency
  latch: cache 7 711 223 116 28 935 11.5 Concurrency Library
  cursor: hand S 398,388,863 162 031 0 8.4 other
  latch: cache line 3 793 80 942 21 340 4.2 objects concurrency
  
  Another curious thing is that 15% of the database of time (the top of the SQL page with a second very remote) was due to a single statement:
  
  SELECT THE DOUBLE NULL
  
  (!!!)
  
  which shows 52 million executions in V$ SQL as well as parsed 52 million (!).
  
  Unfortunately, ASH data has just expired a few hours before I had a chance to watch, so I can't link those expectations to specific sessions... I only know this slider: needle S wait events are mostly associated with the above SELECT statement, and it seems that row cache lock wait is due to a lack of caching in the sequences.
  
  I googled a little and found that some people suggest that this may be a side effect of the EAMA... Any other ideas/suggestions?
  
  Best regards
  Nikolai

  Nikolay Savvinov wrote:

  Another curious thing is that 15% of the database of time (the top of the SQL page with a second very remote) was due to a single statement:

  SELECT THE DOUBLE NULL

  (!!!)

  which shows 52 million executions in V$ SQL as well as parsed 52 million (!).

  Next blog can help.
  http://viveklsharma.WordPress.com/2011/11/19/how-challenging-is-the-task-of-a-performance-optimization-expert-a-real-life-example/

  Check if the dblinks work well.

  Also check if the stats system and its dictionary stats are up to this day.

• Library cache pin and Mutex Ref count

  I understand that concurrency library cache is managed by library cache pin, and a session must acquire a PIN after blocking, now from 10 g Mutex (cursor: PIN) has replaced the locking pin: library cache. Now the cursor: hand S is incremented when another process is updating the reference (PIN) of a shared cursor count, it is in fact rather than sleep until the mutex is available, my confusion is that before this implementation of ByRef count which is effective, library cache latch was removed and assigned whenever the cursor was executed which was shared of course , now with Ref count each sessions only and only by increments and decrements without deletion and by allocating a memory lock (latch: cache library).
  
  Now what brings to my mind, is that for this mutex, it can be referenced at the same time many sessions, providing that all sessions of reference the mutex in S (shared Mode). So if they can refer to the mutex at the same time I don't think there should be any event queue unless just pending session increment counter Ref, so another question is can multiples at the same time run the cursor with the cursor: pin S. And I think that no. assume the session A, B, C wants to share a C1 cursor, they want to execute all this slider, now a, b and c session I think run independently of this slider, at different times, time, they have the chance to increment the counter of REF. Please remove my confusion, it is a humble request.

  842638 wrote:
  I understand that concurrency library cache is managed by library cache pin, and a session must acquire a PIN after blocking, now from 10 g Mutex (cursor: PIN) has replaced the locking pin: library cache. Now the cursor: hand S is incremented when another process is updating the reference (PIN) of a shared cursor count, it is in fact rather than sleep until the mutex is available, my confusion is that before this implementation of ByRef count which is effective, library cache latch was removed and assigned whenever the cursor was executed which was shared of course , now with Ref count each sessions only and only by increments and decrements without deletion and by allocating a memory lock (latch: cache library).

  Now what brings to my mind, is that for this mutex, it can be referenced at the same time many sessions, providing that all sessions of reference the mutex in S (shared Mode). So if they can refer to the mutex at the same time I don't think there should be any event queue unless just pending session increment counter Ref, so another question is can multiples at the same time run the cursor with the cursor: pin S. And I think that no. assume the session A, B, C wants to share a C1 cursor, they want to execute all this slider, now a, b and c session I think run independently of this slider, at different times, time, they have the chance to increment the counter of REF. Please remove my confusion, it is a humble request.

  I think you see the mutex as an object 1/0 a session must value 1 while it running the cursor. It's actually a counter that a session increments when it wants to run the cursor and decremented when it has finished execution. This means that if you want to run a cursor when the meter is already worth 5, we will both try to set to 6 - one usage will succeed and start execution of the cursor, the other fails but recognize that the meter is now 6 and set it to 7 before execution.

  To get detailed information about locks, mutexes and the differences between them, there is no better source of information at http://andreynikolaev.wordpress.com/

  Concerning
  Jonathan Lewis
  http://jonathanlewis.WordPress.com
  Author: core Oracle

• IPhoto library is locked and 'force quit' or restarting solves the problem. Any ideas?

  iPhoto has error message: library is locked. clicking on repair or force quit or restart has not resolved. How can I get the app to restart?

  Can you give us the exact error message? Generally, the most common one said something on a disclock. Is your library on an external? If so, what format is it?

  Also, what version of iPhoto?

  Assuming that is not on an external, try to download iPhoto Library Manager and use the rebuild feature. (In early versions of the Library Manager, this is the file-> control Rebuild. In versions later it is under the menu library.)

  This will create a completely new library. It will then copy (or try) your photos and all associated metadata and versions to this library and as close as possible to what you had in the damaged library fix it. It does this based on the information it finds in the iPhoto sharing mechanism - but it means that things not shared won't be there, so no slide shows, books or calendars, for example - but it should recover all your events, albums and keywords, faces and places.

  Because this process creates a completely new library and does not change your old, it is non-destructive, and if you are not satisfied with the result, you can simply go back to your old.

  https://www.fatcatsoftware.com/iPLM/

• Using the disc very high in ~/Library/Caches/com.apple.bird

  System

  -----------------

  MacBook Pro (retina, 15 inch, mid-2015)

  OS X El Capitan 10.11.5 (15F34)

  256 GB SSD

  ===============================

  Question

  -----------------

  The directory ~/Library/Caches/com.apple.bird is huge in size (33 GB at the time of writing)

  Why this cache takes so much space?

  What is the cache?

  Is it safe to delete the cache?

  Is there an internal tool (not a third-party tool or app, I don't trust those) that I can use

  This cache is related to iCloud. A simple solution is located in this section:

  Library/Chaches/com.apple.bird is the largest then 45 GB

• "Not able to print from Lightroom, error message" / Library/Caches/Canon/PrintStudioPro/PrintStudioPro_LR_TEMP.

  I need your help

  Need to create a folder at the following location: / Library/Caches/Canon/PrintStudioPro/PrintStudioPro_LR_TEMP

  It should solve the problem.

• This is the message I get when I try to print from my pro 1 when I go to plug in extras, I tried to import and add another plugin, but no success/Library/Caches/Canon/PrintStudioPro/PrintStudioPro_LR_TEMP

  This is the message I get when I try to print from my pro 1 when I go to plug in extras, I tried to import and add another plugin, but no success/Library/Caches/Canon/PrintStudioPro/PrintStudioPro_LR_TEMP

  Hi Nathalie-B,

  Greetings!

  Go to the/Library/Caches/Canon, and remove the inner content.

  Also, be sure to empty the trash after that.

  Then try again.

  Concerning

  Jitendra

• Store data cached in app/Library/Caches, how to access this folder?

  Hey all,.

  I'm trying to comply with the new rules to keep content which is not essential to the still very desirable application to the cache in 5.0.1. The initial project was built using Flash IDE and FlashDevelop and files stored in the Documents folder. He was rejected from the app store for 2.23 not to put these files in the app/Library/Caches folder.

  I checked to see if this file exists using a bunch of traces of File.applicationDirectory.resolvePath () and I can not find the existence of records. I see that/Library/Caches exist but I get errors writing to that so that may be it.

  For example, here's a bunch of tracks using applicationDirectory and applicationStorageDirectory and their outputs:

  File.applicationDirectory.resolvePath('/Library/Caches');

  File.applicationDirectory.resolvePath ('. /.. /.. / Library/Caches ');

  File.applicationDirectory.resolvePath ('. /... / Library/Caches ');

  File.applicationDirectory.resolvePath('.. / Library/Caches');

  File.applicationDirectory.resolvePath('Library/Caches');

  File.applicationDirectory.resolvePath ('. /... / Library/Caches ');

  ----------------------------

  File.applicationStorageDirectory.resolvePath('/Library/Caches');

  File.applicationStorageDirectory.resolvePath ('. /.. /.. / Library/Caches ');

  File.applicationStorageDirectory.resolvePath ('. /... / Library/Caches ');

  File.applicationStorageDirectory.resolvePath('./Library/Caches');

  File.applicationStorageDirectory.resolvePath('Library/Caches');

  File.applicationStorageDirectory.resolvePath ('. /... / Library/Caches ');

  outputs:

  cache 1 exist: / Library/Caches

  cache 2 exist: /var/mobile/Applications/F6DD6D3B-E01A-44B5-849C-349170008DDD/myApp.app

  cache 3 exist: /var/mobile/Applications/F6DD6D3B-E01A-44B5-849C-349170008DDD/myApp.app

  cache 4 exist: /var/mobile/Applications/F6DD6D3B-E01A-44B5-849C-349170008DDD/myApp.app

  There is no cache 5: /var/mobile/Applications/F6DD6D3B-E01A-44B5-849C-349170008DDD/myApp.app/Library/Caches

  cache 6 exist: /var/mobile/Applications/F6DD6D3B-E01A-44B5-849C-349170008DDD/myApp.app

  ----------------------------

  cache 1 exist: / Library/Caches

  cache 2 is: var/mobile/Applications/F6DD6D3B-E01A-44B5-849C-349170008DDD/Library/Application Support/com.example.myApp/Local store

  cache 3 exist: var/mobile/Applications/F6DD6D3B-E01A-44B5-849C-349170008DDD/Library/Application Support/com.example.myApp/Local store

  There is no cache 4: var/mobile/Applications/F6DD6D3B-E01A-44B5-849C-349170008DDD/Library/Application Support/com.example.myApp/Local store/Library/Caches

  There is no cache 5: var/mobile/Applications/F6DD6D3B-E01A-44B5-849C-349170008DDD/Library/Application Support/com.example.myApp/Local store/Library/Caches

  cache 6 exist: var/mobile/Applications/F6DD6D3B-E01A-44B5-849C-349170008DDD/Library/Application Support/com.example.myApp/Local store

  I expected "Library/Caches" to resolve... You can clearly see 'cache 5 does not exist: /var/mobile/Applications/F6DD6D3B-E01A-44B5-849C-349170008DDD/myApp.app/Library/Caches' traced here.

  I even made Library\Caches records, he understood as a folder in my publication options. I still don't see the existence of directories. Now, it's weird. I also include a folder "data" and that is if I draw for her.

  Some tips on how I can find this path "Library/Caches"?

  The answer to access/library/Caches/looks like so:

  var homePath:String = File.applicationDirectory.nativePath;

  var cachesFolder:File = new queue (homePath + "/ \.\./Library/Caches");

  If (cachesFolder.exists) {trace ("it exists!") ;}}

• Cursors for parent and child, bind variable and library cache

  I was going through the documentation to understand the difference between the parent and the child cursors. Surprisingly, there's not too much help for this. I was able to collect the following information about this
  
  For each statement SQL cache library contains a cursor "parent" for the text of the SQL statement. The parent cursor is composed of a "handle" that can be searched by the hash value via the library cache hash table and an «object' which contains pointers to each of its «child» cursors Each cursor of the child is also composed of a handle and an object. The child object is composed of two segments numbered from 0 to 6. Lot 0 contains all the credentials for a particular version of the SQL statement and lot 6 contains the execution plan. This distinction between parent and child cursors is maintained even when there is only one version of each SQL statement.
  
  Lets say that 2 LMD were fired with the same set of variables bind (names of variables were same but differed from the value.) The only difference between the 2 LMD was the value of the variable binding) and under the same conditions of load.
  
  These DML 2 would be a sliders 2 children of one parent only cursors.
  
  Please tell me detailed documentation on the subject, so my question is too elementary
  
  Kind regards
  Vishal

  I'm not sure how useful jumping in stuff like bunch 0 and 6 bunch is in terms of understanding what is a parent and what is a child cursor.
  This quote seems to come from Steve Adams - http://www.ixora.com.au/q+a/0104/19005414.htm
  It's a good idea to cite your references.

  I'll give it a go.

  A cursor is a lot of information stored in memory on a SQL statement.

  The basic information for a parent cursor is the text of the SQL statement - exact matches of the statement can only share the parent cursor.

  The cursor of the child is really on the implementation plan specific for a statement and the different settings and parameters that caused this plan to be generated.

  There are a whole bunch of reasons why the executions of the same SQL statement may or may not reuse the existing child cursors.

  In your example 2 statements that differ by the variable binding are likely to lead to different children, although there are factors that can lead to lie different values, do not share the same children among whom for example, the length of the dregs, Adaptive setting cursor_sharing = similar and histograms, or new features like cursor sharing (on subsequent runs of renowned sql running suboptimal initially).

  It might be useful to see V$ SQL_SHARED_CURSOR. This shows the disparities that cause children to not be shared. There are more than 60 columns in this view which gives an indication of the number of factors that can influence.
  http://download.Oracle.com/docs/CD/E11882_01/server.112/e17110/dynviews_3059.htm#REFRN30254

  You might want to look here the criteria for sharing SQL:
  http://download.Oracle.com/docs/CD/E11882_01/server.112/e16638/memory.htm#i40017

  Away from the main documentation, perhaps some of the writings of the optimizer Development Group could help?
  http://blogs.Oracle.com/mt/mt-search.cgi?blog_id=3361&tag=cursor%20sharing&limit=20

  Christian Antognini described this area very well in the "Oracle Performance Troubleshooting Guide".

  Published by: Dom Brooks on February 24, 2011 16:45

• Library Cache Tuning

  HI friends,
  I m new to DBA tasks. v have oracle 11g on WIndows xp...
  
  I give me tasks to Tune Library Cache on my live server
  
  I asked rowcache $ V to get the data dictionary cache hit ratio...
  sound * 99% * (ideally the greter b at 90%)
  
  I asked librarycache $ V to get the library cache miss ratio...
  sound * 0.0006% * (ideally less than 0.1 b)
  
  I asked him too librarycache $ v to get the reord below who had problems.
  
  NAMESPACE GETS GETHITS GETHIT_RATIO PINE PINHITS PINHIT_RATIO CHARGING INVALIDATIONS
  AREA OF SQL 43586289 24169038 * 87827805 86643314 55.45* 98,65 122912 42903
  
  Usually gethit_rate should b about 70%, but its 55,45 just for the sql box?
  
  My settings shared_pool_size = 0.
  
  Can you let me know there is this... and what do I do?
  
  Thanks in adance.

  You would grant something that has proved to be a problem. Is there evidence that the library Cache Hit ratio is the performance impact?

  It may be well that the way the application refers to objects through life cycle daily is, the Cache Hit Ratio, not 'seems' to be good.

  The Cache size bookstores automatically takes the value based on the shared pool. If SHARED_POOL_SIZE is 0, then this is to be auto-resized by Oracle based on SGA_TARGET.

  Hemant K Collette

• Library cache invalidation

  Hi all
  
  When I review a query using extended track that took 10 minutes to finish in production, I noticed the following.
  
  
  Production environment
  --------------------------------
  OPERATING SYSTEM: HP - UX 11
  Database: Oracle 10.2
  Audit: WE (actually, heavy, about 177 policies are on in addition to 57 MeV)
  Data Warehouse using Business Objects
  
  
  Observation of tkprof output
  ---------------------------------------------
  
  
  TOTALS FOR ALL NON RECURSIVE INSTRUCTIONS
  
  call the query of disc elapsed to cpu count current lines
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Parse 2 0.44 0.42 0 0 0 0
  Run 2 0.01 0.00 0 0 0 0
  Pick up 84 4.34 5.05 1303 3522 0 1235
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Total 88 4.79 5.48 1303 3522 0 1235
  
  Chess in the library during parsing cache: 1
  
  Elapsed time are waiting on the following events:
  Event waited on times max wait for the Total WHEREAS
  ---------------------------------------- Waited ---------- ------------
  SQL * Net message to client 85 0.00 0.00
  SQL * Net client message 85 66,91 66.95
  SQL * Net more data from client 1 0.00 0.00
  DB file sequential read 14 0.01 0.09
  latch: allocation session 1 0.00 0.00
  db file scattered read 326 0.53 0.02
  latch: shared pool 2 0.00 0.00
  latch: cache library 1 0.00 0.00
  
  
  TOTALS FOR ALL RECURSIVE INSTRUCTIONS
  
  call the query of disc elapsed to cpu count current lines
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Parse 7121 0.68 0.56 0 0 0 0
  Run 21847 6.53 6.31 0 0 0 6998
  Search 15396 686.64 674,91 2364 22572060 0 21579
  ------- ------ -------- ---------- ---------- ---------- ---------- ----------
  Total 44364 693.85 681,79 2364 22572060 0 28577
  
  Chess in the library during parsing cache: 36
  Lack in the cache of the library during execution: 38
  
  
  The figures for non-recursive don't look too bad but recursive seems bad (I think this is mainly because the audit). I inherited this database, and I plan to make a recommendation to reduce the number of checks in place. In the meantime, I'm trying my best to improve the situation regarding the absences of the library cache. The shared pool is currently 400 m and here are some of my observations...
  
  
  SELECT INVALIDATIONS, PINHITS, NAMESPACE, RELOADS, PINES
  V $ LIBRARYCACHE
  ORDER OF NAMESPACE;
  
  NAMESPACE PINHITS INVALIDATION RECHARGE PINES
  
  3582593 3581741 362 BODY 0
  14296 13932 179 CLUSTER 0
  132338 112879 7460 INDEX 0
  GIVEN JAVA 0 0 0 0
  RESOURCES JAVA 0 0 0 0
  JAVA SOURCE 0 0 0 0
  OBJECT 0 0 0 0
  PIPE 0 0 0 0
  AREA 283694927 281523185 267596 SQL * 118090 *.
  215851629 215588814 105599 TABLE/PROC 0
  5890804 5889652 986 RELAXATION 0
  
  
  Select sum (pinhits) /sum (pine) in V$ LIBRARYCACHE
  0.9951717580770384466008350939793460248477
  
  
  SELECT V $ SGASTAT *.
  WHERE NAME = 'free mΘmoire '.
  AND POOL = 'pool'
  
  49920768 (12:00 day value)
  
  
  Based on the fact that there are 118 090 invalidations SQLAREA within 2 days (database was restarted Saturday) and the following information in the trace sql sql which I was followed Sunday.
  
  Total amount for recursive statements
  ---------------------------------------------------
  Chess in the library during parsing cache: 36
  Lack in the cache of the library during execution: 38
  
  
  I intend to increase the shared_pool of 400 to 600M and 160 M to 250 M large_pool (sqls many parallel boards in them). I don't don't parallel queries in memory of shared_pool. Please let me know if I'm on the right track or suggestions.
  
  Thanks for your time.

  Hello

  Look at what query on V$ SHARED_POOL_ADVICE will propose before changing the shared pool.

  Kind regards