Re: Oracle 8.1.17 extent management

From: Peter Hitchman <pjhoraclel_at_gmail.com>
Date: Fri, 20 Jun 2008 13:38:01 +0100
Message-ID: <5e317f310806200538o21e22640p70c7bfee5ac5fadd@mail.gmail.com>


Hi,
If it can be done move to locally managed tablespaces and for the major objects in the database place them in their own tablespaces defined using uniform extent sizes.
If not define dictionary tablespaces that have the same initial and next extent sizes, also it is possible to define a minimum extent size, which if you make the same as the initial/next, means that there will never be different extent sizes in any tablespace. If it is not practical to move to new dictionary tablespaces then yes alter the next extent values. Sounds like someone trying to keep all of the data in one extent, which was never really a good idea, I had to deal with the same issue - tables defined with massive initial extent sizes and tiny next sizes. Also I never define storage attributes at the object level now, I create appropriate tablespaces and let the objects inherit the settings from their tablespace.

Regards

Pete

On Fri, Jun 20, 2008 at 12:36 PM, John Dunn <JDunn_at_sefas.com> wrote:

> In have a customer still runing 8.1.7. They were having performance
> issues which appeared to be due to frgmentation. An export and import solved
> the performance issue.
>
> They are due to move to Orcale 10 soon, but in the mean time what can they
> do to minimise fragmentation on 8.1.7.
>
> Move to locally managed tablespaces? Change the next extent values(which
> appear to be very small) ?
>
>
>
> John Dunn
>
> Product Consultant
>
> Sefas Innovation Limited
>
> Direct Dial + 44 (0) 117 373 6122
>
> *www.sefas.com*
>
> Sefas Innovation Ltd, CityPoint, Temple Gate, Bristol BS1 6PL, UK. Tel: +44
> (0) 117 373 6114 Fax: +44 (0) 117 373 6115
>
> *Sefas Innovation Limited. *Registered No: 3769761 England. Registered
> Office: One New Street, Wells, Somerset, BA5 2LA, United Kingdom. VAT
> Registration No: GB 741 5377 32
>
> Unless stated to be non-confidential, this email and any attachments are
> private and confidential and are for the addressee only. Sefas monitors
> e-mails to ensure its systems operate effectively and to minimize the risk
> of viruses. Whilst Sefas has taken reasonable steps to scan this email, it
> does not accept liability for any virus that may be contained in it.
>
> Internet communications are not 100% secure and as such Sefas is not
> responsible for their abuse by 3rd parties, nor for any alteration or
> corruption in transmission.
>
>
>

-- 
Regards

Pete

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Jun 20 2008 - 07:38:01 CDT

Original text of this message