Solved

Table and Index in the same tablespace. Performance issue?

Posted on 2011-03-24
6
720 Views
Last Modified: 2013-12-19
Hi All,

I have a column in a table which is being populated by a sequence. And I have an index on this column. Both the table and the index are located in the same tablespace.  I am noticing multiple blocking sessions which exist for a very breif period. The wait event is TX : row lock contention. Is is correct to assume that the index is sequntial as the colum is being populated by a sequence? Because of this reason, would both table and the index element be sharing the same block? As I am doing multiple DMLs on this table, is this resulting in the TX : row lock contention?

Would it help creating the index in a different tablespace for columns populated with a sequence? or, would it be better if I created a reverse key index on this column?

Any input regarding this is greatly appreciated. My database is on 10.2.0.4 , (SunOS wust4019 5.10 Generic_142900-13 sun4u sparc SUNW,Sun-Fire)

Thank you,
0
Comment
Question by:GP7
6 Comments
 
LVL 73

Assisted Solution

by:sdstuber
sdstuber earned 100 total points
ID: 35212777
you've sort of combined 3 questions into one

yes/no - your index will be sequential (ordered) but not because the column is populated by an index, but rather because indexes are always sorted

no,  a table and an index won't share the same block,  every segment (table/index/lob/etc) is allocated in blocks and those blocks aren't shared

nor will having them in the same tablespace cause row lock contention
0
 
LVL 11

Accepted Solution

by:
Akenathon earned 300 total points
ID: 35212881
You have made so many questions that it's not easy where to start, I'll try to put some order:

- A table and each of its indexes have entirely separated segments, so there's no way they share ANY block whatsoever
- There is no such thing as a "sequential" index. Oracle uses BALANCED trees for index structures, so it's always a tree, and it's always balanced (i.e. all leaves are at the same level)
- The row lock contention only happens because more than one session is trying to write to THE SAME TABLE ROW. The exact same thing would happen if the index didn't exist, and the lock will only be released when the locking transaction ends (typically commits or rolls back). It's also unrelated to the fact that the index keys come from a sequence, the only thing which matters is that you are trying to write to the same row(s) at the same time
- You *could* separate the index segment to another tablespace, but for that to give you any difference, the corresponding datafiles would have to reside in separate physical disks or volume groups etc. With the many caches and RAIDs you have these days, I would recommend that you don't go that way... you'll hardly notice the difference on most cases, plus you can certainly make matters worse if you start herding some segments to some particular storage
- The reverse key index is nice for avoiding hot index blocks (if you have many inserts, or if "most" activity occurs in the "new" end of the index, this could well be your case). However, it is terrible for range scans, so doublecheck that you only do index lookups for exact key matches, and that you will never want anything other than that. Again, this has no relation to locking issues

As a general advice, don't embark into a tuning excercise if your users don't see any problem at present or in the near future. If you do, benchmark and trace whatever they accuse of "being slow" and try to understand what's taking the DBMS so long.
0
 
LVL 37

Expert Comment

by:Geert Gruwez
ID: 35213480
a sequence ...

are you talking about a oracle sequence ?
or something using a trigger like this:

insert into table_x (b, c, d) values (2, 3, 4);

> a insert trigger on table_x is used to fill column a with a sequence

trigger content
 
CREATE TRIGGER ins_table_x
BEFORE INSERT ON table_x
FOR EACH ROW
DECLARE 
  aa NUMBER;  
BEGIN
  IF :new.a=0 or :new.a IS NULL THEN
    UPDATE SEQUENCES SET SEQUENCE = NVL(SEQUENCE, 0)+1 WHERE TABLE_NAME = 'table_x';
    SELECT SEQUENCE INTO aa FROM SEQUENCES WHERE TABLE_NAME = 'table_x';
    :new.a := aa;
  END IF;
END;
/

Open in new window


using a trigger like this can cause row lock contention
0
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 
LVL 15

Assisted Solution

by:Franck Pachot
Franck Pachot earned 100 total points
ID: 35218504
Hi,

So you have sessions waiting for 'enq: TX - row lock contention'
This is not a lock at block level or you would have 'TX - allocate ITL entry'
Now try to find the lock mode. If you got the event from v$session, then check P1 column:
If P1=1415053316 (hexadecimal 54580004) it is a mode 4 lock
If P1=1415053318 (hexadecimal 54580006) it is a mode 6 lock

Mode 6 lock is contention on table row
Mode 4 lock is probably contention on unique index entry

Nothing to do with blocks, nor tablespaces, nor sequences (if you insert from a sequence, you cannot have a contention as you cannot have same number for 2 sessions).
In v$session, you also have information to identify the row it is waiting on.

Regards,
Franck.
0
 

Author Comment

by:GP7
ID: 35307985
Thank you all for your input.

@frackpachot - It is a mode 6 lock.

The app team has been informed about this and they are making some code changes to avoid these blocking sessions.

I appreciate your time and your comments. Thank you.
0
 

Author Closing Comment

by:GP7
ID: 35307993
Thank you all...
0

Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Working with Network Access Control Lists in Oracle 11g (part 2) Part 1: http://www.e-e.com/A_8429.html Previously, I introduced the basics of network ACL's including how to create, delete and modify entries to allow and deny access.  For many…
Have you ever had to make fundamental changes to a table in Oracle, but haven't been able to get any downtime?  I'm talking things like: * Dropping columns * Shrinking allocated space * Removing chained blocks and restoring the PCTFREE * Re-or…
This video shows setup options and the basic steps and syntax for duplicating (cloning) a database from one instance to another. Examples are given for duplicating to the same machine and to different machines
This video shows syntax for various backup options while discussing how the different basic backup types work.  It explains how to take full backups, incremental level 0 backups, incremental level 1 backups in both differential and cumulative mode a…

785 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question