Enq: HW - contention

hi
in my spreport i am getting this enq problem pls tell me how to solve this.
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time
buffer busy waits 1,480,241 1,024,132 692 64.5
enq: HW - contention 142,929 389,756 2727 24.5
free buffer waits 5,245,113 99,454 19 6.3
enq: US - contention 12,172 19,131 1572 1.2
db file parallel write 5,228 10,397 1989 .7
log_buffer=25m
checkpointtimeout=0
checkpointinterval=0
thanks.

Total System Global Area 599785472 bytes
Fixed Size 1980328 bytes
Variable Size 146802776 bytes
Database Buffers 423624704 bytes
Redo Buffers 27377664 bytes
using 10gr2
simultaniously 150 user will affect the database.In this database we have create 150 tables.the procedure is.after creating this table using afterinsertion procedure to insert the data in table.We were using 150 procedure to insert 150 tables.
declare
counter NUMBER;
sql_string VARCHAR2(2000);
BEGIN FOR counter IN 1..150 LOOP
sql_string := 'CREATE TABLE emp'||counter||'
(id varchar2(10) primary key,
col_a varchar2(10),
col_b date,
col_c varchar2(10),
col_d varchar2(10),
col_e varchar2(10),
col_f varchar2(10),
col_g varchar2(10),
col_h date,
col_i varchar2(10),
col_j varchar2(10),
col_k date,
col_l varchar2(10),
col_m varchar2(10),
col_n varchar2(10),
col_o varchar2(10),
col_p varchar2(10),
col_q date,
col_r varchar2(10),
col_s varchar2(10),
col_t varchar2(10),
col_u varchar2(10),
col_v char(20),
col_w varchar2(10),
col_x date,
col_y varchar2(10),
col_z varchar2(10),
col_aa varchar2(10),
col_bb varchar2(10),
col_cc char(20),
col_dd varchar2(10),
col_ee date,
col_ff varchar2(10),
col_gg varchar2(10),
col_hh varchar2(10),
col_ii varchar2(10),
col_jj char(10),
col_kk varchar2(10),
col_ll date,
col_mm varchar2(10),
col_nn varchar2(10),
col_oo varchar2(10),
col_pp varchar2(10),
col_qq char(10),
col_rr varchar2(10),
col_ss date,
col_tt varchar2(10),
col_uu varchar2(10),
col_vv varchar2(10),
col_ww varchar2(10),
col_xx char(12)
) TABLESPACE employee
PCTFREE 10
INITRANS 10
MAXTRANS 255
STORAGE
INITIAL 50m
next 50M
MAXEXTENTS UNLIMITED
EXECUTE IMMEDIATE sql_string;
END LOOP;
END;
CREATE OR REPLACE procedure afterinsertion1(n in number)
is
a number;
cc number;
BEGIN
cc:=1;
FOR innercounter IN 1 .. n LOOP
INSERT INTO emp1(id, col_a ,col_b,col_c ,col_d ,col_e, col_f ,col_g ,col_h ,col_i ,col_j ,col_k,col_l,col_m,col_n,col_o,col_p,
col_q,col_r,col_s,col_t,col_u,col_v,col_w,col_x,col_y,col_z,col_aa,col_bb,col_cc,col_dd,col_ee,col_ff,col_gg,
col_hh,col_ii,col_jj,col_kk,col_ll,col_mm,col_nn,col_oo,col_pp,col_qq,col_rr,col_ss,col_tt,col_uu,col_vv,col_ww,
col_xx) VALUES (id.nextval,'col_a','11-JAN-07','col_c','col_d','col_e','col_f','col_g','11-JAN-07' ,'col_i' ,'col_j',
'11-JAN-07','col_l','col_m','col_n','col_o','col_p','11-JAN-07','col_r','col_s','col_t','col_u','col_v','col_w',
'11-JAN-07','col_y','col_z','col_aaa','COL_BB','col_cc','col_dd','11-JAN-07','col_ff','col_gg','col_h','col_ii','col_jj',
'col_kk','11-JAN-07','col_mm','col_nn','col_o','col_pp','col_qq','col_rr','11-JAN-07','col_tt','col_uu',
'col_v','col_ww','col_xx');
cc:=cc+1;
if cc > 3 then
     commit;
     cc:=0;
end if;
END LOOP;
END;
/

