ENQ: TX - line lock conflict

Hello

We have enq: TX - conflict in line with update sql .a lock single session blocks the rest for a long period of time

Here's the sql code

' Client UPDATE SET CUST_NUM = CUST_NUM +: B2 WHERE TABLE_NAME =: B1 '

could you tell me, how do I solve this problem

Thank you

Try to use the DBA_BLOCKERS view to retrieve the blocking database session. As already said must COMMIT to this session blocking or ROLLBACK. In some cases, it may be necessary to kill the blocking of the database session, but you need to know the risk.

Tags: Database

Similar Questions

How to find resulting sql ' enq: TX - line lock conflict.
Hello

In one of our database we still find "enq: TX - line lock conflict" for 2-3 days. But then he stopped. Time it happened he blocked other sessions for a long while and he got is resolved automatically. Now the ADDM report, we have sql queries that has waited for this but, we cannot find that question of what module caused the outcome. What I should look for that, beyond the information. Help, please.

Database is 10 gr 2 on AIX.

Kind regards
Chaouki
Hello
Have you tried querying DBA_HIST_ACTIVE_SESS_HISTORY with event WHERE as "enq: TX %' ?" This should return the lines for the duration of that event (hold/lock) was underway. See column BLOCKING_SESSION which will tell you the session ID that blocked and caused this wait event/lock.

Now again ask DBA_HIST_ACTIVE_SESS_HISTORY with session_id = .

Here, you should see SQLs executed by this session "blocking". Take this list of SQLs and use v$ sql or AWR report using the awrsqrpt.sql script to see the details of each of these SQLs and this should help you find SQL blocking. DBA_HIST_ACTIVE_SESS_HISTORY also shows the module where this session/sql has been executed.

Salman

[ORACLE 10.2.0.5] performance problem with high enq: TX - line lock contention waiting

Hello
I have a performance problem involving high line response to locking conflicts that I can't wait.
The application updates the specific table about 1200 times for my AWR report representing 2 hours.
This update represents 98% of the db_time and wait to enq: TX - line lock conflict is:
-83 796 waiting
-245 441 seconds
The application updates a row both an unprecedented SELECT UPDATES. This is the query:
Update my_table set creationtime =: 1, modificationdate =: version 2, =: creationuserid 3, =: fortesting 4, =: 5, modificationuserid =: participation_uuid 6, =: actimenucontact 7, =: allegroid 8, =: campaign_uuid 9, =: desjardinsemployeetype 10, =: effectiveparticipationtype 11, =: family_uuid 12, =: fetchpasseport 13, =: 14, healthratingfilldate =: hoursofsleeptimecommitment 15, =: igaid 16, =: initialsubscriptiontype 17, =: minutesofsleeptimecommitment 18, =: goal 19, =: partner_uuid 20, =: 21, promotionalemails =: 22, readrules =: sccsubscriptionprovenance 23, =: = subscriptionprovenance 24,: 25, supportemails =: where the 26 uuid = : 27 and = version: 28
Clause where is filtering on uuid which is the primary key of my_table.
The uuid is a specific user and two users would not update the same row, what could be the reason for this wait event?
Thank you

Why guess when you know.

Watch ASH data for these events to the queue.

He'll tell you sql id as well.

Line lock

Hi all
EBS R12.2.4
11 GR 2
OL6.5
Users know the line locking problems today?
I check the blocking session, and I found this:
12 February 2016 15:09:09 [email protected] user (SID = 17) with the statement: SELECT COUNT (*) FROM AP_INVOICE_LINES_ALL WHERE INVOICE_ID =: b1 AND ROWNUM = 1
If it blocks the SQL statement
[email protected] (SID = 220) SQL blocked-> UPDATE AP_PAYMENT_SCHEDULES SET AMOUNT_REMAINING is AMOUNT_REMAINING - AP_UTILITIES_PKG. AP_ROUND_CURRENCY (: B7,: B6), PAYMENT_STATUS_FLAG = DECODE (AMOUNT_REMAINING - AP_UTILITIES_PKG. AP_ROUND_CURRENCY (: B7,: B6), 0, "Y", ((GROSS_AMOUNT /: B5) * (: B5 - NVL (AP_INVOICES_PKG.)) GET_AMOUNT_WITHHELD(:B2), 0))), 'N', 'P'), = LAST_UPDATE_DATE = SYSDATE, LAST_UPDATED_BY: B4, LAST_UPDATE_LOGIN =: B3 WHERE INVOICE_ID =: = PAYMENT_NUM AND B2: B1
Why is a count of the sql blocks?
Kind regards
JC

