Thanks for the comments. And your comment about clusters -- from the
standpoint of getting the great clustering factor and minimizing I/O, I
experimented with self clustering a single table. I used data from a single
partition and it was around 25 million rows. A straight insert into a heap
First major issue encountered, ora-600, due to the use of the overflow. Here
are some comments from the Oracle analyst working the TAR:
*
We are failing as we are working with frames. There is a limit to the
number of frames in 8i, so it is possible to run out--if the
,
Bruce (CALBBAY)
Sent: Thursday, December 12, 2002 10:59 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: IOT Issues?
Larry,
Have you seen paper 138 at Orapub.com
(http://www.orapub.com/cgi/genesis.cgi?p1=subp2=abs138) titled
Index Organized Tables -- When should they be used
I've did some tests on 816.
The tables were small, 3-4 fields including the PK
with a number of rows between 200 000 and 300 000.
The query time was the same except that the IOT read
50% less blocks.
--- Reardon, Bruce (CALBBAY)
[EMAIL PROTECTED] a écrit :
Larry,
Have you seen paper 138
Larry Elkins wrote:
Listers,
Solaris 7, 8.1.7.4 64 bit, E10K.
Have a test IOT of around 120 million rows being created as we speak --
partitioned by month (3 months for the test), overflow by naming the column
at which to break, compressing the concatenated key, using secondary BMI's.
The first one (seen in 8.1.6 and 8.1.7) was deadlocks caused by
simultaneous SELECTs and the addition of a new partition (even though
the queries were not querying the partition). Those deadlocks were
occurring at the dictionary level - because even if an IOT is physically
a single index,
Larry,
Have you seen paper 138 at Orapub.com
(http://www.orapub.com/cgi/genesis.cgi?p1=subp2=abs138) titled Index Organized
Tables -- When should they be used?
This has some benchmark figures.
Also, do you use Forms as a client - this can introduce some gotchas with IOTs
(particularly if
