Re: Re: using temp tables for staging databases?

we drop and recreate the temp tables every night. We also use PCTFREE PCTUSED at 99 and 1 to pack in the blocks and we use very small extent sizes. then we analyze with an estimate size of 20 percent which is quite fast.

All of them are used for full table scans and do not have indexes. Ive found that a 'create table as' is MUCH faster than inserting into global temporary tables when you do not have to worry about latch contention(ie 1-3 users logged in at a time).

anyone else notice this? Seems to go against conventional wisdom which says never use them. So I want to make sure Im not missing something.
>
> From: Tim Gorman <tim_at_sagelogix.com>
> Date: 2003/10/20 Mon AM 10:19:33 EDT
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> Subject: Re: using temp tables for staging databases?
>
> All the time. Oracle Apps's "open interfaces" are built this way, for
> example.
>
> However, "the guys here" covered their bases by specifying "smaller
> temporary tables", as if they could prevent them from becoming large. I
> suppose they might feel that they indemnify themselves if the tables should
> ever become "large"?
>
> As with OraApps "open interface" tables, it is when a large volume of data
> is pushed through that the trouble starts. The "high-water marks" on all
> the tables are pushed to a high level, thereafter causing full table scans
> on the interface/temporary tables to run slowly. The only way to bring the
> HWM back down is quiesce the interface/app and then truncate the tables.
>
>
>
> on 10/20/03 6:39 AM, rgaffuri_at_cox.net at rgaffuri_at_cox.net wrote:
>
> > This is for non-transactional data load instances. The guys here sware that by
> > using smaller temporary tables(not global temp tables) they can increase the
> > speed of the data loads.
> >
> > Not worried about latch contention because its just for bulk loads. I know
> > this bad in transactional instances. Has anyone used these in
> > non-transactional data load instances?
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Tim Gorman
> INET: tim_at_sagelogix.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: <rgaffuri_at_cox.net
  INET: rgaffuri_at_cox.net

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).