Re: Database space grawth decreses 100%

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Wed, 14 Jul 2004 18:27:00 -0700
Message-ID: <1089854838.781803@yasure>

Comments in-line.

Martin wrote:

>>There is insufficient information here to answer your primary question
>>but here are a couple of thoughts.
>>
>>1. What are you doing with 8.1.7.2? Even if for some reason you can't
>>    move to 9i or 10g there is no excuse for not being at 8.1.7.4.
>>
>>2. What is your setting for PCTUSED and PCTFREE on tables and PCTUSED
>>    on indexes?
>>
>>Daniel Morgan

>
>
> Hello Daniel,
>
> Answer to your first question has to with the way our organization
> works, please believe me when I say that we (DBAs) would love to be
> 10g or even 9i. Actual there are plans to upgrade to 9i by the end of
> this year, hopefully.

Understandable but what does that have to do with patching to 8.1.7.4?

> Answer to you second question, table PCTFREE, we moved tables (ones
> that account for most of the growth in and size of the database) with
> PCTFREE 10 and set it to 30 after the move. Table PCTUSED was 40.
> Indexes were rebuilding with PCTFREE 10.

I know this doesn't answer your question but 10/40 is the default values and almost always a waste of space and the generator of poorer performance.

> I guess I should have mentioned that we do not perform many deletions,
> our data is basically inserted and updated only, there is a purge
> process we have, but this particular client has chose not to run it.
>
> Moreover majority of objects that were moved/rebuild onto new LM
> tablespace were done in PARALLE.
>
> Martin

Can't explain the difference you described based on what I've read. But if I were DBA I'd be changing by block usage with PCTUSED and PCTFREE just after I patched to 8.1.7.4.

Daniel Morgan Received on Wed Jul 14 2004 - 20:27:00 CDT