Hi JC,.

Please check below post.

Who is blocking other users. Oracle on cloud

Jonathan

Width of line lock?

I just got adobe ink & Slide and started to use it with the application Adobe Illustrator drawing. I wonder if it is possible to lock the width of the line: you chose, instead of having the stroke vary with your pen/stylus pressure? Please let me know if you have something!
Thank you!

Hi Francisco,.

You use the most recent version (3.3) of the draw? In this version, there is a menu of settings of the brush. To access he tap any of the brushes in the Toolbox; It's at the bottom of the menu color.

I would like to know if that's what you're looking for.

Sue.

Line lock error

Hello
We get the following error when the API call.
Api Hr_Assignment_Api.Update_Emp_Asg
-Step8.2 - Ora-20001: the current
Line is locked Cause: you are
Attempt to lock A row the
Table of Per_All_Assignments_F which is
Currently locked by another
User. Action: Re-interview and
Try to block new line
Although the API works successfully.we receive an error message.
Please can you advice why we get the above error.
Kind regards
Jean Michel.

Hi Patrice,

The simple error message said, that someone else is also of/development help to update the same record that you are trying to update.

Please ensure that no other person accesses the same person of front-end (or same dorsal).

Thank you

Vignesh

Problem with the compatible version of line lock tables

I tested the effect of locking in the tables in activated version to assess restrictions workspace manager to update the records in different workspaces and I met a locking issue where I can't seem to update different registers of the same table in different sessions if these same records have already been updated and committed in a different workspace.
I run the tests on 11.2.0.3. I have ROW_LEVEL_LOCKING worth IT.
Here's a simple test case (I have many other test cases that are not as well, but understand why it is a problem of blocking will help me understand the results of others my test case):
-Alter tablespace names in accordance with the requirements
create table t1 (id varchar2 (36) not null, name varchar2 (50) not null) tablespace XXX;
ALTER table t1 add the key primary t1_pk (id) of constraint using index tablespace XXX;
exec ('LIVE') dbms_wm.gotoworkspace;
insert into t1 values ('1 ', 'name1');
insert into t1 values ('2 ', 'name2');
insert into t1 values ('3 ', 'name3');
commit;
exec dbms_wm.enableversioning ('t1');
exec ('LIVE') dbms_wm.gotoworkspace;
exec dbms_wm.createworkspace ('TESTWSM1');
exec dbms_wm.gotoworkspace ('TESTWSM1');
-Update 2 files in a workspace not LIVING for the update later in different workspaces
Update t1 set name = name | ' changed ' where id in ('1 ', ' 2');
commit;
quit smoking;
-Now in a separate session (called session 1 for this example), run the following without commit the changes:
exec ('LIVE') dbms_wm.gotoworkspace;
Update t1 set name = 'modified' where id = '1';
-Now in another session (session 2) update a different record in the same table. The update below is blocked waiting on the transaction in the session 1 to perform (by commit / rollback):
exec ('LIVE') dbms_wm.gotoworkspace;
Update t1 set name = 'modified' where id = '2';
I am surprised, recordings of the different IDS cannot be updated in different sessions which is why is session 1 blocking the update of the 2 folder that is not being updated anywhere else. I tried this using different workspaces not LIVING with similar results. I tried to change the properties of the table for example, initrans with and always get a lock. Changes made to the properties of the table are correctly propagated to _LT tables but not all tables in handler related workspace created for table T1 that precedes. I don't know if that's the problem.
Note an example of the query Manager space background likely to create the lock is something like:
UPDATE TESTWSM. T1_LT SET LTLOCK = WMSYS.LT_CTX_PKG. CHECKNGETLOCK (: B6, LTLOCK, NEXTVER,: B3, 0, 'UPDATE', VERSION, DELSTATUS,: B5), NEXTVER = WMSYS.LT_CTX_PKG. GETNEXTVER (NEXTVER,: B4, VERSION,: B3: B2, 683) WHERE ROWID =: B1
Any help with this will be appreciated. Thanks in advance.

Hello

