key and data segments do not match

[Jeff Harrison]

--- On Thu, 7/24/08, Brian K. White <brian at aljex.com> wrote:

> From: Brian K. White <brian at aljex.com>
> Subject: Re: key and data segments do not match
> To: filepro-list at lists.celestial.com
> Date: Thursday, July 24, 2008, 10:20 PM
> ----- Original Message ----- 
> From: "Jose Lerebours" <fp at fpgroups.com>
> To: "filePro Mailing List"
> <filepro-list at lists.celestial.com>
> Sent: Thursday, July 24, 2008 2:18 PM
> Subject: key and data segments do not match
> 
> 
> > I just received a call from a very old friend of mine.
>  He is having problems
> > where the error message key and data segments do not
> match  or something
> > to that effect is given when he tries to access a
> file.  I have not seen this in
> > such a long time I can only speculate that it means
> "the map was changed
> > by using vi while file is segmented between key and
> data thus causing map
> > + data association to be corrupt"
> >
> > OR
> >
> > "an old copy of the map was restored overriding
> the earlier map and the
> > restored map file does not match data segments"
> >
> > Whatever the reason, I wonder, what is the way out of
> this one?
> 
> 
> p,  A - Expand Files, select the file, add 10 or 100
> records.
> 
> 
> How does it happen? Who knows, probably more than one way
> anyways.
> 
> Is there a bad record somewhere now, even though the file
> "works" again? Probably. Probably at the end,
> since fp usually only changes the size of key or data when
> increasing it, meaning the discrepency was most likely
> caused while adding a new record. So just go to the highest
> record number (minus the new empty 100) and
> verify/fix/delete that record. Go to the record by record
> number, since the indexes may be buggy until after you
> clean up the bad record and then rebuild indexes.
> So, "ddir file -L ;dxmaint file -ra -e" after
> fixing the bad record is probably a good idea too. (delete
> lockfile, rebuild all indexes, so, not while users are in.)
> 
> We used to see this once in a blue moon, but often enough
> that the expand-files fix was a routine op. No single
> customer saw it very often. Supporting a lot of customers
> it was still only once in a while.
> 
> Probably the reason we never see this any more is we no
> longer use any data segments anywhere, all data are 0-byte
> everywhere.
> Perhaps that is why you never see it any more either?
> 
> -- 

Yes, but I would advise that he look at the data before runs dexpand to see if there is other corruption.  

Also, I have seen these types of problems when you reach the file limit size on your system, and the file cannot grow any larger - therefore the segments have differeing number of records.  Dexpand will not help in these cases.  If that is the case then he will need to create extents - or get rid of some data by archiving.

Jeff Harrison
jeffaharrison at yahoo.com