Similar Messages

  • Wait event enq: JD - contention

    Hi All,
    In the top-5 wait events of the AWR-report i encounter a enq: JD contention wait event (wait class Other).
    I only figured out that JD means Job Queue Date.
    Can anybody tell me more about this wait event?
    Thanks in advance,
    Jeroen van Schaijk

    Hi All,
    I have additional information:
    This wait event synchronizes dates between job queue coordinator and slave processes.
    It appears that this wait event takes more than 10% of the total wait time!
    Does anybody know how to deal with this wait event?
    Thanks in advance,
    Jeroen van Schaijk

  • Enq: MN - contention with log miner

    One of our customers is hitting enq: MN - contention wait event.
    UKJA@ukja102> exec print_table('select * from v$lock_type where type = ''MN'');
    TYPE                          : MN
    NAME                          : LogMiner
    ID1_TAG                       : session ID
    ID2_TAG                       : 0
    IS_USER                       : NO
    DESCRIPTION                   : Synchronizes updates to the LogMiner dictionary
    and prevents multiple instances from preparing the same LogMiner session
    -----------------The situation is as following
    - Batch job is generating massive redo
    - Frequent log file switching occurs during this job
    - Multiple sessions are mining archive logs due to some business requirement
    - From time to time, one session holds MN lock in excluisve mode and other sessions wait for the ML lock to be released.
    Holding session and waiting sessions are executing same SQL statement like following.
    SELECT SCN, SQL_REDO, SEG_OWNER, SEG_NAME, OPERATION_CODE, CSF,DATA_OBJ#,
    XIDUSN || '_' || XIDSLT || '_' || XIDSQN) AS XID, ROW_ID, ROLLBACK, TIMESTAMP FROM V$LOGMNR_CONTENTS
    WHERE (OPERATION_CODE IN (7, 36)
    OR ( ( ROLLBACK = 0 OR (ROLLBACK = 1 AND CSF = 0) ) AND ( OPERATION_CODE IN (1, 2, 3)
    AND ((SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE1')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE2')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE3')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE4')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE5')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE6')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE7')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE8')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE9')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE10')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE'11)
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE12')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE13')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE14')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE15')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE16')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE17')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE18')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE19')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE20')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE21')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE22')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE23')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE24')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE25')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE26')
    OR (SEG_OWNER = 'TEST1' AND TABLE_NAME = 'TABLE27')))))But my experiments show that normal log miner operations do not need MN lock thus no MN lock contention is reproduceable. Same under the situation of very frequent log file switching.
    Does anyone have experience and/or information on this lock?
    ================================
    Dion Cho - Oracle Performance Storyteller
    http://dioncho.wordpress.com (english)
    http://ukja.tistory.com (korean)
    ================================

    My first test case was flawed, so posted wrong info. :(
    Further investigation shows that at certain steps of typical log miner operations need MN lock in exclusive mode. For example, dbms_logmnr.start_logmnr procedure needs exclusive MN lock.
    Excerpt from 10704 event trace file.
    *** 2009-05-19 13:57:53.812
    ksqgtl *** MN-00000000-00000000 mode=6 flags=0x21 timeout=600 ***
    ksqgtl: no transaction
    ksqgtl: use existing ksusetxn DID
    ksqgtl:
         ksqlkdid: 0001-0016-00000014
    *** 2009-05-19 13:57:53.828
    *** ksudidTrace: ksqgtl
         ksusesdi:   0000-0000-00000000
         ksusetxn:   0001-0016-00000014
    ksqgtl: RETURNS 0
    *** 2009-05-19 13:57:53.828
    ksqrcl: MN,0,0
    ksqrcl: returns 0Starting log mining operation would require modification on log miner dictionary.
    This means that multiple sessions can't start log mining concurrently, but once they've started successfully other types of jobs can be done concurrently.
    Any operation that should access the log miner dictionary would require MN lock. I would contact the customer who reported this problem and let them have more investigation.
    ================================
    Dion Cho - Oracle Performance Storyteller
    http://dioncho.wordpress.com (english)
    http://ukja.tistory.com (korean)
    ================================

  • Enq:TT - contention

    10.2.0.2
    There arethousands of holding sessions session due to enq:TT - contention
    These sessions are running
    simple insert like
    insert into TBL_LOG where a=:1, b=:2 and c=:3
    enq:TT - contention
    enq:HW - contention
    google suggests to add freelist and apply latest patch.
    cpu usage is also 100%.
    what could be root cause of this?
    How to troubleshoot this.
    I believe killing these top cpu consumers is a good fix.
    Awr showing these event heavily
    addm say to tune this sql.
    I suspect its issue of parallel query execution
    or commit in these inserts.
    Any hint / doc / link would be higly-2 apprecialted.

    Metalink doc id 419348.1 may help you

  • What´s event "enq: FU - Contention"

    what is the meaning of the following waiting event "enq: FU - Contention"

    http://www.lmgtfy.com/?q=oracle+enq+FU+Contention

  • Enq TM Contention vs Poor index performance

    I have the following issue: I have a lot of Enq TM contention in my database. I then index the relevant tables/columns. This gets rid of the Enq TM issues, but performance is degraded even more due to the massive index reads. We have a good high performance disk system, so that's not the problem.
    Has anyone had a similar issue? Aside from testing 101 different possibilities, does anyone have a recommendation on resolving this?
    TIA,
    Mike

    user12201192 wrote:
    I have the following issue: I have a lot of Enq TM contention in my database. I then index the relevant tables/columns. This gets rid of the Enq TM issues, but performance is degraded even more due to the massive index reads. We have a good high performance disk system, so that's not the problem.
    Has anyone had a similar issue? Aside from testing 101 different possibilities, does anyone have a recommendation on resolving this?
    you have a mystery; while we have no clues.
    post results from following SQL
    SELECT * FROM V$VERSION
    HOW To Make TUNING request
    SQL and PL/SQL FAQ

  • Enq: ST - contention wait event

    Hi,
    At one of our production database I am getting enq: ST - contention wait event at the Top 5 Timed Event section of the AWR report. I have checked with Metalink (Doc ID:974863.1), where I have been suggested to migrate to LMT. But all the tablespaces at the database are in LMT. It would be really very helpful if someone can explain the occurance of such wait event and the way this can be eliminated in future.
    Environment:
    Database Version: 10.2.0.3
    OS: Solaris 10
    Thanks for your valuable time.
    Regards,
    Joy

    I suggest reviewing the following document:
    http://www.perfvision.com/papers/09_enqueues.ppt
    Specifically, look at slide 61 and its notes section.
    Take a look at the output of the following SQL statement:
    SELECT
      SUBSTR(TABLESPACE_NAME,1,20) NAME,
      EXTENT_MANAGEMENT,
      ALLOCATION_TYPE,
      INITIAL_EXTENT,
      NEXT_EXTENT
    FROM
      DBA_TABLESPACES
    ORDER BY
      EXTENT_MANAGEMENT;Is everything listed as LOCAL? For those tablespaces with a UNIFORM ALLOCATION_TYPE, what is the value of INITIAL_EXTENT?
    Charles Hooper
    Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
    http://hoopercharles.wordpress.com/
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Enq: PS – contention wait event

    Hi Guys,
    I am running Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production on RHEL5.
    I changed my db parameter PARALLEL_MAX_SERVERS from 10 to 20. Now, most of my queries are hanging due to this enq: PS – contention wait event. I looked at the req_dgree from the V$PX_SESSION and it is too high.
    I reduced the PARALLEL_MAX_SERVERS back to 10 and still the queries are still hanging and the req_dgree still too high.
    How can I fix this situation?
    Thanks in advance....

    user11979518 wrote:
    Hi Guys,
    I am running Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production on RHEL5.
    I changed my db parameter PARALLEL_MAX_SERVERS from 10 to 20. Now, most of my queries are hanging due to this enq: PS – contention wait event. I looked at the req_dgree from the V$PX_SESSION and it is too high.
    I reduced the PARALLEL_MAX_SERVERS back to 10 and still the queries are still hanging and the req_dgree still too high.
    How can I fix this situation?do use PARALLEL.
    PARALLEL sometimes make SQL slower;.
    PARALLEL is NOT magic solution to all/every performance problem.
    more is not always better; as you have now learned.
    How many cores/CPU exist in this DB Server system?

  • Enq: HW - contention on RAC

    Hi,
    Using multiple insert sessions on same table we are having Wait event "enq: HW - contention". Tablespaces is local and assm is used.
    version 10.2.0.4.0
    Two node RAC.
    Any suggestion to reduce? Thinking to allocate more freelists and freelistgroups manually to segment.
    Segment is a partition in this case.
    Regards
    Edited by: user13512691 on Nov 14, 2011 10:25 PM

    If so, using a larger uniform extent size should reduce the space management overhead.
    Another alternative might be to preallocate extents. Thats correct, solution should be to preallocate extents, because others session are waiting on eng HW contention, as this means first insert statement is allocating new extents. which means other session will wait untill this process completes. I believe allocating new extents are expensive operations which could affect the performance.
    BTW - Manually adding Freelists on objects( objects are placed in assm tablespace) would benefit?
    or other options is to alter MINEXTENT,MAXEXTENT,NEXTENT.
    Is that correct?

  • Problem with enq:SQ contention

    here the problem is more contention with as i shown belo
    enq: SQ - contention 168,888 234,204 1387 30.4
    can u help on this

    Hi Mohamed,
    I've seen SQ enquque waits in busy databases with a large number of competing transactions are inserting rows. Also, look for related buffer busy waits, indicating a freelist shortage.
    You can easily cache as sequence with the "add/alter sequence xxx cache" command. The "cache" clause caches the specified number of sequence values into the buffers in the SGA. This speeds access, but all cached numbers are lost when the database is shut down. The default value is 20; maximum value is maxvalue-minvalue.
    If there are performance problems due to sequence cache waits, examine the row cache locks statistics in the v$system_eventview to determine whether the problem is due to the use of Oracle sequences.
    If this is a RAC database, you should use the NOORDER keyword to avoid an additional cause of SQ enqueue contention that is forced ordering of queued sequence values.
    Here are my notes:
    http://www.dba-oracle.com/t_sequence_caching.htm
    Hope this helps . . .
    Donald K. Burleson
    Oracle Press author

  • Enq tc -contention

    Hello,
    I just started analysing our database i found a wait event in EM graph(other). when i dig into the other wait event i encounter a wait event (enq tc -contention). i have tried to find solution on net. but i did not find it on Google or even in matalink. it take considerable time for example if insert statement taking 2mint to complete it execution one mint is spending on this wait event. kindly help me out how to go away this event
    Oracle 11 r2
    windoows server 2003
    Redo and Control Files are On SSD
    Rest of all Files are on SAN.
    Edited by: Oracle Studnet on May 26, 2011 2:51 AM

    Thanks but he discussed TX contention but i have encounter with TC contention? could you plz provide my any ML note where i can find out the root cause of this Problem. This wait event taking 80% database time. i found top foreground wait in AWR. Simple insert or merge statement are causing enq TC contention. it might be possible instance memory configuration would be incorrect. i have observed some issue in AWR
    Instance Efficiency Percentages (Target 100%)
    Buffer Nowait %: 100.00 Redo NoWait %: 100.00
    Buffer Hit %: 100.00 In-memory Sort %: 100.00
    Library Hit %: 98.73 Soft Parse %: 98.32
    Execute to Parse %: 47.27 Latch Hit %: 100.00
    Parse CPU to Parse Elapsd %: 48.23 % Non-Parse CPU: 99.6 Let check my Memory Statistic
    Host Mem (MB): 32,757.8 32,757.8
    SGA use (MB): 15,680.0 15,680.0 ()
    PGA use (MB): 515.2 508.2  why PGA used so small memory? (automatic memory is enable memory_target 25GB)
    % Host Mem used for SGA+PGA: 49.44 49.42 i have changed some default setting due to large sort operation. check out parameters that i have changed
    ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE;
    alter system set db_files = 10000 scope = spfile;
    alter system set processes = 500 scope = spfile;
    alter system set memory_max_target = 25000M scope=spfile;
    alter system set memory_target = 25000M scope = spfile;
    alter system set  workarea_size_policy = manual  scope=SPFILE;
    alter system set sort_area_size = 204800000 scope=SPFILE;
    alter system set hash_area_size = 409600000 scope=SPFILE;
    alter system set "_pga_max_size"=2000000000  scope=SPFILE;
    alter system set "_smm_max_size"=1073741824  scope=SPFILE;
    ALTER SYSTEM SET large_pool_size = 1073741824 SCOPE=SPFILE;But my instance taking 15GB which is the default sga_max_size memory would i need to increase it? if i set it 20GB then i mean SGA will use 20GB what about PGA. there are large sorting operations like join table are perform night loading (batch job).
    why PGA is taking less memory with these settings?
    Top 5 Timed Foreground Events
    Event Waits Time(s) Avg wait (ms) % DB time Wait Class
    enq: TC - contention 3 3,161 1053811 79.56 Other
    DB CPU   528   13.28  
    db file sequential read 73,709 125 2 3.14 User I/O
    enq: CF - contention 4 106 26540 2.67 Other
    log file sync 391 57 145 1.43 Commit

  • Enq Us contention

    Hi ,
    I am getting Enq Us contention as top wait event continuosly in one of my RAC database. and 2nd top wait event is DFS file handel.
    Could any body expalin me this wait event and solution to minimize this wait event.
    My db size 70GB
    Undo tablespace is 1.5GB with autoextend on
    undo retion =900
    SGA_ATRGET =2.5GB

    Have a read through this thread:
    Re: Slowing down enqueue procedure...."Sometimes"
    It helped someone with a similar issue to yours.

  • I see 'enq: JI - contention' when building multiple cubes/partitions

    Version 11.2.0.3
    I can successfully build multiple partitions of a cube simultaneously by supplying the degree of parallelism that I want. I can also build multiple cubes and multiple partitions of multiple cubes by submitting separate jobs (one per cube) with parallelism set in the job (for number of partitions per job/cube).
    My goal was to refresh 2 cubes simultaneously, 2 partitions in parallel each, so that 4 partitions total were refreshing simultaneously. There were sufficient hardware resources (memory and processes) to do this. I tried to submit 2 jobs, one for each cube, with parallel 2 on each.
    What happens is that 3 partitions start loading, not 4. The smaller of the 2 cubes loads 2 partitions at a time, but the larger of the cubes starts loading only 1 partition and the other partition process waits with JI - contention.
    I understand that JI contention is related one materialized view refresh blocking another refresh of the same MV. Yet simultaneous refresh of different partitions is supported for cube MVs.
    Because I see the large cube having the problem but not the smaller one, I wonder if adding more hash partitions to the AW$ (analytic workspace) table would allow more concurrent update processes. We have a high enough setting for processes and job_queue_processes, and enough available threads, etc.
    Will more hash subpartitions on the AW$ table allow for more concurrency for cube refreshes?

    It looks like the JI contention was coming from having multiple jobs submitted to update the SAME cube (albeit different partitions). Multiple jobs for different cubes (up to one job/cube each) seems to avoid this issue. I thought there was only one job per cube, but that was not true.
    Still, if someone has some insight into creating more AW hash subpartitions, I'd like to hear it. I know how to do it, but I am not sure what the impact will be on load or solve times. I have read a few sources online indicating that it is a good idea to have as many subpartitions as logical cube partitions, and that it is a good idea to set the subpartition number to a power of two to ensure good balance.

  • Enq: TX - row lock contention in Select without for update

    We have deployed a new Version of our Software on the test-system of our customer.
    While the software runs fine on our Systems (Oracle EE 10.2.0.4 as well as Oracle EE 11.2.0.2 on EL 5.4 x86_64) it runs sluggish on our Customer's system (Oracle EE 10.2.0.4 on Solaris 10 x64).
    During analysis of the problem I came across this:
    SQL ID:  Plan Hash: 3934983510
    SELECT ts.message_id_t235
      FROM t235_time_series ts,
           t238_timeseries_reported tsr
    WHERE ts.time_series_id_t235 = tsr.timeseries_id_t238
       AND tsr.message_id_t238 = :b2
       AND ts.current_state_t235 = :b1
       AND ROWNUM = 1
    call     count       cpu    elapsed       disk      query    current        rows
    ======= ======  ======== ========== ========== ========== ==========  ==========
    Parse        0      0.00       0.00          0          0          0           0
    Execute      8      0.01     *137.55*          0          8          5           0
    Fetch        8      0.00       0.00          0         60          0           8
    ======= ======  ======== ========== ========== ========== ==========  ==========
    total       16      0.01     137.55          0         68          5           8
    Misses in library cache during parse: 0
    Optimizer mode: CHOOSE
    Parsing user id: 90     (recursive depth: 1)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ========================================   Waited  ==========  ============
      *enq:* *TX* *=* *row* *lock* *contention*                 281        0.64        *137.01*
    ********************************************************************************As you can see the statement is very primitive. The Tables used are very huge (100M+ Rows) but have no bitmap indexes. How can this statement wait on enq: TX = row lock contention?
    Thanks in advance!
    Best regards,
    Sven
    Edited by: user12182396 on Feb 4, 2011 5:43 AM
    Edited by: user12182396 on Feb 4, 2011 6:02 AM

    user12182396 wrote:
    We have deployed a new Version of our Software on the test-system of our customer.
    While the software runs fine on our Systems (Oracle EE 10.2.0.4 as well as Oracle EE 11.2.0.2 on EL 5.4 x86_64) it runs sluggish on our Customer's system (Oracle EE 10.2.0.4 on Solaris 10 x64).
    During analysis of the problem I came across this:
    SQL ID:  Plan Hash: 3934983510
    SELECT ts.message_id_t235
    FROM t235_time_series ts,
    t238_timeseries_reported tsr
    WHERE ts.time_series_id_t235 = tsr.timeseries_id_t238
    AND tsr.message_id_t238 = :b2
    AND ts.current_state_t235 = :b1
    AND ROWNUM = 1
    call     count       cpu    elapsed       disk      query    current        rows
    ======= ======  ======== ========== ========== ========== ==========  ==========
    Parse        0      0.00       0.00          0          0          0           0
    Execute      8      0.01     *137.55*          0          8          5           0
    Fetch        8      0.00       0.00          0         60          0           8
    ======= ======  ======== ========== ========== ========== ==========  ==========
    total       16      0.01     137.55          0         68          5           8
    Misses in library cache during parse: 0
    Optimizer mode: CHOOSE
    Parsing user id: 90     (recursive depth: 1)
    Elapsed times include waiting on following events:
    Event waited on                             Times   Max. Wait  Total Waited
    ========================================   Waited  ==========  ============
    *enq:* *TX* *=* *row* *lock* *contention*                 281        0.64        *137.01*
    ******************************************************************************** As you can see the statement is very primitive. The Tables used are very huge (100M+ Rows) but have no bitmap indexes. How can this statement wait on enq: TX = row lock contention?
    Are either of these tables subject to distributed transactions through database links ? If so then it is possible for a select statement to wait on a TX enqueue in mode 4 if it's trying to read a block which is subject to change by another tranaction that is stuck between the PREPARE and COMMIT phases of a "2 phase commit".
    However, I have to say that don't know whether this would show up as: "enq: TX - row lock contention" or "enq: TX - contention". If you monitor the system for a while - checking v$lock for lock types TX, or query v$active_session_history (if you're licensed to use it) you may be able to check the lock mode.
    If this is the problem then it's generally indicative of a networking problem of some sort - possibly simple congestion because of excess traffic.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    To post code, statspack/AWR report, execution plans or trace files, START and END the text with the tag {noformat}{noformat} (the word "code" in lowercase, curly brackets, no spaces) so that the text appears in fixed format.
    There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Enq wait events

    hi,
    Please could someone point me to some doc explaining enq events like:
    enq: AT - contention and how to interpret the name|mode parameter for such events (select event#,name,parameter1 p1, parameter2 p2, parameter3 p3 from v$event_name where name='enq: AT - contention')
    Thanks for ur time,
    RUben

    In addition,
    UKJA@ukja102> @lock_type at
    UKJA@ukja102> set serveroutput on
    UKJA@ukja102>
    UKJA@ukja102> exec print_table('select * from v$lock_type where type = upper(''&1'')');
    TYPE                          : AT
    NAME                          : Alter Tablespace
    ID1_TAG                       : 0
    ID2_TAG                       : 0
    IS_USER                       : NO
    DESCRIPTION                   : Serializes 'alter tablespace' operations
    -----------------Dion Cho

Maybe you are looking for

  • Windows 7 64-bit drivers for HP ScanJet 6200c

    Hello HP, Will you be releasing 64-bit drivers for the ScanJet 6200c?  Regards, Dean.

  • Internet access in Ballyforan

    well Eircom alan..try this...I am stuck out in Leitrim beside Keshcarrigan and have limited or No connectivity. I have only got the line in 3 weeks and get readings of less than 1mb constantly on my speed. Eircom told me I was guanteed at least 60% o

  • Using BATCH-EXPORT on subclips vs MM to create independent media files

    I've been capturing full HDV tapes with the DV Start/Stop Detection turned on and everything has worked just fine - until now. I'm now encountering a problem w FCP "Searching for Media" on roughly 25% of my clips DURING capture, and in the process, l

  • Why can I not print from text editor?

    I am new to the mac & was trying to do up a text document.  I went to text editor thinking that would work. I did it up all nice & can not print it. I just goes all funny. I know it is not my printer; can print other things fine. Can you please help?

  • JNDI LookUp does not work in WSAD5.0

    Hi, I have an independent java class which creates Data Source in WASD 5.0, and this works fine to get data source when the server is 4.0, but does not work for server 5.0, here is the code: public static void main(String[] args) throws NamingExcepti