The reason for the block is actually the same as above. The splits is registered at the level of the version/savepoint, not necessarily just the workspace. In your example, workspaces TESTWSM1 and TESTWSM2 have a single version and the LIVE workspace has 3 versions. A new version is always implicitly created during a CreateWorkspace operation if the most RECENT/current version has modified data. The lines for the id = "1" and id = "2" are changed in each workspace to the child and before creating a workspace. However, since the id = "3" LIVE online has changed after the creation of TESTWSM1, it is in a different version of those other 2 rows. So when the updates for the id = "1" and id = "2" are executed, the line is attempted to be divided between TESTWSM1, TESTWSM2 and the latest version of LIVE. No other line has been updated with this combination so we try to introduce a set of lines in the metadata table. As this happens multiple sessions at the same time, one of them is obliged to block until the other transaction issues a commit or rollback.

It is not a way to avoid these LMD. The lock is acquired in this case is a short-lived transaction lock and they are required for the correct rows be returned for a particular workspace.

Kind regards

Ben

The implementation of the exclusive line locking in Oracle
Hi all

Since the beginning of learning Oracle, I've known that oracle has no row-level lock. Row level locking is achieved by ITL in the header of the block.
In this context, I am curious how statement "lock table in exclusive mode of line" is implemented? Update for all ITLs lines all the blocks belonging to the table?

Best regards
Leon
I'm not sure what you mean by Oracle has no blockage at the level of the lines. Line level Oracle most certainly is a lock. A single line in a table can be locked without blocking the other lines of the table, or even of other lines in the same block.

You are right that this works through the ITL. When a DML is run, if a session doesn't has not already open transaction, Oracle will create one, by booking a slot/segment/wrap in the rollback segment header. Then, in the block where the line should be blocked, an ITL slot is reserved in the block header, that contains this transaction id, essentially pointing to this location of rollback segment. Now, to lock a specific line in the directory of the line, there is a byte of the lock. The locking byte is either 0, which means that the row is not locked, or she will 1.n value, where n is the number of ITL sites reserved in the block header. Thus, if the locking byte is not null, it points to slot ITL of the transaction that holds the lock. So, you can see that it is very easy for a transaction lock a single line in a block, or all lines in the block. Simply set the byte corresponding to the ITL (s) appropriate locking.

This fact implies, it is that Oracle has no "centralized list of the locks on level line. Row-level locks are inherent in the structure of datablock, as stated above.

Hope the helps to clarify your understanding.

-Mark

line lock hiding

Hi all

DB version is 10.2.0.4

In the AWR 5 Albums waiting events report, I could see wait event "locking of cache line. Searched in google and got the below

SQL> select p1text,p1,p2text,p2,p3text,p3 from v$session where event = 'row cache lock';

P1TEXT                       P1 P2TEXT                       P2 P3TEXT                                                                   P3
-------------------- ---------- -------------------- ---------- ---------------------------------------------------------------- ----------
cache id                     16 mode                          0 request                                                                   3

1 row selected.

SQL> select PARAMETER ,COUNT ,GETS ,GETMISSES ,MODIFICATIONS from v$rowcache where cache#=16;

PARAMETER                             COUNT       GETS  GETMISSES MODIFICATIONS
-------------------------------- ---------- ---------- ---------- -------------
dc_histogram_defs                      1704   47481213   11479508          5408
dc_histogram_data                       218    8211149    1277649             0
dc_histogram_data                        83    2668657     301607             0

3 rows selected.

SQL> SELECT parameter, sum(gets), sum(getmisses), 100*sum(gets - getmisses) / sum(gets) pct_succ_gets, sum(modifications) updates FROM V$ROWCACHE WHERE gets > 0 GROUP BY parameter;

PARAMETER                         SUM(GETS) SUM(GETMISSES) PCT_SUCC_GETS    UPDATES
-------------------------------- ---------- -------------- ------------- ----------
dc_constraints                         7468           4954    33.6636315       7468
dc_free_extents                         578            445    23.0103806        178
dc_tablespaces                     82731475          12753    99.9845851          0
dc_tablespace_quotas                  41635           2672    93.5823226        110
dc_awr_control                         1774            856    51.7474634         30
dc_object_grants                   16804751         315710    98.1213051          0
dc_histogram_data                  10893968        1582368    85.4748242          0
dc_rollback_segments                4721434            934    99.9802179        606
dc_sequences                         123169          46953    61.8792066     123169
dc_usernames                       12046759          82141    99.3181486          0
dc_segments                        43854408        3208602    92.6835131      32483
dc_objects                         19096430        2728645    85.7112298       6698
dc_database_links                    231247           1383    99.4019382          0
dc_histogram_defs                  47588238       11511573    75.8100458       5408
dc_table_scns                         77108          12028    84.4010998        128
dc_used_extents                          71             45    36.6197183         71
dc_users                          132473881          75854    99.9427404          0
outstanding_alerts                     8387           7779    7.24931442         29
dc_files                               2904           1072    63.0853994          0
dc_object_ids                     277958942        3175244    98.8576572        831
dc_global_oids                      1683020          46540    97.2347328          0
kqlsubheap_object                     77217           3211    95.8415893          0
dc_profiles                          150822           3056    97.9737704          0
global database name                     22              7    68.1818182          0

