oerr ora 14642
14642, 00000, "Bitmap index mismatch for tables in ALTER TABLE EXCHANGE
PARTITION"
// *Cause: The two tables in the EXCHANGE have usable bitmap
indexes, and the
//
INCLUDING INDEXES option has been specified and the tables
have
// different hakan
factors.
// *Action: Perform the exchange with the EXCLUDING INDEXES option
or alter the
// bitmap
indexes to be unusable.
oerr ora 14643
14643, 00000, "Hakan factor mismatch for tables in ALTER TABLE EXCHANGE
PARTITION"
// *Cause: Either records_per_block has been minimized for
one of the tables to
be
// exchanged, but
not the other, or the hakan factors for the tables to
be
// exchanged are not
equal.
// *Action: If records_per_block has been minimized for one of the
tables, but not
// the
other, either perform alter table with the NOMINIMIZE
RECORDS_PER_BLOCK
//
option for both tables, or perform alter table with the
MINIMIZE
//
RECORDS_PER_BLOCK for both tables. If the hakan factors do not
match
// perform alter
table with the NOMINIMIZE RECORDS_PER_BLOCK
option
// for both
tables.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 24, 2003 6:34 PM
To: Multiple recipients of list ORACLE-L
Subject: Re: Reorganizing tables
Jonathan,
What is the 'Haken' factor?
Jared
"Jonathan Lewis" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
03/24/2003 02:24 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: Re: Reorganizing tables
This may have been mentioned already, but a
table re-org can be a positive threat to performance.
If your primary tables have (for example) a three-stage
life:
initial row size is small
row grows after a couple of weeks
row reaches full size after another 4 weeks,
then what value are you going to use for your
PCTFREE when you rebuild ?
If you set it to zero to avoid wasting space
for the vast percentage of rows that are full
size then many incomplete rows will end up
migrating.
If you set it to match the growth requirement
of the newest rows, then you leave lots of
empty space in the blocks that hold only old
rows.
(The optimum storage answer is to set the
Hakan factor before moving the table - but
that's not a trivial exercise because of a bug
whose number I can't remember).
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
For one-day tutorials:
(see http://www.jlcomp.demon.co.uk/tutorial.html )
____UK_______April 8th
____UK_______April 22nd
____Denmark May 21-23rd
____USA_(FL)_May 2nd
Next dates for the 3-day seminar:
(see http://www.jlcomp.demon.co.uk/seminar.html )
____UK_(Manchester)_May
____Estonia___June (provisional)
____USA_(CA, TX)_August
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" <[EMAIL PROTECTED]>
Sent: 24 March 2003 20:53
> Thanks Jared, Rachel, Tom, Dick, Prakash, Ron
>
> Excellent points. Very much appreciated. Unfortunately at this point
people
> are asking "but have you tested it?". So I need to construct some
type of
> test that will demonstrate how much effect a reorg will have. After
I've
> answered that question, then I can move on to some of the other
issues that
> you mention. I have joked that if the results are strongly positive,
they
> won't see me much after that because I'll be touring the world
selling my
> performance solution that never occurred to anyone else.
> Our test system is cloned from an RMAN backup of production so
the tables
> should be close to production. I'm thinking of creating a new table
and
> copying the contents of a production table into it and then tracing
> full-table scans and comparing the results.
>
> Jared - is there a way to estimate block-level fragmentation?
Comparing the
> average row length with the number of blocks used?
>
> Dennis Williams
> DBA, 40%OCP, 100% DBA
> Lifetouch, Inc.
> [EMAIL PROTECTED]
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jonathan Lewis
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
