Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1347
  • Last Modified:

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.
0
JR2003
Asked:
JR2003
2 Solutions
 
seazodiacCommented:
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 GeerlingsDatabase 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

Featured Post

NEW Veeam Backup for Microsoft Office 365 1.5

With Office 365, it’s your data and your responsibility to protect it. NEW Veeam Backup for Microsoft Office 365 eliminates the risk of losing access to your Office 365 data.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now