24 rows selected.

Source: http://surachartopun.com/2009/11/investigate-row-cache-lock.html

How can I solve this lock cache on dc_histogram_defs and dc_histogram_data line?

Baskar.l

Lines, locked in a table
DB Version: 10 g 2, 11G

Within a single session, for a table, is it possible to determine the number of rows locked in this table?
-See lock it related information

Select OS_USER_NAME os_user,
PROCESS os_pid,
ORACLE_USERNAME oracle_user,
l.SID oracle_id,
decode (TYPE,
"SIR', 'Media Recovery."
"RT", "redo the wire."
A ', 'username ',.
"TX", "Transaction."
"TM", "DML"
"UL", "PL/SQL User Lock."
"DX", "Xaction distributed."
"CF", "control file."
'IS', 'State of the Instance.
"FS", "file Set."
"EI", "Instance recovery."
"ST', 'disk space Operation."
"TS", "Temp Segment."
'IV', 'Library Cache Invalidation',
"LS', 'Start or Switch Journal."
"RW", "rank waiting."
"SQ", "Sequence number",
"TE", "expand the table."
'TT', 'Table Temp', type) type of lock.
decode (LMODE,
0, 'none. '
1, "null."
2, "line-S (SS).
3, 'Row - X (SX).
4, "action."
5, row/s-X (SSX)',
Lock_held 6, 'exclusive', lmode);
decode (REQUEST,
0, 'none. '
1, "null."
2, "line-S (SS).
3, 'Row - X (SX).
4, "action."
5, row/s-X (SSX)',
Lock_requested 6, 'exclusive', ask).
decode (BLOCK,
0, "Do not block",
1, 'blocking',
State 2, 'global', block),
OWNER,
OBJECT_NAME
v $ locked_object lo,.
DBA_OBJECTS do,
v$ lock l
If lo. Object_id = do. OBJECT_ID
AND l.SID = OL. SESSION_ID;

Concerning
Asif Kabir

Failure to get the db line lock: ORA-01157

Hello

I have a client that uses that the customer is using Oracle Database 11 g Enterprise Edition Release 11.2.0.3.0 - 64 bit Production with the partitioning, Real Application Clusters, Automatic Storage Management. An application has been installed recently in which scripts created a .dbf file instead of save on the disk group. So if I run the query I see the following output below

SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
+RIAMSTG_DBF1/riamstg/datafile/oamstg_mds.259.821014833
+RIAMSTG_DBF1/riamstg/datafile/oamstg_ias_opss.256.821014833
+RIAMSTG_DBF1/riamstg/datafile/oamstg_oam.274.821014833
+RIAMSTG_DBF1/riamstg/datafile/oamstg_ias_iau.276.821014835
+RIAMSTG_DBF1/riamstg/datafile/bistg_mds.279.821875255
+RIAMSTG_DBF1/riamstg/datafile/bistg_biplatform.278.821875255
/db/oracle/112/db/dbhome_1/dbs/rbacx.dbf

Now, when we reboot the DB we see the error below.

ORA-01157: cannot identify/lock data file 18 - see DBWR trace file
ORA-01110: data file 18: '/db/oracle/112/db/dbhome_1/dbs/rbacx.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory

In my view, that the error may be related to the .dbf file. How can I move this ASM format?

-Extreme

It should be ALTER TABLESPACE OFFLINE RBACX without the single quotation mark character. (I had the character to reach the unknown tbsname).

Hemant K Collette

Compression of data and lock.

If some tables and indexes are compressed, they cause more locking during the DML activity? For example, blocking not to line level, but at the level of the blocks?
Also, RAC database can cause more locking given that global locks?
Thank you.

