Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: problem about full scan temporary table

Re: problem about full scan temporary table

From: Jonathan Lewis <>
Date: Sun, 24 Sep 2006 08:31:24 +0100
Message-ID: <01e001c6dfab$707930b0$0300a8c0@Primary>

Every session gets its private copy of the table in the temporary tablespace (make sure it's big enough), and knows its own HWM.

If you are using 10g, consider using tablespace groups - just in case it gives you an edge in performance, and in case you need to drop and recreate some temporary files.

If you are running 9i, "on commit delete rows" may be a better bet than "on commit preserve rows". If you TRUNCATE a GTT, that counts as DDL which invalidates every cursor that references that GTT definition - even the cursors of people with their own private data sets. Fixed in 10.2. Conversely, the 'commit' if you have 'on commit delete rows' is not DDL, so doesn't invalidate anything. The whole thing may be a moot point, of course, as the impact on the library cache may be insignificant compared to the work done in lots of high-volume tablescans.


Jonathan Lewis

The Co-operative Oracle Users' FAQ

Cost Based Oracle: Fundamentals

> Hi, all
> I created a global temporary table, and many sessions
> will populate huge
> volume of data into this table. All of these sessions
> will access the table
> by means of full scan. Suppose session S1 inserted
> 10,000 blocks of data,
> and S2 inserted 10,000 blocks of data. If S1 scan the
> table, will it scan
> 10,000 blocks or 20,000 blocks? For normal table,
> there is high water mark
> that determine the upper boundary that oracle will
> scan, for temporary
> table, is there a similar high water mark for each
> session, or for all
> session?
> Thanks
> Robin
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> --
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.12.8/455 - Release Date: 22/09/2006

Received on Sun Sep 24 2006 - 02:31:24 CDT

Original text of this message