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, [EMAIL PROTECTED] at [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
