RE: Partition Question

I agree too,
You have to know what is best for you,
I just partitioned several tables by date value... left the "historic" records in one partition (let's say date < Jan 2002) and the rest of the records in another partition.....but that was because it was the best for us, some users generate historic reports, and other users just update the transactions of the day and generate reports of that day... Hope this helps,

Saludos,
Veronica Levin Enriquez
Compañía Cervecera de Nicaragua

-----Mensaje original-----
De: Mark Richard [mailto:mrichard_at_transurban.com.au] Enviado el: Tuesday, November 05, 2002 4:09 PM Para: Multiple recipients of list ORACLE-L Asunto: Re: Partition Question

I agree...

What are you trying to accomplish with partitioning? Partitioning by year / month / day / whatever can make it easy to truncate / archive old data. The only trick is to create new partitions before they are required.

Another goal of partitioning may be query execution. You might partition a table by a certain column what is frequently stored in a where clause. This might restrict the query to a partition rather than the entire table and (depending on the query) could give a performance gain.

If you are lucky partitioning will achieve both, if you are unlucky partitioning will just introduce a maintenance hassle. Think about why you want to partition the table and what you expect to gain by doing it. Whatever you do, don't partition simply because you can.

Regards,

     Mark.  

                    Don Jerman

                    <djerman_at_dot.st       To:     Multiple recipients of
list ORACLE-L <ORACLE-L_at_fatcity.com>       
                    ate.nc.us>            cc:

                    Sent by:              Subject:     Re: Partition
Question                                       
                    root_at_fatcity.co

                    m

 

 

                    05/11/2002

                    05:54

                    Please respond

                    to ORACLE-L

 

 

It depends on your reason for partitioning -- if you mean to drop a partition in
the future (to roll off the 1999 data or whatever) then the ID range is potentially a valid approach, as long as ID is serial. If you just want to put
chunks on different disk volumes, you could use the type or even a hash partitioning scheme. It's down to what you're trying to accomplish, and what is
good for one partition key is probably bad or neutral for the other.

Hamid Alavi wrote:

> Hi List,
>
> I have a question regarding partitioning: If I want to partition a table
> which strategy is better, like do i have to use a value which from first
day
> of using this table all those partion is using or just using first
partion,
> then second etc.
> E.G:
> If I do partion tableA based on ID range 10000000, so for few month the
only
> first partion of this table will be used then second partion, but if I
> partion it on Type (1,2,3,4,5) any record can be any of these type and
from
> first day all of the partions will be used.
> Just want to check with you guys which way is better for performance?
> THanks for HELP>
>
> Hamid Alavi
> Office 818 737-0526
> Cell 818 416-5095
>
> ======================= Confidentiality Statement =======================
> The information contained in this message and any attachments is
> intended only for the use of the individual or entity to which it is
> addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL
> and exempt from disclosure under applicable law. If you have received
> this message in error, you are prohibited from copying, distributing, or
> using the information. Please contact the sender immediately by return
> e-mail and delete the original message from your system.
> ===================== End Confidentiality Statement =====================
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Hamid Alavi
> INET: hamid.alavi_at_quovadx.com
>
> 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: ListGuru_at_fatcity.com (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).
(See attached file: djerman.vcf)

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

   Privileged/Confidential information may be contained in this message.

          If you are not the addressee indicated in this message
       (or responsible for delivery of the message to such person),
            you may not copy or deliver this message to anyone.
In such case, you should destroy this message and kindly notify the sender
           by reply e-mail or by telephone on (61 3) 9612-6999.
   Please advise immediately if you or your employer does not consent to
                Internet e-mail for messages of this kind.
        Opinions, conclusions and other information in this message
              that do not relate to the official business of
                         Transurban City Link Ltd
         shall be understood as neither given nor endorsed by it.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Veronica Levin
  INET: vlevin_at_victoria.com.ni

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: ListGuru_at_fatcity.com (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).