RE: Partitioning opinion
- From: "Mohan, Ross" <RMohan@xxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 31 Aug 2004 13:53:13 -0400
HS -
From bloody personal experience, I'd stay away
from globals on partitioned tables unless
1) the tables are "small" (say, e.g. partitions under about 1G each)
2) you are willing to delete from about-to-be-archived partitions
before dropping them, in order to preserve the globals. (Not an
issue
in 9i, but haven't tested this in battle. Looks great on marketing
paper.)
I haven't found a single case where a well-thought app absolutely needed
globals (IMHO, the "I need my PK, Waaaah" argument is spurious) on a
partitioned
table.
Having said that, it's been a real pleasure having the partitions to work
with.
Final thought: You might want to consider separate tspaces for your really
large
part_tables and their indexes. Could come in handy if you decide to do the
transportable tablespace shuffle in the future. (Of course, globals make
this
harder, as well) .
JMTC,
- RM
-----Original Message-----
From: Gogala, Mladen [mailto:Mladen.Gogala@xxxxxxxx]
Sent: Tuesday, August 31, 2004 1:31 PM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: Partitioning opinion
Harvinder, partitions are tables in disguise. In Oracle7 there were things
called "partition views". In Oracle8, there was a logical leap with respect
to the notion of "segment". Before Oracle8 there was 1-to-1 correspondence
("bijective mapping") between tables and data segments and between indexes
and index segments. That is no longer true. With partitioning option, the
bijective mapping is broken and a table can have more then a single segment.
Why am I telling you all that? If you take a look at traces generated by the
event 10053, you'll see that partition pruning is done first, then the
access path to the particular partition(s) is determined. If an optimizer
decides that the desired result lies within a single partition, and it will
consider all indexes it has on that partition to resolve the query,
regardless whether they're global or local. Local indexes have one B-tree
for each partition, which (hopefully) has fewer entries then then the global
B-tree index and is of fewer degree (level). Local indexes are easier to
search because of the sheer size. The dark secret
of the partitioning option is that partitions are tables in disguise, and
should be treated as such.
--
Mladen Gogala
A & E TV Network
Ext. 1216
> -----Original Message-----
> From: Harvinder Singh [mailto:Harvinder.Singh@xxxxxxxxxxxxx]
> Sent: Tuesday, August 31, 2004 1:02 PM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: Partitioning opinion
>
>
> Hi,
>
> We have a table having 14 columns and contain historical data
> and we are planning to implement partitioning so that we will
> keep only 12 months data online and purge the old partition
> every month. We will be using Range partitioning on Date
> column name Interv and have primary key on (id,Interv). Data
> is never updated and only deleted for archiving that we are
> planning to do as drop partition so for most of the time only
> inserts will go against this table and few Selects. For
> performance of select we have to add 2 more non-unique global
> indexes. So the schema will look like: Primary key index on
> (id,Interv) Does non-prefix local indexes be Ok or we should
> change the order of PK to (interv,id) to have prefix local
> index? Non-unique index on 3 columns Non-unique index on 3
> columns Should we partition these global non-unique indexes
> or it does not matter since partitions will not be used by
> optimizer for pruning?
>
> Thanks
> --Harvinder
>
>
>
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
