Re: Oracle partitioning

Without knowing what queries are to be run and how you intend to partition your data then it really is an open ended question. Example :

You have an historical sales table, with a primary key :

Customer
Product
Date

you could partition the data on the date field: maybe have 12 partitions across separate devices, each partition holding a separate month. This spreads i-o and reduces your partitions to manageable chunks. If, however, the major part of the analysis of this data is done per time period, that is you run monthly reports, then the partitioning is not so effective because the report you run for any given month is accessing one partition only. So maybe you should think about partitioning on 'arbitrary' columns that provide a more randomised i-o sweep .. or maybe not .. it depends too much on what the data is and what applications are going to access it and how.

The simple answer is : Partitioning provides benefits for handling large tables but those benefits are directly proportional to amount of up front analysis you do re data and application access. Same as ever.

There are no easy answers .. no matter how simple the question is.

Hope this helps.

Neil

kachkar_at_my-deja.com wrote in message <7v82bs$om9$1_at_nnrp1.deja.com>...
>In article <7v6fj1$bif$1_at_ctb-nnrp1.saix.net>,
> "Billy Verreynne" <vslabs_at_onwe.co.za> wrote:
>> kachkar_at_my-deja.com wrote in message <7v609f$833$1_at_nnrp1.deja.com>...
>>
>> >I have some simple questions :
>> >How effective is the partitioning ?
>>
>> As effective as the implementation of it.
>>
>> >If I implemented it, Is it going to cut down the query time by 100% ?
>>
>> Very unlikely.
>>
>> >I would like to here from anybody who used it , and how fast is the
>> >performance before and after using the partitioning…
>>
>> Ah.. this question makes more sense. However, the answer IMHO will
>still be
>> meaningless with regards to your situation.
>>
>> There are no hard and fast rules in database systems. There's no magic
>wand
>> solutions that always work and always provide huge performance
>increases.
>> There are too many factors that are unique to every situation.
>>
>> To partition or not to partition can only really be answered by
>> investigating the data you want to partition, how these partition
>tables are
>> to be populated, updated and maintained, what type of queries are run,
>and
>> so on.
>>
>> regards,
>> Billy
>>
>>
>
>
>Billy ,
>
>Let us assume that I've created the ideal environment for the
>partitioning, again how
>effective is the partitioning ?
>
>Regards,
>Khaled Achkar
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
Received on Thu Oct 28 1999 - 06:57:22 CDT