If some tables and indexes are compressed, they cause more locking during the DML activity? For example, blocking not to line level, but at the level of the blocks?

You are referring to the escalation of locks that occurs when many locks are maintained at a level of granularity (for example, lines) and a database trigger locks at a granularity (for example, block or table).

Oracle Database never degenerates locks. Escalation of locks greatly increases the likelihood of blocking. See: http://docs.oracle.com/cd/B28359_01/server.111/b28318/consist.htm#CIHCFHGE

Also, RAC database can cause more locking given that global locks?

No, the CARS will cause multiple locks of the application.

Of course, there are certain overload RAC because it is a more complex architecture (more than 1 cache buffers, inteconnect, etc.) and you can meet various "gc" wait-events (wait for the events of the cluster).

In RAC environment there is an extra cost for management of locking and interconnection, BUT the fact that you use CARS doesn't mean he will do more locks associated with the application (it will not create a line/table locks more).

For example, the fact that you are using RAC does not mean that you will encounter more wait-events 'enq - tx line lock conflict '.

Database locking issues
Dear all,

We had two node oracle RAC 10 g 2 of last 2-3 years. Now plans to add the third node. The node is added but increase that store the locking on a table of ID_USER_SESSION, in this user session information.
SELECT table_name, nom_tablespace, temporary from user_tables where table_name = 'ID_USER_SESSION ';

TABLE_NAME NOM_TABLESPACE T
------------------------------ ------------------------------ -
I HAVE D_USER_SESSION AFSYS_DATA_SPACE N

ID Planhash % activity % event SQL SQL text event

* 9y6v6907gzts2 4077075788 88.82 enq: TX - line lock contention 88.71 DELETE FROM ID_USER_SESSION WH... *.

bz1d91crtmmfp 2.41 enq: TX - line lock conflict 2.40 INSERT IN ID_USER_PROGRAM_DE...

can you guys please guide me how to solve this problem.

Thank you and best regards,
Shir khan
SHERKHAN wrote:

