RE: GTT Locks

From: Ravi Kulkarni <kulkarni.ravi_at_heb.com>
Date: Wed, 03 Mar 2004 15:55:35 -0600
Message-id: <0HU000BMSSWLKK@sys98057.heb.com>

Thanks Jonathan..

What I am trying to understand is -

Why should there be a lock ONLY when using a select from a regular table and NOT when doing a simple insert ?
Why is the change in functionality between 8i and 9i ?
Where can I get more info(papers etc.) on this since we are using GTTs extensively and are gearing up for production in a few weeks.

Thanks,
Ravi.

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Jonathan Lewis Sent: Wednesday, March 03, 2004 12:04 PM To: oracle-l_at_freelists.org
Subject: Re: GTT Locks

Notes in-line

Jonathan Lewis
http://www.jlcomp.demon.co.uk

The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

March 2004 Hotsos Symposium - The Burden of Proof Dynamic Sampling - an investigation
March 2004 Charlotte OUG (www.cltoug.org) CBO Tutorial April 2004 Iceland
June 2004 UK - Optimising Oracle Seminar

Original Message ----- From: "Ravi Kulkarni" <kulkarni.ravi_at_heb.com> To: <oracle-l_at_freelists.org> Sent: Wednesday, March 03, 2004 5:15 PM Subject: RE: GTT Locks

> John,
>

Jonathan

>
> The table GTT needs to be a Global Temporary table.
>

Absolutely true - I don't know how I managed to forget the GT bit when I was doing the test

Having corrected the error, I agree with your observations:

insert into gtt values (1);

Locks:
TY ID1 ID2 LMODE
-- ---------- ---------- ----------

TX     131091       7538          6
TO      30494          1          3

commit;
insert into gtt select rownum from user_objects where rownum = 1;

TY ID1 ID2 LMODE
-- ---------- ---------- ----------

TX     393219       7548          6
TM      30494          0          3
TO      30494          1          3

commit;
begin

        for i in 1..10000 loop
            insert into gtt values (i);
        end loop;

end;
/

TY ID1 ID2 LMODE
-- ---------- ---------- ----------

TX     458780       7532          6
TO      30494          1          3



----------------------------------------------------------------

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

  --- Ravi Kulkarni <kulkarni.ravi_at_heb.com> wrote: > Trying to understand
the locking behavior of
 GTTs (Global Temporary Tables) :
 > (GTT_T is a GTT. T is a regular table)
 >
 > SQL> insert into gtt_t values (1000);
 > 1 row created.
 >
 > SQL> select object_name, object_type, a.object_id, b.locked_mode from
dba_objects a,
 > v$locked_object b where a.object_id=b.object_id;
 > no rows selected
 >
 > SQL> insert into gtt_t select *from T;
 > 1 row created.
 >
 > SQL> select object_name, object_type, a.object_id, b.locked_mode from
dba_objects a,
 > v$locked_object b where a.object_id=b.object_id;
 >
 > OBJECT_NAME   OBJECT_TYPE    OBJECT_ID     OBJECT_ID LOCKED_MODE
 > ----------------------------------------------------------------
 > GTT_T        TABLE           204835       204835     3
 >
 >
 > The user acquires a lock on the GTT for performing DML ONLY when
selecting from a Non-GTT.
 > 1. How is this different from the first insert on GTT? (In either case,
 noticed a 'TO'
 > lock-type in v$lock)
 > 2. Where can I find more info on GTT-peculiarities ?
 >
 > TIA,
 > Ravi.

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Wed Mar 03 2004 - 15:52:44 CST