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
-
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 PMsb92075 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
%' -
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 AMThanks 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 -
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 ?
VinitaDear 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 -
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,
ShankarHi,
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/ -
Hello,
could any one has good stuff to monitor and diagnose lock and latch contention in databasedbcontrol 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 -
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 Graaf1) 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. ThanksAssuming 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?