DELETE FROM ID_USER_SESSION WHERE (USER_SESS_ID =: = USER_SESS_SERIAL AND B2: B1) OR (USER_SESS_ID, USER_SESS_SERIAL) NOT IN (SELECT SID, SERIAL # FROM V$ SESSION);

(Sid, serial #) are only unique within the lifetime of a single instance. The same (sid, serial #) may exist simultaneously in all three of your RAC instances. Somehow, you need to change your table and the code to include the number of proceedings initiated by the session on.

Concerning
Jonathan Lewis

CREATE INDEXES online is waiting for the TX = 4 mode

Hello
I have a strange blocking problem where an INDEX CREATE LINE is waiting for a transaction that did only inserted a line in the parent table.
Wait is mode TX = 4 (not TM locks) and I currently have it reproduced only on 11.2.0.3 and 11.2.0.4
Easy to replicate the schema SCOTT:
Session 1:
SQL > set time on
14:54:58 SQL > insert into SCOTT. Dept (DEPTNO, dname) values (50, 'test');
1 line of creation.
Session 2;
14:55:24 SQL > create index test on SCOTT. EMP (ename) online;
It's waiting ' enq: TX - line lock conflict ":"
SQL > select sid, chain_signature from v$ wait_chains where blocker_is_valid = 'TRUE '.
SID CHAIN_SIGNATURE
---------- ----------------------------------------------------------------------
603 ' SQL * Net client message' < ='enq: TX - line lock conflict '
While waiting to acquire the lock of transaction in mode 4:
SQL > select * lock gv$ where sid = 603
INST_ID SELECT ADDR KADDR SID TYPE ID1 ID2 LMODE CTIME BLOCK REQUEST
---------- ---------------- ---------------- ---------- ---- ---------- ---------- ---------- ---------- ---------- ----------
1 00000006CDA05EB8 00000006CDA05F10 603 352577 0 4 0 348 2 AE
1 00000006CDA06078 00000006CDA060D0 603 DL 779505 0 3 0 308 2
1 00000006CD9FABE0 00000006CD9FAC38 603 DL 779505 0 3 0 308 2
1 00007F28001F5028 00007F28001F5088 603 779505 0 2 0 308 2 TM
1 00007F28001F5028 00007F28001F5088 603 779510 0 4 0 308 2 TM
1 00000006CD9FA240 00000006CD9FA298 603 779505 0 4 0 308 2 OD
1 00000006B4F26790 00000006B4F26808 589847 711499 6 0 308 2 TX 603
1 00000006CDA0ED68 00000006CDA0EDC0 655377 996169 0 4 308 TX 603 0
I've traced 10046 and 10704:
broadcast message = obj 29231196672 #= 779514 tim = 1447251053634045
ksqgtl * mode TX-000f001e-000ad97c = 4 flags = 0 x 10001 timeout = 21474836 *.
ksqgtl: xcb = 0x6bb322528, ktcdix = 2147483647, topxcb = 0x6bb322528
ktcipt (topxcb) = 0 x 0
ksucti: init logon has of txn DID:
ksqgtl:
ksqlkdid: 0001-003F-0000AFC4
ksudidTrace: ksqgtl
ktcmydid(): 0001-003F-0000AFC4
ksusesdi: 0001-003F-0000AFC3
ksusetxn: 0001-003F-0000AFC4
ksqcmi: TX, f001e, ad97c mode = 4 timeout = 21474836
2015-11-11 15:11:36.566
WAITING #140700792578680: nam ='enq: TX - line lock conflict ' ela 42932082 name = | mode = 1415053316 usn < < 16 | location = sequence 983070 = obj 711036 #= 779514 tim = 1447251096566283
And there is nothing in V$ SESSION leader/block/line current. class obj # is EMP. current sql_id is the CREATE INDEX.
If anyone has an idea on:
-Why creating an index in line must wait for transactions that modified only parent table
-How to continue the investigation
-can or cannot reproduce in other versions
Thanks in advance,
Franck.

I guess you have a constraint foreign key between emp and Dept.

It's expected behaviours: since 11.1 any DML at one end of a referential integrity constraint translates into a mode lock 3 taken at the other end, and your phenomenon resembles a side effect of this.

When you try to create the index online that your session must assume that the other session (holding mode 3 on the emp and dept) may have changed the emp and dept, so it must wait for the session to the commit or rollback.

(I guess that in principle, he could walk the cancellation of the transaction see if EMP had in fact been changed - but maybe who was considered too complicated to be worth the risk to implement)

Concerning

Jonathan Lewis

Updated - I just did a quick check to reproduce the effect on 11.1.0.7

For reference - here are a few notes on modes of locking and how the application has changed over time: https://jonathanlewis.wordpress.com/2010/06/21/locks/

Need help for analysis "plan and background events waiting" on the report statspack for oracle database 11.2.0.4 on AIX

HI: I analyze the STATSPACK report: this is the "volume test" on our UAT server for most of entry or "bind variables". Our shared pool is well used in oracle. Recovery of Oracle logs is not configured properly on this server, as in "Top 5 events of waiting", there are 2 for Oder.
I need to know what other information may be digging from of 'waiting in the foreground events' & ' background waiting events ", and which can help us better understand, in combination of ' Top 5 wait event, that how did the server test /? It could be overwhelming. wait events, so appreciate useful diagnostic or analyses. Database is oracle 11.2.0.4 updated from 11.2.0.3 on IBM AIX 64-bit, level 6.x system power

STATSPACK report

DB Id Instance Inst Num Startup Time Release RAC database

~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
700000XXX XXX 1 22 April 15 12:12 11.2.0.4.0 no.

Host name Platform CPU Cores Sockets (G) memory
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
dXXXX_XXX AIX-Based Systems (64-2 1 0 16.0)

Snapshot Id Snap Snap time Sessions Curs/Sess comment
~~~~~~~~    ---------- ------------------ -------- --------- ------------------
BEGIN Snap: 5635 22 April 15 13:00:02 114 4.6
End Snap: 5636 22 April 15 14:00:01 128 8.8
Elapsed time: 59.98 (mins) Av law Sess: 0.6
DB time: 35,98 (mins) DB CPU: 19,43 (mins)

Cache sizes Begin End
~~~~~~~~~~~       ---------- ----------
Cache buffer: block 2 064 M Std size: 8 K
Shared pool: 3 072 M Log Buffer: 13 632 K
Load profile per second per Transaction per Exec by call
~~~~~~~~~~~~      ------------------ ----------------- ----------- -----------
DB Time (s): 0.0 0.6 0.00 0.00
DB CPU: 0.0 0.3 0.00 0.00
Size: 458 720,6 8,755.7
Logical reads: 245,7 12 874,2
Block changes: 1 356.4 25.9
Physical reads: 6.6 0.1
Physical writings: 61.8 1.2
The user calls: 38.8 2 033,7
Analysis: 286,5 5.5
Hard analysis: 0.5 0.0
Treated W/A Mo: 1.7 0.0
Logons: 1.2 0.0
Runs: 801,1 15.3
Cancellations: 6.1 0.1
Operations: 52.4

Indicators of the instance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer % Nowait: 100.00 do NoWait %: 100.00
Buffer % success: 99.98% W/A optimal, Exec: 100.00
Library success %: 99,77% soft Parse: 99.82
Run parse %: 64.24 latch hit %: 99.98
Analyze the CPU to analyze Elapsd %: 53.15% Non-Parse CPU: 98.03

Shared pool statistics Begin End
------ ------
% Memory use: 10.50 12.79
% SQL with executions > 1: 69,98 78,37
% Memory for SQL w/exec > 1: 70.22 81,96
Top 5 timed events Avg % Total
~~~~~~~~~~~~~~~~~~                                                   wait   Call
Event waits time (s) (ms) time
----------------------------------------- ------------ ----------- ------ ------
CPU time                                                       847          50.2
ENQ: TX - 4 480 97 434 25.8 line lock conflict
Log file sync 284 169 185 1 11.0
log file parallel write 299 537 164 1 9.7
log file sequential read 698 16 24 1.0
Host CPU (processors: 2 hearts: Sockets 1: 0)
~ ~ ~ Medium load
Begin End User System Idle WIO WCPU
------- -------   ------- ------- ------- ------- --------
1.16 1.84 19.28 14.51 66.21 1.20 82.01

Instance of CPU
~~~~~~~~~~~~                                       % Time (seconds)
-------- --------------
Host: Time (s) Total: 7,193.8
Host: Availability of time processor (s): 2,430.7
% of time host is busy: 33.8
Instance: Time processor Total (s): 1,203.1
% Busy CPU used, for example: 49.5
Instance: Time of database total (s): 2,426.4
% DB time waiting for CPU (resp. resources): 0.0

Statistical memory Begin End
~~~~~~~~~~~~~~~~~                ------------ ------------
Host Mem (MB): 16,384.0 16 384,0
Use of LMS (MB): 7,136.0 7 136,0
Use of PGA (Mo): 282.5 361.4
Host % Mem used for SGA + PGA: 45.3 45.8
Foreground wait events DB/Inst: XXXXXs Snaps: 5635-5636
-> Only events with wait times Total (s) > =.001 are indicated
--> sorted by Total desc waiting time, waits desc (idle last events)

AVG % Total
% Tim Total wait Wait Wait call
Event is waiting for the time (s) (ms) /txn times
---------------------------- ------------ ---- ---------- ------ -------- ------
ENQ: TX - line lock 4 480 0 434 97 contentio 0,0 25.8
284 167 0 185 1 file synchronization log 1.5 11.0
File I/O 8 741 of disk 0 4 operations 0.0 0.2
direct path write 0 13 247 3 0.1 0.2
DB file sequential read 6 058 0 1 0.0 0.1
buffer busy waits 1 800 0 1 1 0,0.1
SQL * Net more data to the client 29 161 0 1 0.2 0.1
direct path read 7 696 0 1 0.0 0.0
db file scattered read 316 0 1 2 0,0.0
latch: shared pool 144 0 0 2 0,0.0
Initialization of 30 0 0 3 0,0.0 CSS
cursor: hand 10 0 0 9 0,0.0 S
lock row cache 41 0 0 2 0,0.0
latch: rank objects cache 19 0 0 3 0,0.0
log file switch (private 8 0 0 7 0,0.0 str
library cache: mutex X 28 0 0 2 0,0.0
latch: cache buffers chains 54 0 0 1 0,0.0
free lock 290 0 0 0.0 0.0
sequential control file read 1 568 0 0 0.0 0.0
switch logfile (4 0 0 6 0,0.0 control point
Live sync 8 0 0 3 0,0.0 road
latch: redo allocation 60 0 0 0 0.0.0
SQL * Net break/reset for 34 0 0 1 0,0.0 customer
latch: enqueue hash chains 45 0 0 0 0.0.0
latch: cache buffers lru chain 7 0 0 2 0,0.0
latch: allowance 5 0 0 1 0,0.0 session
latch: object queue header 6 0 0 1 0,0.0 o
Operation of metadata files ASM 30 0 0 0 0.0.0
latch: in memory of undo latch 15 0 0 0.0 0.0
latch: cancel the overall data 8 0 0 0 0.0.0
SQL * Net client message 6 362 536 0 278 225 44 33.7
jobq slave wait 7 270 100 3 635 500 0.0
SQL * Net more data to 7 976 0 15 2 0,0 clien
SQL * Net message to client 6 362 544 0 8 0 33.7
-------------------------------------------------------------
Context of the DB/Inst events waiting: XXXXXs clings: 5635-5636
-> Only events with wait times Total (s) > =.001 are indicated
--> sorted by Total desc waiting time, waits desc (idle last events)
AVG % Total
% Tim Total wait Wait Wait call
Event is waiting for the time (s) (ms) /txn times
---------------------------- ------------ ---- ---------- ------ -------- ------
log file parallel write 299 537 0 164 1 1.6 9.7
log file sequential read 698 0 16 24 0.0 1.0
db file parallel write 9 556 0 13 1 0,1.8
146 0 10 70 0,0.6 startup operating system thread
control file parallel write 2 037 0 2 1 0,0.1
Newspaper archive e/s 35 0 1 30 0,0.1
LGWR wait for redo copy 2 447 0 0 0.0 0.0
async file IO DB present 9 556 0 0 0.1 0.0
DB file sequential read 145 0 0 2 0,0.0
File I/O disk 349 0 operations 0 0.0 0.0
db file scattered read 30 0 0 4 0,0.0
sequential control file read 5 837 0 0 0.0 0.0
ADR block lu file 19 0 0 4 0,0.0
Block ADR file write 5 0 0 15 0,0.0
direct path write 14 0 0 2 0,0.0
direct path read 3 0 0 7 0,0.0
latch: shared pool 3 0 0 6 0,0.0
single log file write 56 0 0 0.0 0.0
latch: redo allocation 53 0 0 0 0.0.0
latch: 1 0 0 3 0,0.0 active service list
free latch 11 0 0 0 0.0.0
CPI of RDBMS 5 314 523 57 189 182 1.7 message
Space Manager: slave wa slowed 4 086 88 18 996 4649 0.0
DIAG idle wait 7 185 100 1000 7 186 0.0
Streams AQ: waiting time 2 50 4 909 # 0,0
Streams AQ: qmn slowed slave 129 0 3 612 28002 0.0 w
Streams AQ: Coordinator of the 258 50 3 612 14001 0,0 qmn
SMON timer 2 43 3 605 83839 0.0
PMON timer 99 1 199 2999 3 596 0.0
SQL * Net client message 17 019 0 31 2 0.1
SQL * Net message to client 12 762 0 0 0.1 0
class slaves wait 28 0 0 0 0.0
Thank you very much!

Hello

I think that your CPU is overloaded by your stress tests. You have one VCPU with 2 wires (2 LCPU), right? And the load average is greater than one. You have time DB which is not counted in (CPU time + wait events) and which comes no doubt from time spent in the runqueue.

> Oracle recovery logs is not properly configured on this server, as in "Top 5 events of waiting", there are 2 for oder

It is an error in statspack for show "log file parallel write here." This moment is historical and is included in 'log file sync '. And I don't think you have to redo misconfiguration. Waiting for 1ms to commit is ok. In OLTP you should have more than one validation in a user interaction so that the user don't worry not about 1 m in batch mode, unless you commit to each row, 1 DC to commit should not increase the total execution time.

The fact that you have a lot of line lock (enq: TX - line lock conflict) but very little time (on average 97 ms) is probably a sign that testers are running simultaneously a charge affecting the same data. Their set of test data is perhaps too simple and short. An example: when stress tests of an order entry system if you run 1000 concurrent sessions, ordering the same product to the same customer, you can get this kind of symptoms, but the test we unrealistic.

It's a high activity of 2000 calls per second, 52 transactions per second, user. But you also have low average active sessions, so the report probably covers a period of non-uniform activity, which makes the averages without meaning.

So note to tell about the events of waiting here. But we don't have any info about 39% of DB time devoted to the CPU which is where something can be improved.

Kind regards

Franck.

ENQ: TX - line lock conflict

Similar Questions

Maybe you are looking for