Large database, consistently corrupted header when building index for 2 fields, 100% reproducible

[Matthew Jew]

> On 10/7/08 5:24 PM, "Matthew Jew" <mjew at icnc.com> wrote:
>
> Hi Matthew,
>
> > I have a very large database, which I am building by importing the
> > contents of about 60 smaller databases.
> > Each of the smaller databases is error-free (can be diagnosed
> > successfully with no problems.)
>
> ok
>
> > However, when my application copies the contents of those  
> databases  into one
> > very large database (about 9 million records) two of the indexes are
> > corrupted. (Both  fields are unsigned long fields.)
> >
> > This line is from the very verbose diagnosis output:
> >
> > PAGE (5446, 5440) Corrupted Header (Values Count). Corrupted Header
> > (Values count < RecID count). At least one value counter is wrong.
>
> > The diagnosis finds no other problems. (No other indexes have
> > problems, no tables have problems.)
>
> Wow, ULONG. ...
>
> ----
> > During the importing, I turn off indexing (for speed).
>
> ok
>
> > At the end, I turn back on indexing. The indexing process takes  
> about  2 hours
> > and 30 minutes (or so). Most of the time indexing is spent on a  
> single field
> > that is being  indexed by word (that takes 2 hours).
>
> What cache size you have. Make it as big as possible during indexing.
> Helps a lots.
>
> > The other fields just take a short time to index (a few minutes).
>
> ok
>
> > The re-indexing process completes successfully. However, when I do a
> > diagnosis of the database, it consistently has a corrupted header  
> for those
> > two unsigned long  fields.
>
> > What should I do?
>
> * Are this 2 ULONG fields from the same table?

Yes, they are in the same table.

>
> * Does this table have OTHER ULONG fields?

Yes, there are 7 unsigned long fields.
Of the 7 unsigned long fields, 3 of them are indexed.
2 unsigned long indexes have problems.
1 unsigned long index is all right.
All other indexes of other types are all right.

>
> * how many records in THIS table ?
>

9,791,162 records in this table.

>
> * So I assume that if EXPORT only this one ULONG field into text  
> field,
>     then create a new db with one table and one ulong field,
>     and import back this data
>         then reindex => should reproduce problem.
>

Not so.
I tried that, and if I set up a new table with just the one ULONG field
and import the data, then index it, the problem does NOT occur.

However, if I take the existing full database, turn off indexing on  
ALL fields,
then turn on indexing on just that one specific ULONG field, the  
problem happens
in the exact same place:
  PAGE (5446, 5440) Corrupted Header (Values Count). Corrupted Header  
(Values count < RecID count). At least one value counter is wrong.


> If this does, then we get 9M * 4 bytes = 36Mb table size,
>     compressed about 5Mb.
>
>

I can compress the full .dat file to about 604 MB using ZIP,
and using StuffIt can compress all the DB parts to about 532 MB.

The version I have compressed is one with all the data, but
all the indexes have been turned off.
You can activate indexing for just the newsgroupNumber field
and see that the index that is created has the corrupted header problem.
(Or it did every single time I tried to create the index for it.)
The index seemed to only take a few seconds to create.

I can set up a private web page and/or FTP folder for you,
and send you the link information privately, if that would work for you.

- Matthew

> You must be able send this db without index to me.
> Then I will be able reproduce it and debug asap.
>
>
> Also I remember that in Mantis present similar bug report from Ivan.
> I need check all this.
>
> -- 
> Best regards,
>
> Ruslan Zasukhin
>
>