Is it latch contention?

I ran a query and was monitoring it. I found high values for db_sequential_reads and later high values for latch free. I was monitoring using V$SESSION_WAIT. how confirm if there was any latch contention. Initial investigation pushing me to understand that there should be something wrong with a table and associated index. It may be a case of 'hot blocks' which are getting repeatedly touched by the query. The suggested fix is adding more FREELISTS. But the question is my tbale properties show an empty entry against FREELISTS for the table/indexes and I am on 9.2.0.7.Do the suggestions suit my case and are my interpretions correct?

Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=114 Card=1 Bytes=186
   1    0   SORT (GROUP BY) (Cost=93 Card=1 Bytes=186)
   2    1     FILTER
   3    2       NESTED LOOPS (Cost=89 Card=1 Bytes=186)
   4    3         HASH JOIN (Cost=88 Card=1 Bytes=162)
   5    4           MERGE JOIN (CARTESIAN) (Cost=73 Card=1 Bytes=135)
   6    5             MERGE JOIN (CARTESIAN) (Cost=35 Card=1 Bytes=122
   7    6               TABLE ACCESS (BY INDEX ROWID) OF 'PSNVSBOOKREQ
          UST' (Cost=3 Card=1 Bytes=46)
   8    7                 NESTED LOOPS (Cost=34 Card=1 Bytes=103)
   9    8                   HASH JOIN (Cost=31 Card=1 Bytes=57)
  10    9                     TABLE ACCESS (FULL) OF 'PS_YYXX_GL_ME_TB
          L' (Cost=14 Card=1 Bytes=23)
  11    9                     VIEW OF 'PS_CSXX_XLATTABLE' (Cost=17 Car
          d=2 Bytes=68)
  12   11                       SORT (UNIQUE) (Cost=17 Card=2 Bytes=13
          3)
  13   12                         UNION-ALL
  14   13                           FILTER
  15   14                             TABLE ACCESS (BY INDEX ROWID) OF
           'PSXLATITEM' (Cost=2 Card=1 Bytes=51)
  16   15                               INDEX (RANGE SCAN) OF 'PSAPSXL
          ATITEM' (NON-UNIQUE) (Cost=1 Card=21)
  17   14                             SORT (AGGREGATE)
  18   17                               FILTER
  19   18                                 INDEX (RANGE SCAN) OF 'PS_PS
          XLATITEM' (UNIQUE) (Cost=2 Card=1 Bytes=26)
  20   13                           FILTER
  21   20                             NESTED LOOPS (Cost=3 Card=1 Byte
          s=82)
  22   21                               TABLE ACCESS (BY INDEX ROWID)
          OF 'PSXLATITEMLANG' (Cost=2 Card=1 Bytes=54)
  23   22                                 INDEX (RANGE SCAN) OF 'PS_PS
          XLATITEMLANG' (UNIQUE) (Cost=2 Card=1)
  24   21                               TABLE ACCESS (BY INDEX ROWID)
          OF 'PSXLATITEM' (Cost=1 Card=1 Bytes=28)
  25   24                                 INDEX (UNIQUE SCAN) OF 'PS_P
          SXLATITEM' (UNIQUE)
  26   20                             SORT (AGGREGATE)
  27   26                               FILTER
  28   27                                 INDEX (RANGE SCAN) OF 'PS_PS
          XLATITEM' (UNIQUE) (Cost=2 Card=1 Bytes=26)
  29    8                   INLIST ITERATOR
  30   29                     INDEX (RANGE SCAN) OF 'PS_PSNVSBOOKREQUS
          T' (UNIQUE) (Cost=5 Card=43)
  31    6               BUFFER (SORT) (Cost=32 Card=1 Bytes=19)
  32   31                 TABLE ACCESS (BY INDEX ROWID) OF 'PS_YYXX_BC
          TRL_TBL' (Cost=1 Card=1 Bytes=19)
  33   32                   INDEX (RANGE SCAN) OF 'PS0YYXX_BCTRL_TBL'
          (NON-UNIQUE) (Cost=1 Card=4)
  34    5             BUFFER (SORT) (Cost=72 Card=564 Bytes=7332)
  35   34               TABLE ACCESS (FULL) OF 'PS_SET_CNTRL_GROUP' (C
          ost=38 Card=564 Bytes=7332)
  36    4           TABLE ACCESS (FULL) OF 'PS_NVS_SCOPE_FIELD' (Cost=
          14 Card=3606 Bytes=97362)
  37    3         TABLE ACCESS (BY INDEX ROWID) OF 'PS_NVS_REPORT' (Co
          st=1 Card=1 Bytes=24)
  38   37           INDEX (UNIQUE SCAN) OF 'PS_NVS_REPORT' (UNIQUE)
  39    2       SORT (AGGREGATE)
  40   39         VIEW OF 'PS_YYXX_XLATTABLE' (Cost=17 Card=2 Bytes=54
  41   40           SORT (UNIQUE) (Cost=17 Card=2 Bytes=133)
  42   41             UNION-ALL
  43   42               FILTER
  44   43                 FILTER
  45   44                   TABLE ACCESS (BY INDEX ROWID) OF 'PSXLATIT
          EM' (Cost=2 Card=1 Bytes=51)
  46   45                     INDEX (RANGE SCAN) OF 'PS_PSXLATITEM' (U
          NIQUE) (Cost=2 Card=1)
  47   43                 SORT (AGGREGATE)
  48   47                   FILTER
  49   48                     INDEX (RANGE SCAN) OF 'PS_PSXLATITEM' (U
          NIQUE) (Cost=2 Card=1 Bytes=26)
  50   42               FILTER
  51   50                 NESTED LOOPS (Cost=3 Card=1 Bytes=82)
  52   51                   TABLE ACCESS (BY INDEX ROWID) OF 'PSXLATIT
          EMLANG' (Cost=2 Card=1 Bytes=54)
  53   52                     INDEX (RANGE SCAN) OF 'PS_PSXLATITEMLANG
          ' (UNIQUE) (Cost=2 Card=1)
  54   51                   TABLE ACCESS (BY INDEX ROWID) OF 'PSXLATIT
          EM' (Cost=1 Card=1 Bytes=28)
  55   54                     INDEX (UNIQUE SCAN) OF 'PS_PSXLATITEM' (
          UNIQUE)
  56   50                 SORT (AGGREGATE)
  57   56                   FILTER
  58   57                     INDEX (RANGE SCAN) OF 'PS_PSXLATITEM' (U
          NIQUE) (Cost=2 Card=1 Bytes=26)
  59    2       SORT (AGGREGATE)
  60   59         TABLE ACCESS (BY INDEX ROWID) OF 'PS_YYXX_GL_ME_TBL'
           (Cost=4 Card=1 Bytes=29)
  61   60           INDEX (RANGE SCAN) OF 'PS_YYXX_GL_ME_TBL' (UNIQUE)
           (Cost=2 Card=5)
[\pre]
Message was edited by:
        Elvis
Message was edited by:
        Elvis                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Similar Messages

  • Result cache latch contention

    Hi,
    Apologies for double posting!
    I had posted this query to the SQL and PL/SQL forum last week.
    Result cache latch contention: http://forums.oracle.com/forums/thread.jspa?threadID=1553667&tstart=0*
    Posting it here again as I am trying to better understand the RC Latch behavior before using it in our production system.
    Thanks!
    Edited by: kedruwsky on Oct 10, 2010 9:32 PM

    sb92075 wrote:
    Latches exist to manage potential contention.
    What else do you not understand?
    Since latches exist, they will used used regardless if you understand or not.That was profound!
    Did you check the results of the 3 test cases that were executed to check how the RC Latch was used?
    Results of the test cases show how many times the latch was acquired (per invocation and throughout the iterations).
    I want to understand the why behind the results?
    i.e. 2 latch GETS per request and acquire/release of the latch when there is a change in the request signature.
    Also, result of test case 3 does not fit with the observations of test case 1 & 2.
    Concurrent executions of the test cases have shown degraded performance.
    Thus, I am not ready to implement this feature until I understand how it works and if there are any ways to reduce the contention.

  • Reducing shared pool latch contention

    I see a lot of shared pool latch contention on my 11gR2 database because there are over 100 identical schemas that run identical SQL. This causes lots of child cursors to be created. Scheduled jobs kick off hourly for every schema at the same time and that produces contention for shared pool latches for the same parent cursor.
    I want to reduce that contention. Here's my question...
    If I make the SQL text unique by either
    (a) changing the object referenbes from "TableName" to "SchemaName.TableName", or
    (b) adding a comment to the SQL that includes the SchemaName
    ...will that cause a separate cursor to be created in the shared pool?
    I know in older versions even a change in a comment would cause Oracle to treat it as a separate statement. Is that still true in 11gR2?
    FWIW cursor_sharing is set to EXACT.

    Chuck1958 wrote:
    If I make the SQL text unique by either
    (a) changing the object referenbes from "TableName" to "SchemaName.TableName", or
    (b) adding a comment to the SQL that includes the SchemaName
    ...will that cause a separate cursor to be created in the shared pool?
    I know in older versions even a change in a comment would cause Oracle to treat it as a separate statement. Is that still true in 11gR2?
    Yes:
    SQL> select * from v$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    PL/SQL Release 11.2.0.1.0 - Production
    CORE    11.2.0.1.0      Production
    TNS for Linux: Version 11.2.0.1.0 - Production
    NLSRTL Version 11.2.0.1.0 - Production
    SQL> show parameter cursor_sharing
    NAME                                 TYPE        VALUE
    cursor_sharing                       string      EXACT
    SQL> select * /* schema1 */ from t where x=0;
    no rows selected
    SQL> select * /* schema2 */ from t where x=0;
    no rows selected
    SQL> select sql_id, child_number, sql_text
      2  from v$sql
      3  where sql_text like '%/* schema%';
    SQL_ID        CHILD_NUMBER SQL_TEXT
    4d03bxnvbw4ac            0 select * /* schema2 */ from t where x=0
    76xtkkpvfqx1h            0 select * /* schema1 */ from t where x=0
    b3zjvv0cfbhrx            0 select sql_id, child_number, sql_text fr
                               om v$sql where sql_text like '%/* schema
                               %'

  • Latch Contention issues

    Hi,
    We recently upgraded the oracle version from 9.07 to 9.08. Since the upgrade out application has been performing poorly. We spoke to the Oracle DBAs and they identified this to be a latch contention problem. They changed the cursor sharing from exact to similar. They even increased the buffer cache size. But we continue to have performance issues with the database.
    Had anyone come across latch contention issues and how was it resolved? Is there is a bug in 9.08 version? Do we think of downgrading it back to 9.07?
    Please suggest.

    Hi,
    shared pool housekeeping is not as simple as you imagine it to be. It's not like at any given moment of time there is only one "correct" child cursor, the rest being subject to purging, it's much more complex, and the exact housekeeping algorithms are not accessible to us users. Plus, you only have several child curors; I once had over a hundred and raised a SR to that effect -- the customer support represebtatuve said that cursor sharing mechanisms in Oracle aren't perfect and unless one has thousands of child cursors one shouldn't be worried.
    Best regards,
    Nikolay

  • Latch contention in Oracle 10.2.0.4

    Hello All,
    There is one script which takes 8 hours to complete on one of our Oracle 10.2.0.3 databases.
    The TKPROF Output shows the below Wait events:
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file scattered read                      28965        0.00          0.00
      db file sequential read                   1394318        0.00          0.00
      SQL*Net message to client                 4467645        0.00          0.00
      SQL*Net message from client               4467645        0.00          0.00
      latch: shared pool                           2847       29.05        864.44
      latch: library cache                         1221        5.78        389.93
      latch: row cache objects                      126        0.58          2.39
      latch: cache buffers chains                  2765        0.02          0.16
      log file sync                                   3        0.00          0.00
      latch free                                     63        1.06          1.71
      latch: object queue header operation            5        0.00          0.01
      SQL*Net break/reset to client                1156        0.00          0.00
      read by other session                       21609        0.99          3.99
      latch: library cache lock                       1        0.01          0.01How can we reduce the "latch: shared pool" and "latch: library cache" wait/contentions?
    The script in question runs 95 SELECT Statements, 3 UPDATE Statements and 1 INSERT Statement.
    For more information, please let me know. Thanks.
    Suddhasatwa.
    Edited by: user13021719 on Mar 16, 2012 12:27 AM

    Thanks for the above note.
    yes the numbers are correct: there are 95 SELECT statements only in the program as well as in the TRACE file.
    From the output of TKPROF I can see these 2 SELECT Statements taking maximum of these wait events:
    TKPROF: Release 10.2.0.4.0 - Production on Fri Mar 16 01:25:38 2012
    Copyright (c) 1982, 2007, Oracle.  All rights reserved.
    Trace file: hr84tax_ora_3391.trc
    Sort options: exeela  fchela  prsela
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    SELECT PAYCALL2.PAY_BEGIN_DT, PAYCALL2.PAY_END_DT, PAYCALL2.CHECK_DT,
      PSPCL1.COMPANY, PSPCL1.PAYGROUP, PSPCL1.PAY_END_DT, PSPCL1.PAGE_NUM,
      PSPCL1.LINE_NUM, PSPCL1.OFF_CYCLE, PSPCL1.SEPCHK, PSPCL1.EMPLID,
      PSPCL1.CHECK_DT, PSPCL1.PAYCHECK_OPTION, PSPCL1.PAYCHECK_STATUS
    FROM
      PS_PAY_CHECK PSPCL1, PS_PAY_CALENDAR PAYCALL2, PS_PAY_CAL_BAL_ID BALL1
      WHERE    PAYCALL2.COMPANY     = BALL1.COMPANY AND PAYCALL2.PAYGROUP    =
      BALL1.PAYGROUP AND PAYCALL2.PAY_END_DT  = BALL1.PAY_END_DT AND
      BALL1.BALANCE_ID     = :1 AND PAYCALL2.CHECK_DT   >= :2 AND
      PAYCALL2.CHECK_DT   <= :3 AND PSPCL1.COMPANY       = :4 AND PSPCL1.EMPLID
           = :5 AND PSPCL1.COMPANY       = PAYCALL2.COMPANY AND PSPCL1.PAYGROUP
         = PAYCALL2.PAYGROUP AND PSPCL1.PAY_END_DT    = PAYCALL2.PAY_END_DT AND
      PSPCL1.PAYCHECK_STATUS IN ('F','R','A') ORDER BY PAYCALL2.CHECK_DT
    call     count       cpu    elapsed       disk      query    current        rows
    Parse    11087      0.00       0.60          0          0          0           0
    Execute  15222      0.00      17.59         11         22          0           0
    Fetch    30444      0.00   16726.93     976663    8991463          0       23572
    total    56753      0.00   16745.12     976674    8991485          0       23572
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 28
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      latch: shared pool                             60        1.34         10.00
      latch: library cache                           22        0.34          0.86
      SQL*Net message to client                   41531        0.00          0.00
      SQL*Net message from client                 41531        0.00          0.00
      db file sequential read                    976663        0.00          0.00
      latch: cache buffers chains                     2        0.00          0.00
      latch: object queue header operation            2        0.00          0.00
    SELECT JB.OFFICER_CD, JB.EMPL_CLASS, JB.JOBCODE, JB.PAYGROUP,
      JB.BUSINESS_UNIT, JB.STD_HOURS, JB.STD_HRS_FREQUENCY, JB.COMPRATE,
      JB.EMPL_STATUS, JB.TAX_LOCATION_CD, JB.LOCATION, JB.EMPL_TYPE, JB.HOURLY_RT,
       JB.EFFDT, JB.EFFSEQ, JB.EMPL_RCD, JB.DEPTID, JB.SETID_JOBCODE, JB.ESTABID,
      JB.SAL_ADMIN_PLAN, JB.FICA_STATUS_EE, JB.SETID_LOCATION
    from
      PS_JOB JB  Where JB.EMPLID     = :1 AND JB.COMPANY  = :2 AND JB.EFFDT =
      (SELECT MAX(JB1.EFFDT) FROM   PS_JOB JB1  WHERE JB1.EMPLID    = JB.EMPLID
      AND JB1.COMPANY   = JB.COMPANY AND JB1.EFFDT <= :3) AND JB.EFFSEQ = (SELECT
      MAX(JB2.EFFSEQ) FROM  PS_JOB JB2  WHERE JB2.EMPLID   = JB.EMPLID AND
      JB2.COMPANY   = JB.COMPANY AND JB2.EFFDT     = JB.EFFDT) ORDER by JB.EFFDT,
      JB.EFFSEQ
    call     count       cpu    elapsed       disk      query    current        rows
    Parse    14305      0.00       1.62          0          0          0           0
    Execute  25852      0.00      62.80          0         44          0           0
    Fetch    51704      0.00    2429.58     167169    1036420          0       25888
    total    91861      0.00    2494.01     167169    1036464          0       25888
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 28
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      latch: shared pool                            242        9.08         66.46
      latch: library cache                          108        5.78         61.32
      latch: row cache objects                       23        0.06          0.20
      SQL*Net message to client                   66009        0.00          0.00
      SQL*Net message from client                 66009        0.00          0.00
      db file sequential read                    167169        0.00          0.00
      latch free                                      1        0.04          0.04
      read by other session                           1        0.00          0.00
    ********************************************************************************The OEM tuning advisor does not recommend any tuning options for these.
    Please advice.
    For more information, please let me know.
    Thanks
    Suddhasatwa
    Edited by: user13021719 on Mar 16, 2012 12:27 AM

  • "latch: row cache objects" and high "VERSION_COUNT"

    Hello,
    we are being faced with a situation where the database spends most of it's time waiting for latches in the shared pool (as seen in the AWR report).
    All statements issued by the application are using bind variables, but what we can see in V$SQL is that even though the statements are using bind variables some of them have a relatively high version_count (> 300) and many invaliadations (100 - 200) even though the tables involved are very small (some not more than 3 or 4 rows).
    Here is some (hopefully enough) information about the environment
    Version: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production (on RedHat EL 5)
    Parameters:
    cursor_bind_capture_destination       memory+disk
    cursor_sharing                        EXACT
    cursor_space_for_time                 FALSE
    filesystemio_options                  none
    hi_shared_memory_address              0
    memory_max_target                     12288M
    memory_target                         12288M
    object_cache_optimal_size             102400
    open_cursors                          300
    optimizer_capture_sql_plan_baselines  FALSE
    optimizer_dynamic_sampling            2
    optimizer_features_enable             11.2.0.2
    optimizer_index_caching               0
    optimizer_index_cost_adj              100
    optimizer_mode                        ALL_ROWS
    optimizer_secure_view_merging         TRUE
    optimizer_use_invisible_indexes       FALSE
    optimizer_use_pending_statistics      FALSE
    optimizer_use_sql_plan_baselines      TRUE
    plsql_optimize_level                  2
    session_cached_cursors                50
    shared_memory_address                 0The shared pool size (according to AWR) is 4,832M     
    The buffer cache is 3,008M     
    Now, my question: is a version_count of > 300 a problem (we have about 10-15 of those with a total of ~7000 statements in v$sqlarea). Those are also the statements listed in the AWR report at the top in the section "SQL ordered by Version Count" and "SQL ordered by Sharable Memory"
    Is it possible that those statements are causing the the latch contention in the shared pool?
    I went through https://blogs.oracle.com/optimizer/entry/why_are_there_more_cursors_in_11g_for_my_query_containing_bind_variables_1
    The tables involved are fairly small and all the execution plans for each cursor are identical.
    I can understand some of the invalidations that happen, because we have 7 schemas that have identical tables, but from my understanding that shouldn't cause such a high invalidation number. Or am I mistaken?
    I'm not that experienced with Oracle tuning at that level, so I would appreciate any pointer on how I can find out where exactly the latch problem occurs
    After flushing the shared pool, the problem seems to go away for a while. But apparently that is only fighting symptoms, not fixing the root cause of the problem.
    Some of the statements in question:
    SELECT * FROM QRTZ_SIMPLE_TRIGGERS WHERE TRIGGER_NAME = :1 AND TRIGGER_GROUP = :2
    UPDATE QRTZ_TRIGGERS SET TRIGGER_STATE = :1 WHERE TRIGGER_NAME = :2 AND TRIGGER_GROUP = :3 AND TRIGGER_STATE = :4
    UPDATE QRTZ_TRIGGERS SET TRIGGER_STATE = :1 WHERE JOB_NAME = :2 AND JOB_GROUP = :3 AND TRIGGER_STATE = :4
    SELECT TRIGGER_STATE FROM QRTZ_TRIGGERS WHERE TRIGGER_NAME = :1 AND TRIGGER_GROUP = :2
    UPDATE QRTZ_SIMPLE_TRIGGERS SET REPEAT_COUNT = :1, REPEAT_INTERVAL = :2, TIMES_TRIGGERED = :3 WHERE TRIGGER_NAME = :4 AND TRIGGER_GROUP = :5
    DELETE FROM QRTZ_TRIGGER_LISTENERS WHERE TRIGGER_NAME = :1 AND TRIGGER_GROUP = :2So all of them are using bind variables.
    I have seen that the columns used in the where clause all have histograms available. Would removing them reduce the number of invalidations?
    Unfortunately I did not save the information from v$sql_shared_cursor before the shared pool was flushed, but most of the invalidations occurred in the ROLL_INVALID_MISMATCH column if that is of any help. There are some invalidations reported for AUTH_CHECK_MISMATCH and TRANSLATION_MISMATCH but to my understanding they caused by executing the statement for different schemas if I'm not mistaken.
    Looking at v$latch_missed, most of the waits for parent = 'row cache objects' are for "kqrpre: find obj" and "kqreqd: reget"

    >
    In the AWR report, what does the Dictionary Cache Stats section say?
    >
    Here they are:
    Dictionary Cache Stats                                                                                                     
    Cache                 Get Requests      Pct Miss     Scan Reqs    Mod Reqs      Final Usage                                
    dc_awr_control        65                0.00         0            2             1                                          
    dc_constraints        729               33.33        0            729           1                                          
    dc_global_oids        60                23.33        0            0             31                                         
    dc_histogram_data     7,397             10.53        0            0             2,514                                      
    dc_histogram_defs     21,797            9.83         0            0             5,239                                      
    dc_object_grants      4                 25.00        0            0             12                                         
    dc_objects            27,683            2.29         0            223           2,581                                      
    dc_profiles           1,842             0.00         0            0             1                                          
    dc_rollback_segments  1,634             0.00         0            0             39                                         
    dc_segments           7,335             6.94         0            360           1,679                                      
    dc_sequences          139               5.76         0            139           19                                         
    dc_table_scns         53                100.00       0            0             0                                          
    dc_tablespace_quotas  1,956             0.10         0            0             4                                          
    dc_tablespaces        17,488            0.00         0            0             11                                         
    dc_users              58,013            0.03         0            0             164                                        
    global database name  4,261             0.00         0            0             1                                          
    outstanding_alerts    54                0.00         0            0             9                                          
    sch_lj_oids           4                 0.00         0            0             2                                          
    Library Cache Activity                                                                                                     
    Namespace             Get Requests     Pct Miss     Pin Requests          Pct Miss      Reloads   Invalidations            
    ACCOUNT_STATUS        3,664            0.03         0                                   0         0                        
    BODY                  560              2.14         2,343                 0.60          0         0                        
    CLUSTER               52               0.00         52                    0.00          0         0                        
    DBLINK                3,668            0.00         0                                   0         0                        
    EDITION               1,857            0.00         3,697                 0.00          0         0                        
    INDEX                 99               19.19        99                    19.19         0         0                        
    OBJECT ID             68               100.00       0                                   0         0                        
    SCHEMA                2,646            0.00         0                                   0         0                        
    SQL AREA              32,996           2.26         1,142,497             0.21          189       226                      
    SQL AREA BUILD        848              62.15        0                                   0         0                        
    SQL AREA STATS        860              82.09        860                   82.09         0         0                        
    TABLE/PROCEDURE       17,713           2.62         26,112                4.88          61        0                        
    TRIGGER               1,704            2.00         6,737                 0.52          1         0                        

  • Index  Contention

    Hi,
    Oracle Version:- Oracle Database Enterprise Edition Release 10.2.0.1
    OS- Microsoft Windows 64-Bit 2003R2
    Whenever load on db is increased , my EM shows follwing to me: IX-Lock Contention Found, and Latch- Cache Buffer Chains.
    Can someone please explain what does this mean ?. And what may be possible causes for it ?
    Vinita

    Dear Vinita,
    Let me tell you the magical keyword in your expression;
    Whenever load on db is increasedWhat sort of load? Oracle does not create the lock and latch contention by itself but the application can cripple the database so bad!
    First observe your application and see what the sessions are doing. Run ASH to find out the queries. Run AWR and see the ADDM findings (if you have already purchased the diagnostic pack for your production system, if you are on a test environment just run).
    You can also see the metalink for those events and their information.
    At the end those are contentions and needs to be observed in my opinion.
    Regards.
    Ogan

  • Latches in Oracle9i

    Hi,
    In Oracle9i to tune latches , there's a parameter - DB_BLOCK_LRU_LATCHES which is undocumented..and is automatically set by Oracle in SMP (symmetric multiprocessor) machines.My question is can we set this parameter in Oracle9i to tune the latch contention specially if we have more DBWR 's.This parameter does not show when we give show parameter from v$spparameters.
    How far is this true and if one can throw some light on the topic...u can mail me
    at [email protected]
    regards,
    Shankar

    Hi,
    17:04:03 sys:XXX@hpuxXXX> select * from v$version where rownum=1;
    BANNER
    Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
    1 row selected.
    Elapsed: 00:00:00.00
    17:04:12 sys:XXX@hpuxXXX> SELECT
    17:04:19   2  a.ksppinm "Parameter",
    17:04:19   3  a.ksppdesc "Description",
    17:04:20   4  b.ksppstvl "Session Value",
    17:04:20   5  c.ksppstvl "Instance Value"
    17:04:20   6  FROM
    17:04:20   7  x$ksppi a,
    17:04:20   8  x$ksppcv b,
    17:04:21   9  x$ksppsv c
    17:04:21  10  WHERE
    17:04:21  11  a.indx = b.indx
    17:04:21  12  AND
    17:04:21  13  a.indx = c.indx
    17:04:21  14  AND
    17:04:21  15  a.ksppinm LIKE  '%db%block%lru%latches%';
    Parameter                Description            Session Value  Instance Value
    _db_block_lru_latches    number of lru latches  32             32
    1 row selected.As with all those undocumented/hidden parameters, you must not set them except when asked to by Oracle (under a SR/TAR). So, well, you can, but you should absolutely avoid this, and should get back to the basics: why is there latches? are my sql statements optimized? do I read just what is needed? etc
    Regards,
    Yoann.

  • How to find Latch and what actions need to be taken when there is a latch

    Hi
    Can you please tell me how to find Latch and what actions need to be taken when there is a latch?
    Thanks
    Regards,
    RJ.

    1. What is a latch?
    Latches are low level serialization mechanisms used to protect shared
    data structures in the SGA. The implementation of latches is operating
    system dependent, particularly in regard to whether a process will wait
    for a latch and for how long.
    A latch is a type of a lock that can be very quickly acquired and freed.
    Latches are typically used to prevent more than one process from
    executing the same piece of code at a given time. Associated with each
    latch is a cleanup procedure that will be called if a process dies while
    holding the latch. Latches have an associated level that is used to
    prevent deadlocks. Once a process acquires a latch at a certain level it
    cannot subsequently acquire a latch at a level that is equal to or less
    than that level (unless it acquires it nowait).
    2. Latches vs Enqueues
    Enqueues are another type of locking mechanism used in Oracle.
    An enqueue is a more sophisticated mechanism which permits several concurrent
    processes to have varying degree of sharing of "known" resources. Any object
    which can be concurrently used, can be protected with enqueues. A good example
    is of locks on tables. We allow varying levels of sharing on tables e.g.
    two processes can lock a table in share mode or in share update mode etc.
    One difference is that the enqueue is obtained using an OS specific
    locking mechanism. An enqueue allows the user to store a value in the lock,
    i.e the mode in which we are requesting it. The OS lock manager keeps track
    of the resources locked. If a process cannot be granted the lock because it
    is incompatible with the mode requested and the lock is requested with wait,
    the OS puts the requesting process on a wait queue which is serviced in FIFO.
    Another difference between latches and enqueues is that
    in latches there is no ordered queue of waiters like in enqueues. Latch
    waiters may either use timers to wakeup and retry or spin (only in
    multiprocessors). Since all waiters are concurrently retrying (depending on
    the scheduler), anyone might get the latch and conceivably the first one to
    try might be the last one to get.
    3. When do we need to obtain a latch?
    A process acquires a latch when working with a structure in the SGA
    (System Global Area). It continues to hold the latch for the period
    of time it works with the structure. The latch is dropped when the
    process is finished with the structure. Each latch protects a different
    set of data, identified by the name of the latch.
    Oracle uses atomic instructions like "test and set" for operating on latches.
    Processes waiting to execute a part of code for which a latch has
    already been obtained by some other process will wait until the
    latch is released. Examples are redo allocation latches, copy
    latches, archive control latch etc. The basic idea is to block concurrent
    access to shared data structures. Since the instructions to
    set and free latches are atomic, the OS guarantees that only one process gets
    it. Since it is only one instruction, it is quite fast. Latches are held
    for short periods of time and provide a mechanism for cleanup in case
    a holder dies abnormally while holding it. This cleaning is done using
    the services of PMON.
    4. Latches request modes?
    Latches request can be made in two modes: "willing-to-wait" or "no wait". Normally,
    latches will be requested in "willing-to-wait" mode. A request in "willing-to-wait" mode
    will loop, wait, and request again until the latch is obtained. In "no wait" mode the process
    request the latch. If one is not available, instead of waiting, another one is requested. Only
    when all fail does the server process have to wait.
    Examples of "willing-to-wait" latches are: shared pool and library cache latches
    A example of "no wait" latches is the redo copy latch.
    5. What causes latch contention?
    If a required latch is busy, the process requesting it spins, tries again
    and if still not available, spins again. The loop is repeated up to a maximum
    number of times determined by the initialization parameter SPINCOUNT.
    If after this entire loop, the latch is still not available, the process must yield
    the CPU and go to sleep. Initially is sleeps for one centisecond. This time is
    doubled in every subsequent sleep.
    This causes a slowdown to occur and results in additional CPU usage,
    until a latch is available. The CPU usage is a consequence of the
    "spinning" of the process. "Spinning" means that the process continues to
    look for the availability of the latch after certain intervals of time,
    during which it sleeps.
    6. How to identify contention for internal latches?
    Relevant data dictionary views to query
    V$LATCH
    V$LATCHHOLDER
    V$LATCHNAME
    Each row in the V$LATCH table contains statistics for a different type
    of latch. The columns of the table reflect activity for different types
    of latch requests. The distinction between these types of requests is
    whether the requesting process continues to request a latch if it
    is unavailable:
    willing-to-wait If the latch requested with a willing-to-wait
    request is not available, the requesting process
    waits a short time and requests the latch again.
    The process continues waiting and requesting until
    the latch is available.
    no wait If the latch requested with an immediate request is
    not available, the requesting process does not
    wait, but continues processing.
    V$LATCHNAME key information:
    GETS Number of successful willing-to-wait requests for
    a latch.
    MISSES Number of times an initial willing-to-wait request
    was unsuccessful.
    SLEEPS Number of times a process waited a requested a latch
    after an initial wiling-to-wait request.
    IMMEDIATE_GETS Number of successful immediate requests for each latch.
    IMMEDIATE_MISSES Number of unsuccessful immediate requests for each latch.
    Calculating latch hit ratio
    To get the Hit ratio for latches apply the following formula:
    "willing-to-wait" Hit Ratio=(GETS-MISSES)/GETS
    "no wait" Hit Ratio=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS
    This number should be close to 1. If not, tune according to the latch name
    7. Useful SQL scripts to get latch information
    ** Display System-wide latch statistics.
    column name format A32 truncate heading "LATCH NAME"
    column pid heading "HOLDER PID"
    select c.name,a.addr,a.gets,a.misses,a.sleeps,
    a.immediate_gets,a.immediate_misses,b.pid
    from v$latch a, v$latchholder b, v$latchname c
    where a.addr = b.laddr(+)
    and a.latch# = c.latch#
    order by a.latch#;
    ** Given a latch address, find out the latch name.
    column name format a64 heading 'Name'
    select a.name from v$latchname a, v$latch b
    where b.addr = '&addr'
    and b.latch#=a.latch#;
    ** Display latch statistics by latch name.
    column name format a32 heading 'LATCH NAME'
    column pid heading 'HOLDER PID'
    select c.name,a.addr,a.gets,a.misses,a.sleeps,
    a.immediate_gets,a.immediate_misses,b.pid
    from v$latch a, v$latchholder b, v$latchname c
    where a.addr = b.laddr(+) and a.latch# = c.latch#
    and c.name like '&latch_name%' order by a.latch#;
    8. List of all the latches
    Oracle versions might differ in the latch# assigned to the existing latches.
    The following query will help you to identify all latches and the number assigned.
    column name format a40 heading 'LATCH NAME'
    select latch#, name from v$latchname;

  • Why the event latch: cache buffers chains wait event arises and resolution

    Can any one please give full information about:
    latch: cache buffers chains wait event
    Why this event arises and resolution?

    Google gave me
    http://www.pythian.com/news/1135/tuning-latch-contention-cache-buffers-chain-latches/

  • Lock & latch

    Hello,
    could any one has good stuff to monitor and diagnose lock and latch contention in database

    dbcontrol comes free with the database
    http://download.oracle.com/docs/cd/B28359_01/server.111/b28319/emca.htm
    HTH
    Srini

  • Active session Spike on Oracle RAC 11G R2 on HP UX

    Dear Experts,
    We need urgent help please, as we are facing very low performance in production database.
    We are having oracle 11G RAC on HP Unix environment. Following is the ADDM report. Kindly check and please help me to figure it out the issue and resolve it at earliest.
    ---------Instance 1---------------
              ADDM Report for Task 'TASK_36650'
    Analysis Period
    AWR snapshot range from 11634 to 11636.
    Time period starts at 21-JUL-13 07.00.03 PM
    Time period ends at 21-JUL-13 09.00.49 PM
    Analysis Target
    Database 'MCMSDRAC' with DB ID 2894940361.
    Database version 11.2.0.1.0.
    ADDM performed an analysis of instance mcmsdrac1, numbered 1 and hosted at
    mcmsdbl1.
    Activity During the Analysis Period
    Total database time was 38466 seconds.
    The average number of active sessions was 5.31.
    Summary of Findings
       Description           Active Sessions      Recommendations
                             Percent of Activity  
    1  CPU Usage             1.44 | 27.08         1
    2  Interconnect Latency  .07 | 1.33           1
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              Findings and Recommendations
    Finding 1: CPU Usage
    Impact is 1.44 active sessions, 27.08% of total activity.
    Host CPU was a bottleneck and the instance was consuming 99% of the host CPU.
    All wait times will be inflated by wait for CPU.
    Host CPU consumption was 99%.
       Recommendation 1: Host Configuration
       Estimated benefit is 1.44 active sessions, 27.08% of total activity.
       Action
          Consider adding more CPUs to the host or adding instances serving the
          database on other hosts.
       Action
          Session CPU consumption was throttled by the Oracle Resource Manager.
          Consider revising the resource plan that was active during the analysis
          period.
    Finding 2: Interconnect Latency
    Impact is .07 active sessions, 1.33% of total activity.
    Higher than expected latency of the cluster interconnect was responsible for
    significant database time on this instance.
    The instance was consuming 110 kilo bits per second of interconnect bandwidth.
    20% of this interconnect bandwidth was used for global cache messaging, 21%
    for parallel query messaging and 7% for database lock management.
    The average latency for 8K interconnect messages was 42153 microseconds.
    The instance is using the private interconnect device "lan2" with IP address
    172.16.200.71 and source "Oracle Cluster Repository".
    The device "lan2" was used for 100% of interconnect traffic and experienced 0
    send or receive errors during the analysis period.
       Recommendation 1: Host Configuration
       Estimated benefit is .07 active sessions, 1.33% of total activity.
       Action
          Investigate cause of high network interconnect latency between database
          instances. Oracle's recommended solution is to use a high speed
          dedicated network.
       Action
          Check the configuration of the cluster interconnect. Check OS setup like
          adapter setting, firmware and driver release. Check that the OS's socket
          receive buffers are large enough to store an entire multiblock read. The
          value of parameter "db_file_multiblock_read_count" may be decreased as a
          workaround.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              Additional Information
    Miscellaneous Information
    Wait class "Application" was not consuming significant database time.
    Wait class "Cluster" was not consuming significant database time.
    Wait class "Commit" was not consuming significant database time.
    Wait class "Concurrency" was not consuming significant database time.
    Wait class "Configuration" was not consuming significant database time.
    Wait class "Network" was not consuming significant database time.
    Wait class "User I/O" was not consuming significant database time.
    Session connect and disconnect calls were not consuming significant database
    time.
    Hard parsing of SQL statements was not consuming significant database time.
    The database's maintenance windows were active during 100% of the analysis
    period.
    ----------------Instance 2 --------------------
              ADDM Report for Task 'TASK_36652'
    Analysis Period
    AWR snapshot range from 11634 to 11636.
    Time period starts at 21-JUL-13 07.00.03 PM
    Time period ends at 21-JUL-13 09.00.49 PM
    Analysis Target
    Database 'MCMSDRAC' with DB ID 2894940361.
    Database version 11.2.0.1.0.
    ADDM performed an analysis of instance mcmsdrac2, numbered 2 and hosted at
    mcmsdbl2.
    Activity During the Analysis Period
    Total database time was 2898 seconds.
    The average number of active sessions was .4.
    Summary of Findings
        Description                 Active Sessions      Recommendations
                                    Percent of Activity  
    1   Top SQL Statements          .11 | 27.65          5
    2   Interconnect Latency        .1 | 24.15           1
    3   Shared Pool Latches         .09 | 22.42          1
    4   PL/SQL Execution            .06 | 14.39          2
    5   Unusual "Other" Wait Event  .03 | 8.73           4
    6   Unusual "Other" Wait Event  .03 | 6.42           3
    7   Unusual "Other" Wait Event  .03 | 6.29           6
    8   Hard Parse                  .02 | 5.5            0
    9   Soft Parse                  .02 | 3.86           2
    10  Unusual "Other" Wait Event  .01 | 3.75           4
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              Findings and Recommendations
    Finding 1: Top SQL Statements
    Impact is .11 active sessions, 27.65% of total activity.
    SQL statements consuming significant database time were found. These
    statements offer a good opportunity for performance improvement.
       Recommendation 1: SQL Tuning
       Estimated benefit is .05 active sessions, 12.88% of total activity.
       Action
          Investigate the PL/SQL statement with SQL_ID "d1s02myktu19h" for
          possible performance improvements. You can supplement the information
          given here with an ASH report for this SQL_ID.
          Related Object
             SQL statement with SQL_ID d1s02myktu19h.
             begin dbms_utility.validate(:1,:2,:3,:4); end;
       Rationale
          The SQL Tuning Advisor cannot operate on PL/SQL statements.
       Rationale
          Database time for this SQL was divided as follows: 13% for SQL
          execution, 2% for parsing, 85% for PL/SQL execution and 0% for Java
          execution.
       Rationale
          SQL statement with SQL_ID "d1s02myktu19h" was executed 48 times and had
          an average elapsed time of 7 seconds.
       Rationale
          Waiting for event "library cache pin" in wait class "Concurrency"
          accounted for 70% of the database time spent in processing the SQL
          statement with SQL_ID "d1s02myktu19h".
       Rationale
          Top level calls to execute the PL/SQL statement with SQL_ID
          "63wt8yna5umd6" are responsible for 100% of the database time spent on
          the PL/SQL statement with SQL_ID "d1s02myktu19h".
          Related Object
             SQL statement with SQL_ID 63wt8yna5umd6.
             begin DBMS_UTILITY.COMPILE_SCHEMA( 'TPAUSER', FALSE ); end;
       Recommendation 2: SQL Tuning
       Estimated benefit is .02 active sessions, 4.55% of total activity.
       Action
          Run SQL Tuning Advisor on the SELECT statement with SQL_ID
          "fk3bh3t41101x".
          Related Object
             SQL statement with SQL_ID fk3bh3t41101x.
             SELECT MEM.MEMBER_CODE ,MEM.E_NAME,Pol.Policy_no
             ,pol.date_from,pol.date_to,POL.E_NAME,MEM.SEX,(SYSDATE-MEM.BIRTH_DATE
             ) AGE,POL.SCHEME_NO FROM TPAUSER.MEMBERS MEM,TPAUSER.POLICY POL WHERE
             POL.QUOTATION_NO=MEM.QUOTATION_NO AND POL.BRANCH_CODE=MEM.BRANCH_CODE
             and endt_no=(select max(endt_no) from tpauser.members mm where
             mm.member_code=mem.member_code AND mm.QUOTATION_NO=MEM.QUOTATION_NO)
             and member_code like '%' || nvl(:1,null) ||'%' ORDER BY MEMBER_CODE
       Rationale
          The SQL spent 92% of its database time on CPU, I/O and Cluster waits.
          This part of database time may be improved by the SQL Tuning Advisor.
       Rationale
          Database time for this SQL was divided as follows: 100% for SQL
          execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
          execution.
       Rationale
          SQL statement with SQL_ID "fk3bh3t41101x" was executed 14 times and had
          an average elapsed time of 4.9 seconds.
       Rationale
          At least one execution of the statement ran in parallel.
       Recommendation 3: SQL Tuning
       Estimated benefit is .02 active sessions, 3.79% of total activity.
       Action
          Run SQL Tuning Advisor on the SELECT statement with SQL_ID
          "7mhjbjg9ntqf5".
          Related Object
             SQL statement with SQL_ID 7mhjbjg9ntqf5.
             SELECT SUM(CNT) FROM (SELECT COUNT(PROC_CODE) CNT FROM
             TPAUSER.TORBINY_PROCEDURE WHERE BRANCH_CODE = :B6 AND QUOTATION_NO =
             :B5 AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND PR_EFFECTIVE_DATE<=
             :B2 AND PROC_CODE = :B1 UNION SELECT COUNT(MED_CODE) CNT FROM
             TPAUSER.TORBINY_MEDICINE WHERE BRANCH_CODE = :B6 AND QUOTATION_NO =
             :B5 AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND M_EFFECTIVE_DATE<= :B2
             AND MED_CODE = :B1 UNION SELECT COUNT(LAB_CODE) CNT FROM
             TPAUSER.TORBINY_LAB WHERE BRANCH_CODE = :B6 AND QUOTATION_NO = :B5
             AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND L_EFFECTIVE_DATE<= :B2 AND
             LAB_CODE = :B1 )
       Rationale
          The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
          This part of database time may be improved by the SQL Tuning Advisor.
       Rationale
          Database time for this SQL was divided as follows: 0% for SQL execution,
          0% for parsing, 100% for PL/SQL execution and 0% for Java execution.
       Rationale
          SQL statement with SQL_ID "7mhjbjg9ntqf5" was executed 31 times and had
          an average elapsed time of 3.4 seconds.
       Rationale
          Top level calls to execute the SELECT statement with SQL_ID
          "a11nzdnd91gsg" are responsible for 100% of the database time spent on
          the SELECT statement with SQL_ID "7mhjbjg9ntqf5".
          Related Object
             SQL statement with SQL_ID a11nzdnd91gsg.
             SELECT POLICY_NO,SCHEME_NO FROM TPAUSER.POLICY WHERE QUOTATION_NO
             =:B1
       Recommendation 4: SQL Tuning
       Estimated benefit is .01 active sessions, 3.03% of total activity.
       Action
          Investigate the SELECT statement with SQL_ID "4uqs4jt7aca5s" for
          possible performance improvements. You can supplement the information
          given here with an ASH report for this SQL_ID.
          Related Object
             SQL statement with SQL_ID 4uqs4jt7aca5s.
             SELECT DISTINCT USER_ID FROM GV$SESSION, USERS WHERE UPPER (USERNAME)
             = UPPER (USER_ID) AND USERS.APPROVAL_CLAIM='VC' AND USER_ID=:B1
       Rationale
          The SQL spent only 0% of its database time on CPU, I/O and Cluster
          waits. Therefore, the SQL Tuning Advisor is not applicable in this case.
          Look at performance data for the SQL to find potential improvements.
       Rationale
          Database time for this SQL was divided as follows: 100% for SQL
          execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
          execution.
       Rationale
          SQL statement with SQL_ID "4uqs4jt7aca5s" was executed 261 times and had
          an average elapsed time of 0.35 seconds.
       Rationale
          At least one execution of the statement ran in parallel.
       Rationale
          Top level calls to execute the PL/SQL statement with SQL_ID
          "91vt043t78460" are responsible for 100% of the database time spent on
          the SELECT statement with SQL_ID "4uqs4jt7aca5s".
          Related Object
             SQL statement with SQL_ID 91vt043t78460.
             begin TPAUSER.RECEIVE_NEW_FAX_APRROVAL(:V00001,:V00002,:V00003,:V0000
             4); end;
       Recommendation 5: SQL Tuning
       Estimated benefit is .01 active sessions, 3.03% of total activity.
       Action
          Run SQL Tuning Advisor on the SELECT statement with SQL_ID
          "7kt28fkc0yn5f".
          Related Object
             SQL statement with SQL_ID 7kt28fkc0yn5f.
             SELECT COUNT(*) FROM TPAUSER.APPROVAL_MASTER WHERE APPROVAL_STATUS IS
             NULL AND (UPPER(CODED) = UPPER(:B1 ) OR UPPER(PROCESSED_BY) =
             UPPER(:B1 ))
       Rationale
          The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
          This part of database time may be improved by the SQL Tuning Advisor.
       Rationale
          Database time for this SQL was divided as follows: 100% for SQL
          execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
          execution.
       Rationale
          SQL statement with SQL_ID "7kt28fkc0yn5f" was executed 1034 times and
          had an average elapsed time of 0.063 seconds.
       Rationale
          Top level calls to execute the PL/SQL statement with SQL_ID
          "91vt043t78460" are responsible for 100% of the database time spent on
          the SELECT statement with SQL_ID "7kt28fkc0yn5f".
          Related Object
             SQL statement with SQL_ID 91vt043t78460.
             begin TPAUSER.RECEIVE_NEW_FAX_APRROVAL(:V00001,:V00002,:V00003,:V0000
             4); end;
    Finding 2: Interconnect Latency
    Impact is .1 active sessions, 24.15% of total activity.
    Higher than expected latency of the cluster interconnect was responsible for
    significant database time on this instance.
    The instance was consuming 128 kilo bits per second of interconnect bandwidth.
    17% of this interconnect bandwidth was used for global cache messaging, 6% for
    parallel query messaging and 8% for database lock management.
    The average latency for 8K interconnect messages was 41863 microseconds.
    The instance is using the private interconnect device "lan2" with IP address
    172.16.200.72 and source "Oracle Cluster Repository".
    The device "lan2" was used for 100% of interconnect traffic and experienced 0
    send or receive errors during the analysis period.
       Recommendation 1: Host Configuration
       Estimated benefit is .1 active sessions, 24.15% of total activity.
       Action
          Investigate cause of high network interconnect latency between database
          instances. Oracle's recommended solution is to use a high speed
          dedicated network.
       Action
          Check the configuration of the cluster interconnect. Check OS setup like
          adapter setting, firmware and driver release. Check that the OS's socket
          receive buffers are large enough to store an entire multiblock read. The
          value of parameter "db_file_multiblock_read_count" may be decreased as a
          workaround.
       Symptoms That Led to the Finding:
          Inter-instance messaging was consuming significant database time on this
          instance.
          Impact is .06 active sessions, 14.23% of total activity.
             Wait class "Cluster" was consuming significant database time.
             Impact is .06 active sessions, 14.23% of total activity.
    Finding 3: Shared Pool Latches
    Impact is .09 active sessions, 22.42% of total activity.
    Contention for latches related to the shared pool was consuming significant
    database time.
    Waits for "library cache lock" amounted to 5% of database time.
    Waits for "library cache pin" amounted to 17% of database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .09 active sessions, 22.42% of total activity.
       Action
          Investigate the cause for latch contention using the given blocking
          sessions or modules.
       Rationale
          The session with ID 17 and serial number 15595 in instance number 1 was
          the blocking session responsible for 34% of this recommendation's
          benefit.
       Symptoms That Led to the Finding:
          Wait class "Concurrency" was consuming significant database time.
          Impact is .1 active sessions, 24.96% of total activity.
    Finding 4: PL/SQL Execution
    Impact is .06 active sessions, 14.39% of total activity.
    PL/SQL execution consumed significant database time.
       Recommendation 1: SQL Tuning
       Estimated benefit is .05 active sessions, 12.5% of total activity.
       Action
          Tune the entry point PL/SQL "SYS.DBMS_UTILITY.COMPILE_SCHEMA" of type
          "PACKAGE" and ID 6019. Refer to the PL/SQL documentation for addition
          information.
       Rationale
          318 seconds spent in executing PL/SQL "SYS.DBMS_UTILITY.VALIDATE#2" of
          type "PACKAGE" and ID 6019.
       Recommendation 2: SQL Tuning
       Estimated benefit is .01 active sessions, 1.89% of total activity.
       Action
          Tune the entry point PL/SQL
          "SYSMAN.EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS" of type "PACKAGE" and
          ID 68654. Refer to the PL/SQL documentation for addition information.
    Finding 5: Unusual "Other" Wait Event
    Impact is .03 active sessions, 8.73% of total activity.
    Wait event "DFS lock handle" in wait class "Other" was consuming significant
    database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .03 active sessions, 8.73% of total activity.
       Action
          Investigate the cause for high "DFS lock handle" waits. Refer to
          Oracle's "Database Reference" for the description of this wait event.
       Recommendation 2: Application Analysis
       Estimated benefit is .03 active sessions, 8.27% of total activity.
       Action
          Investigate the cause for high "DFS lock handle" waits in Service
          "mcmsdrac".
       Recommendation 3: Application Analysis
       Estimated benefit is .02 active sessions, 5.05% of total activity.
       Action
          Investigate the cause for high "DFS lock handle" waits in Module "TOAD
          9.7.2.5".
       Recommendation 4: Application Analysis
       Estimated benefit is .01 active sessions, 3.21% of total activity.
       Action
          Investigate the cause for high "DFS lock handle" waits in Module
          "toad.exe".
       Symptoms That Led to the Finding:
          Wait class "Other" was consuming significant database time.
          Impact is .15 active sessions, 38.29% of total activity.
    Finding 6: Unusual "Other" Wait Event
    Impact is .03 active sessions, 6.42% of total activity.
    Wait event "reliable message" in wait class "Other" was consuming significant
    database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .03 active sessions, 6.42% of total activity.
       Action
          Investigate the cause for high "reliable message" waits. Refer to
          Oracle's "Database Reference" for the description of this wait event.
       Recommendation 2: Application Analysis
       Estimated benefit is .03 active sessions, 6.42% of total activity.
       Action
          Investigate the cause for high "reliable message" waits in Service
          "mcmsdrac".
       Recommendation 3: Application Analysis
       Estimated benefit is .02 active sessions, 4.13% of total activity.
       Action
          Investigate the cause for high "reliable message" waits in Module "TOAD
          9.7.2.5".
       Symptoms That Led to the Finding:
          Wait class "Other" was consuming significant database time.
          Impact is .15 active sessions, 38.29% of total activity.
    Finding 7: Unusual "Other" Wait Event
    Impact is .03 active sessions, 6.29% of total activity.
    Wait event "enq: PS - contention" in wait class "Other" was consuming
    significant database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .03 active sessions, 6.29% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits. Refer to
          Oracle's "Database Reference" for the description of this wait event.
       Recommendation 2: Application Analysis
       Estimated benefit is .02 active sessions, 6.02% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits in Service
          "mcmsdrac".
       Recommendation 3: Application Analysis
       Estimated benefit is .02 active sessions, 4.93% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits with
          P1,P2,P3 ("name|mode, instance, slave ID") values "1347616774", "1" and
          "3599" respectively.
       Recommendation 4: Application Analysis
       Estimated benefit is .01 active sessions, 2.74% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits in Module
          "Inbox Reader_92.exe".
       Recommendation 5: Application Analysis
       Estimated benefit is .01 active sessions, 2.74% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits in Module
          "TOAD 9.7.2.5".
       Recommendation 6: Application Analysis
       Estimated benefit is .01 active sessions, 1.37% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits with
          P1,P2,P3 ("name|mode, instance, slave ID") values "1347616774", "1" and
          "3598" respectively.
       Symptoms That Led to the Finding:
          Wait class "Other" was consuming significant database time.
          Impact is .15 active sessions, 38.29% of total activity.
    Finding 8: Hard Parse
    Impact is .02 active sessions, 5.5% of total activity.
    Hard parsing of SQL statements was consuming significant database time.
    Hard parses due to cursor environment mismatch were not consuming significant
    database time.
    Hard parsing SQL statements that encountered parse errors was not consuming
    significant database time.
    Hard parses due to literal usage and cursor invalidation were not consuming
    significant database time.
    The Oracle instance memory (SGA and PGA) was adequately sized.
       No recommendations are available.
       Symptoms That Led to the Finding:
          Contention for latches related to the shared pool was consuming
          significant database time.
          Impact is .09 active sessions, 22.42% of total activity.
             Wait class "Concurrency" was consuming significant database time.
             Impact is .1 active sessions, 24.96% of total activity.
    Finding 9: Soft Parse
    Impact is .02 active sessions, 3.86% of total activity.
    Soft parsing of SQL statements was consuming significant database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .02 active sessions, 3.86% of total activity.
       Action
          Investigate application logic to keep open the frequently used cursors.
          Note that cursors are closed by both cursor close calls and session
          disconnects.
       Recommendation 2: Database Configuration
       Estimated benefit is .02 active sessions, 3.86% of total activity.
       Action
          Consider increasing the session cursor cache size by increasing the
          value of parameter "session_cached_cursors".
       Rationale
          The value of parameter "session_cached_cursors" was "100" during the
          analysis period.
       Symptoms That Led to the Finding:
          Contention for latches related to the shared pool was consuming
          significant database time.
          Impact is .09 active sessions, 22.42% of total activity.
             Wait class "Concurrency" was consuming significant database time.
             Impact is .1 active sessions, 24.96% of total activity.
    Finding 10: Unusual "Other" Wait Event
    Impact is .01 active sessions, 3.75% of total activity.
    Wait event "IPC send completion sync" in wait class "Other" was consuming
    significant database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .01 active sessions, 3.75% of total activity.
       Action
          Investigate the cause for high "IPC send completion sync" waits. Refer
          to Oracle's "Database Reference" for the description of this wait event.
       Recommendation 2: Application Analysis
       Estimated benefit is .01 active sessions, 3.75% of total activity.
       Action
          Investigate the cause for high "IPC send completion sync" waits with P1
          ("send count") value "1".
       Recommendation 3: Application Analysis
       Estimated benefit is .01 active sessions, 2.59% of total activity.
       Action
          Investigate the cause for high "IPC send completion sync" waits in
          Service "mcmsdrac".
       Recommendation 4: Application Analysis
       Estimated benefit is .01 active sessions, 1.73% of total activity.
       Action
          Investigate the cause for high "IPC send completion sync" waits in
          Module "TOAD 9.7.2.5".
       Symptoms That Led to the Finding:
          Wait class "Other" was consuming significant database time.
          Impact is .15 active sessions, 38.29% of total activity.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              Additional Information
    Miscellaneous Information
    Wait class "Application" was not consuming significant database time.
    Wait class "Commit" was not consuming significant database time.
    Wait class "Configuration" was not consuming significant database time.
    CPU was not a bottleneck for the instance.
    Wait class "Network" was not consuming significant database time.
    Wait class "User I/O" was not consuming significant database time.
    Session connect and disconnect calls were not consuming significant database
    time.
    The database's maintenance windows were active during 100% of the analysis
    period.
    Please help.

    Hello experts...
    Please do the needful... It's really very urgent.
    Thanks,
    Syed

  • Table creation

    Code :
    CREATE TABLE [techforum_member_list](
    [TfmID] INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000000),
    [Name] NVARCHAR(250) NOT NULL INDEX [IName] HASH WITH (BUCKET_COUNT = 1000000),
    [JoiningDate] DATETIME NULL
    WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);
    Error
    Msg 12328, Level 16, State 102, Line 49
    Indexes on character columns that do not use a *_BIN2 collation are not supported with indexes on memory optimized tables.
    Msg 1750, Level 16, State 0, Line 49
    Could not create constraint or index. See previous errors.

    A couple comments in addition to Ahsan reply.
    Keep in mind, that BIN2 collation is case- and accent- sensitive. This could be the breaking change for the application behavior if you decided to convert existing system to use In-Memory OLTP.
    Another one is more the observation on design. In-memory OLTP provides you the most benefits by removing latch contention, e.g. it helps the most with OLTP tables with highly volatile data. Moving static catalog tables to in-memory area are less beneficial.
    Granted, you can get some performance improvements especially with native compilation involved; however, they would not be as noticeable as in case of the tables with volatile transactional data. 
    Thank you!
    Dmitri V. Korotkevitch (MVP, MCM, MCPD)
    My blog: http://aboutsqlserver.com

  • Performance issue with multiple installations of 1 application in 1 databas

    In our company we use JD Edwards. Every branch has its own JD Edwards installation in a separate schema but in the same database (Oracle9i Enterprise Edition Release 9.2.0.7.0) => In 1 database there are 10-20 copies of each table.
    On top of JD Edwards we are developing a Java/JSP application which accesses the JD Edwards data by means of pl/sql stored functions returning ref_cursors. Our DBA states we have to prefix all our tables/views within our stored functions for performance reasons. According to him omitting the schema name would result in increase of hard parses, because the shared_pool can only store 1 occurrence of an sql statement. So only the statement of 1 branch is cached. The execution of the same statement in anothers schema would lead to a hard parse and not to a soft parse.
    For us developers the use of schema names complicates the development process, because we have to use a substitution parameter (&schema_name) in our coding which prevents us from maintaining our code in tools like Toad.
    Questions
    * Does it make sense to use the schema name in this case?
    * Is there another way (not using schema names) to get a good performance in this situation?
    Thanks,
    Matthieu de Graaf

    1) I'm not a JD Edwards person, but I would wager that if you're to the point where you have consolidated all the schemas to a single instance that it would be possible and preferrable to consolidate everything further into a single schema. I have to believe that JD Edwards provides tools to restrict what bits a particular branch can see without requiring separate instances.
    2) What data are you accessing exactly? Are you always accessing data for a particular branch? Or do you need information from every branch?
    3) Is your application logging in as a single user? Or will there be 1 application user for every JD Edwards schema?
    4) Are you deploying your PL/SQL into 10-20 different schemas? Or into just 1?
    Whether or not you are explicitly using the schema name, Oracle will have to do a hard parse of every logically distinct SQL statement. Two SQL statements that access different tables that happen to share the same name are logically distinct, so your shared pool will end up with 10-20 copies of the "SELECT * FROM <<some table name>>" SQL statement if it is executed against every instance of <<some table name>>.
    The question may be whether it is better to explicitly provide the schema name or to rely on synonyms. You generate the same number of hard parses either way, but explicit schema names may improve latch contention during parses if Oracle has to do a lot of synonym resolution. Not many people/ applications are really hurt by this latch contention, though, so it is very hard to say whether this is a legitimate concern.
    Justin

  • Execute immediate on DDL command

    Below sample SQL is 1 of the many code that is running OK in our database. And this code has causes a lot of latch contention to our database and it's being called so many times that cause hard parse.
    /* test code */
    CREATE OR REPLACE PROCEDURE dsal (p_client_id NUMBER) IS
    BEGIN
    EXECUTE IMMEDIATE
    'create table tmp_dsal_'||p_client_id
    ' (client_id number, '||
    ' trade_id number, '||
    ' ps_id number, '||
    ' ps_liquid varchar2(2), '||
    ' status_code varchar2(3) default ''NA'' not null, '||
    ' start_value_dte date, '||
    ' end_value_dte date)';
    EXECUTE IMMEDIATE 'drop table tmp_dsal_'||p_client_id;
    END;
    I want to improve it by using bind variable. The below program compile with no error.
    CREATE OR REPLACE PROCEDURE dsal (p_client_id NUMBER) IS
    BEGIN
    EXECUTE IMMEDIATE
    'create table tmp_dsal_:client_id'||
    ' (client_id number, '||
    ' trade_id number, '||
    ' ps_id number, '||
    ' ps_liquid varchar2(2), '||
    ' status_code varchar2(3) default ''NA'' not null, '||
    ' start_value_dte date, '||
    ' end_value_dte date)' using p_client_id;
    EXECUTE IMMEDIATE 'drop table tmp_dsal_:client_id' using p_client_id;
    END;
    When I execute it, I'm getting the below error. I understand DML statement using bind variable in execute immediate command but not sure on DDL. Is there a workaround on issue or this is limitation?
    SQL> exec dsal(223);
    BEGIN dsal(223); END;
    ERROR at line 1:
    ORA-00922: missing or invalid option
    ORA-06512: at "SYS.DSAL", line 3
    ORA-06512: at line 1
    Appreciate any comment/help. Thanks

    Assuming that all of the client load processes run in seperate session, then do this once in the database and use this global temporary table for the loads. A GTT is a permanent object in the database, but the data it contains is only visible to the session that inserts it. Multiple sessions can access the same GTT at the same time, and will never see each other's data.
    CREATE TEMPORARY TABLE tmp_dsal (
       client_id       NUMBER,
       trade_id        NUMBER,
       ps_id           NUMBER,
       ps_liquid       VARCHAR2(2),
       status_code     VARCHAR2(3) DEFAULT 'NA' NOT NULL,
       start_value_dte DATE,
       end_value_dte   DATE)
    ON COMMIT [PRESERVE|DELETE] ROWSThe on commit clause determines what happens to the data in the GTT when the session that created the data issues a commit. DELETE will automaticall delete all of that session's data while PRESERVE will keep the data until the session either explicitly deletes it or the session ends.
    John

Maybe you are looking for

  • Best way to migrate iTunes and iPod to new hard drive

    Currently, my iTunes Library is referencing music files that sit on my music data drive (E:drive). My Library is actually on another data drive (D: drive), while my OS and apps are on the C: drive. I also have a networked Network Attached Storage (NA

  • Cascade LOV in Apex 4.0

    Hello Apex Fun how can i make cascade list of value in Apex 4.0 ? i tried cascade which enabled in list of item properties but contain problems , please help me also when use that cascade the Arabic characters shown unclear .. Edited by: Moh Loay on

  • New iPod not recognized in Vista PC and no devices in iTunes

    Hello, plugged iPod Touch into computer and Vista showed usual little box which said automatically located drivers and installed them. But couldn't find iPod in My computer. Installed iTunes from download area. No devices in left column. Reinstalled

  • Can I use a 3g dongle with macbook air 11?

    Can I use a 3g dongle with a macbook air 11 (in Europe)?

  • Using LDAP group to autenticate users from inside network to Internet

    Hi team, I got an asa 5510 version 7.2.3 and i need to autenticate my users from inside network to internet using a security group in the Active Directory, anyone can help me with these?