Re: Challenge: Partitioning is a wrong idea

Joel Garry wrote:
> Even this guy can come up with more things:
> http://www.dba-oracle.com/oracle_tips_partitioning.htm

Spell out your arguments and I will address them the way I address Don's:

• Stable - Partitioning is a very stable technology and has been used in Oracle since Oracle8, back in 1997. Each new release of Oracle improves partitioning features.

The code is a liability. There are always bugs in it. There is always a case when during new feature design its interaction with partitioning simply haven't been thought out.

• Robust - Oracle9i partitioning allows for multi-level keys, a combination of the Range and List partitioning technique. The table is first range-partitioned, and then each individual range-partition is further sub-partitioned using a list partitioning technique. Unlike composite Range-Hash partitioning, the content of each sub-partition represents a logical subset of the data, described by its appropriate Range and List partition setup.

OK, I can range partition, then I could hash partition on top of it. Cool. Prove me that even one level of partitioning gives me a single benefit, first.

• Faster backups - A DBA can back-up a single partition of a table, rather than backing up the entire table, thereby reducing backup time.

You want to backup a portion of the table? Have it occured to you that

create table_copy as
select * from table_at_db_link
where my_criteria

is perhaps the simplest and the most flexible way to accomplish this?

• Less overhead - Because older partitioned tablespaces can be marked as read-only, Oracle has less stress on the redo logs, locks and latches, thereby improving overall performance.

What are partitioned tablespaces? Is it one more concept to learn?

• Easier management - Maintenance of partitioned tables is improved because maintenance can be focused on particular portions of tables. For maintenance operations across an entire database object, it is possible to perform these operations on a per-partition basis, thus dividing the maintenance process into more manageable chunks.

This should be clarifed. What kind of maintenance? The way to focus onto a certain portion of the table is

select from table where your_focus_condition

This could be a part of bigger maintenence operation.

• Faster SQL - Oracle is partition-aware, and some SQL may improve is speed by several orders of magnitude (over 100x faster).

This is anecdotical evidence without a SQL*Plus log proof in Tom's style.

• Index range scans - Partitioning physically sequences rows in index-order causing a dramatic improvement (over 10x faster) in the speed of partition-key scans.

Sorry, no. Index range scans has nothing to do with partitioning. Their speed is attributed to ingenious B*Tree structure.

• Full-table scans - Partition pruning only access those data blocks required by the query.

Select by index range scan, instead! Admittedly, this is might be inferior to partition scan beacause random IO is less performant than sequential one. Make the table index-organized, then. (You f**ked up the table physical layout with these "partitions" anyway. Index organised table provides some coherent structure, at least).

• Table joins - Partition-wise joins take the specific sub-set of the query partitions, causing huge speed improvements on nested loop and hash joins.

Would it be faster than indexed nested loop?

• Updates - Oracle parallel query for partitions improves batch load speed by

Parallel query could work with normal tables as well, right? Received on Thu Apr 07 2005 - 20:04:21 CDT