What is the Haken Factor?

We've encountered a problem with corrupt bitmap indexes on partitioned tables in Oracles 8.1.7.4. With Oracle's help we're making progress towards a solution, which appears to involve something called a 'Haken Factor'.

I gather this is an attribute of a table which is involved in sizing bitmap indexes, it appears in the SPARE1 column of sys.tab$.

Does anyone know anything about the Haken Factor, Metalink has quite a few references, Google almost nothing relevant. I can see that it's important, but I'm looking for a better explanation of what it is.
LVL 18
JR2003Asked:
Who is Participating?
 
seazodiacConnect With a Mentor Commented:
check this out, something I came across on the web.


Hakan factor is a number used by the
bitmap index algorithms to limit the number
of rows that Oracle assumes can be stored
in a single block.  It is (generally) dictated at
table creation time by the number and type
of non-null columns.  Check tab$.spare1
just after creating a table.


Things can go wrong with partitioned tables,
though, as the table has a Hakan factor, but
in your case you've created a table to exchange
with it that has a different Hakan factor.


The closest reference to your problem comes
from (a) minimize_records_per_block, which
can only be used in the absence of bitmap indexes
on a table and resets the Hakan factor, and (b) a
note about dropping bitmap indexes before your
first compress a data segment in a partitioned
table.
0
 
Mark GeerlingsConnect With a Mentor Database AdministratorCommented:
I can't answer your question exactly, but we also had some trouble with bit-mapped indexes in Oracle8.1.7.  I don't remember if they were on partitioned tables or not.  We ended up eliminating the bit-mapped indexes, because they caused more problems than they solved in our (mainly OLTP) system.  If you have a data warehouse, or if your bit-mapped indexes are limited to reporting tables that do not get concurrent inserts by multiple users, then you may want to keep your bit-mapped indexes.  We did try adjusting the spare1 column of sys.tab$ for those tables, but if I recall correctly that did not solve all of the problems.
0
 
JR2003Author Commented:
Thanks for your comments.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.