Striving for Optimal Performance
  • Home
  • Blog
    • Archive
    • Categories
  • Troubleshooting Oracle Performance
    • Description
    • Structure
    • Table of Contents
    • Forewords
    • Reviews
    • Downloadable Files
    • Addenda and Errata
  • Publications
  • Public Appearances
    • Past Public Appearances
  • Contact
  • Search
  • About

Invisible Indexes and Locks

Oct17
2008
6 Comments Written by Christian Antognini

Invisible indexes are useful to temporarily hide an index from the query optimizer. In this post, instead of explaining what invisible indexes are, I would like to show whether the database engine uses invisible indexes to avoid false contention caused by unindexed foreign key.

  • Let’s start by creating two test tables with a relation (foreign key) between them:
SQL> CREATE TABLE t1 AS SELECT rownum AS n FROM dual CONNECT BY level <= 10;

Table created.

SQL> CREATE TABLE t2 AS SELECT rownum AS n FROM dual CONNECT BY level <= 10;

Table created.

SQL> ALTER TABLE t1 ADD CONSTRAINT t1_uk UNIQUE (n);

Table altered.

SQL> ALTER TABLE t2 ADD CONSTRAINT t1_t2_fk FOREIGN KEY (n) REFERENCES t1 (n);

Table altered.
  • Note that the foreign key is unindexed. Therefore, as shown by the following example, false contention due to locks is possible:
Session 1 Session 2
SQL> SELECT sys_context('userenv','sid') AS sid
  2  FROM dual;

SID
----
86

SQL> INSERT INTO t2 VALUES (1);

1 row created.
SQL> SELECT sys_context('userenv','sid') AS sid
  2  FROM dual;

SID
----
85

SQL> DELETE FROM t2 WHERE n = 2;

1 row deleted.

SQL> DELETE FROM t1 WHERE n = 2;
SQL> SELECT blocking_session
  2  FROM v$session
  3  WHERE sid = 85;

BLOCKING_SESSION
----------------
              86

SQL> ROLLBACK;

Rollback complete.
1 row deleted.

SQL> ROLLBACK;

Rollback complete.
  • Now, let’s execute the same SQL statements when the the foreign key is indexed by an invisible index:
Session 1 Session 2
SQL> CREATE INDEX i ON t2 (n) INVISIBLE;

Index created.

SQL> INSERT INTO t2 VALUES (1);

1 row created.
SQL> DELETE FROM t2 WHERE n = 2;

1 row deleted.

SQL> DELETE FROM t1 WHERE n = 2;

1 row deleted.
  • As you can see there is no false contention due to locks.

Conclusion: invisible indexes can only be used to assess how the query optimizer would behave when a specific index is (not) available. But, be careful, with them you cannot assess how an application would behave when a specific index is (not) available. In fact, except for access paths, invisible indexes are regularly updated and used for setting locks when DML statements are executed.

Posted in 11gR1, Indexes
SHARE THIS Twitter Facebook Delicious StumbleUpon E-mail
← TOP on Google Book Search
Introduce TVD$XTAT →

3 Comments

  1. Asif Momen
    October 17, 2008 at 12:02 | Permalink

    Well demonstrated.

    Reply
  2. Surachart Opun
    December 3, 2009 at 05:18 | Permalink

    It’s a good example & idea to use invisible index with FOREIGN KEY.

    Reply
  3. Matthias Rogel
    May 13, 2013 at 12:10 | Permalink

    Christian,

    invisible indexes can even be used to back up a primary key
    http://richardfoote.wordpress.com/2008/11/20/visible-invisible-indexes-the-invisible-band/#comment-87679

    Regards
    Matthias

    Reply
  1. Visible Invisible Indexes (The Invisible Band) « Richard Foote’s Oracle Blog on November 20, 2008 at 13:57
  2. Book Review: Pro Oracle SQL « Charles Hooper's Oracle Notes on January 17, 2011 at 07:06
  3. Book Review: Oracle Database 11g Performance Tuning Recipes « Charles Hooper's Oracle Notes on September 10, 2011 at 22:13

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

*

*


4 + eight =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

EvoLve theme by Theme4Press  •  Powered by WordPress Striving for Optimal Performance