Two years ago when partitioning came out we ran some tests. We found out
that oracle had some coding problems if you were using 8.0.5.
Everything ran okay, but it was slow.
The problems was with how the determined which partition to put data into.
If you had 200 partition and data was being loaded into the the last
partition, it had to do 200 compares and then insert. They have fixed it
and now the use a hash algorythem to determine which partition to insert
data into. It is really fast.
However you will find your biggest pay backs will be in doing selects.
Did you know that partitioning takes advantage of pararrel processing, so
your selects can be hitting several partitions at the same time. This
really speeds everything up.
You will not want to partition every table. Only those table that fit the
partitioning model. Also the way that you partition data can make or break
your application. You need to really think out how you are going to
partition a table. It really makes a big difference in performance. Try
different options and do some testing. Ask this question, "how are my users
going to access the data?" This is the starting question. Also you can
also see how partitioning is going to effect backups and system/database
management.
How many disks are you going to put data on. Which drives are used. Where
are my indexes and data?
All good question. So it's not just a partitioning question.
>From: "Toepke, Kevin M" <ktoepke_at_trilegiant.com>
>Reply-To: ORACLE-L_at_fatcity.com
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Subject: RE: Partitoned Table Insert Performance
>Date: Thu, 02 May 2002 09:48:31 -0800
>
>Way back in the days of Oracle 8.0.5 I did some performance testing of bulk
>inserts/sqlldr of range partitioned tables v.s. non-partitioned tables. I
>don't have the benchmarks on hand, but here's what I found. All tests were
>done using the direct path inserts (sqlldr direct=true or /*+ APPEND */)
>
>If the table had no indexes, then there was no noticable difference when
>inserting approx 8 million rows.
>
>If the partitioned table had only local indexes, then the inserts into the
>tables were slightly faster. The difference was in seconds for my 8million
>row test.
>
>If the partitioned table had global partitioned indexes, then the inserts
>were generally slower. Again, the diference was in seconds.
>
>If the partitioned table had a global non-partitioned index there was no
>noticable diffence in time.
>
>In sort, range partitioning a table does not effect performance. The
>indexing of the range-partitioned table does.
>
>HTH
>Caver
>
>-----Original Message-----
>Sent: Thursday, May 02, 2002 12:45 PM
>To: Multiple recipients of list ORACLE-L
>
>
>I am in the process of implementing partitioning on some existing tables. I
>have been asked by management to evaluate the performance impacts of the
>changes. I am aware of many of the performance advantages of partitioning:
>partition pruning, partition-wise joins and parallel data loads. What I am
>concerned about is the additional overhead of inserting data into a
>partitioned table. What sort of overhead is associated with partitioned
>table inserts? Does determining the correct partition slow insertions? We
>are utilizing only range partitions, so hash value computations should not
>be a factor. Our application is very insertion intensive. One of the
>operations that performs insertions does so synchronously, so any decrease
>in insertion performance would be quite visible. Do you have any thoughts
>or
>experiences with this issue. Any performance tests on two similar tables,
>one partitioned and the other not? Any input would be appreciated. Thanks.
>Erik
>
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: Toepke, Kevin M
> INET: ktoepke_at_trilegiant.com
>
>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>San Diego, California -- Public Internet access / Mailing Lists
>--------------------------------------------------------------------
>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).
Chat with friends online, try MSN Messenger:
http://messenger.msn.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: basher 59
INET: kb7yss_at_hotmail.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).
Received on Thu May 02 2002 - 13:53:42 CDT
