Re: TRUNCATE Table Command

From: Rennick Sandra <t89003_at_isdserv.dehavilland.ca>
Date: 1995/06/22
Message-ID: <1995Jun22.191832.23480_at_dhnews.dehavilland.ca>#1/1


Tony Jambu (aaj_at_phantom.telecom.com.au) wrote:
: In article <1995Jun15.180113.6313_at_dhnews.dehavilland.ca>,
: t89003_at_isdserv.dehavilland.ca (Rennick Sandra) writes:
: >
: > We have just encountered an interesting situation using the TRUNCATE TABLE
: > command with the DROP STORAGE option. We have a table that was originally
: > defined with a NEXT extent of 1M. Several weeks ago, we changed the NEXT
: > extent to be 10M. After we truncated the table, the NEXT extent was
: > redefined to the original value of 1M. Not knowing that this would happen,
: > we then attempted to import data into the table, and ran out of extents.
: >
: > Has anyone seen this before? Can anyone explain why this happened?
 

: It is documented in the manuals. If it is causing your hassles, why
: not just use the REUSE STORAGE option to TRUNCATE?
 

: ta
: tony

We cannot use the REUSE STORAGE option because this table contains a long field. The application that uses this table constantly deletes and inserts (no updates) data. Due to excessive chaining, the free space in the blocks does not seem to be reused after a while. Instead, the table gets a new extent. Eventually, the table runs out of space in the tablespace. As well, the performance decreases; which is again attributed to chaining. This is my first experience with using the long datatype. Is there a special way that the table should be defined? i.e. PCTFREE and PCTUSED?

Sandra Received on Thu Jun 22 1995 - 00:00:00 CEST

Original text of this message