Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Direct Path Inserts and Partition Splits

Re: Direct Path Inserts and Partition Splits

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Wed, 18 Dec 2002 13:25:36 -0800
Message-ID: <F001.0051D935.20021218132536@fatcity.com>

Ten minute partitions sound painful !
(That's as close as I can get to "what

kind of a DBA are you" ;)

Two attendant questions -

How many partitions will you end up with in the table ? Large numbers, especially when locally indexed, can result in dictionary thrashing. Also, depending on the nature of the queries, the overheads may far outweigh any anticipated performance benefits.

What's the splitting strategy - split every 10 minutes, or split (say) once every 24 hours to break off the last day, then split that day into 10 minute slices ?

Remember that every time you split a partition you invalidate dependent objects - which includes all cursors - so the impact on any otherwise sharable SQL is bad.

Remember too that every time you split, Oracle renumber every partition above the split point - and every time you drop a partition you renumber every partition about the drop point.

Your description has just reminded me of one bizarre accident I got when stressing partitioned IOTs in Oracle 8.1.6 - I couldn't reproduce it, but I managed to get a partition that APPEARED to belong to the table I wanted it in, but (like you) if I queried it by name it didn't exist in the table, but if I queried the main table with a suitable range of values the data appeared.

Somehow the data dictionary knew it belonged to two different tables in two different schemas - so a direct query wouldn't find it, but a data-based query visited it without checking its ownership.

You could try flushing the shared pool before doing the trace - if the dictionary cache holds all the defining information, a trace file may not show the cause of such an error; but if the defining data has to be reloaded into the dictionary cache, then you may spot the
FETCH that fails.

Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

Coming soon a new one-day tutorial:
Cost Based Optimisation
(see http://www.jlcomp.demon.co.uk/tutorial.html )

Next Seminar dates:
(see http://www.jlcomp.demon.co.uk/seminar.html )

____England______January 21/23

The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

-----Original Message-----
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Date: 18 December 2002 20:25

The database version is 9.0.1.3. The OCI program attempts to obtain an exclusive lock on the table, and waits until the split operation is complete and the locks associated with the split are released allowing it to resume.

In the production system we will have partitions to hold ten minutes worth of data. The present table was created with two partitions one called first and the other bin. All inserts were to the bin partition. It was the bin partition which was split.

As I stated before the bin partition was split on December 4th into partitions for Nov 26, Nov 27, Nov 28, Nov 29, and Nov 30. Data for dates after November 30th remained in the bin partition, which also remained the insert partition. Partitions for Nov 26 and Nov 27 were moved to a different table and then dropped from the original The trouble was discovered when the user tried to do a count(*) against Nov 28 partition. All partitions left in the original table return an 8103 error when specifically named in the query. However data except for about 1.5 hours of the 28 November partition is accessible if the query is based on date ranges.

I did do a simple 10046 trace at Oracle's behest. The statement being traced failed with the 8103 error, however the trace itself recorded no problems. Nothing looks out of the ordinary at all concerning the obj$ table.

Oracle's proclamation is that its okay to split partitions which are involved in a pending DML operation. This partition an insert statement queued awaiting the release of the resource. Their concern was what if the split changed the partition to which the pending insert should go. In this case it would not have.



I have oscillated in my own mind, it's my first experience with partitioning, whether what we did would obviously cause dictionary corruption Certainly it would have been better to create the table with the necessary partitions in the first place. The production system will undergo significant partition management operations, just not against the partition which is receiving the data. I was really hoping for an " Of course what you did will cause dictionary corruption. What kind of DBA are you anyway?" response. I could then add it to my experience and tut-tut anyone who tried to do the same in the future. Your answer has only increased my unease about going forward.

Ian

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jonathan Lewis
  INET: jonathan_at_jlcomp.demon.co.uk

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).
Received on Wed Dec 18 2002 - 15:25:36 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US