Corruption detected

MiniMe · Post by **MiniMe** » Mon Mar 17, 2003 3:59 pm

I have a script that updates and inserts records. It kept displaying

006 /db/maint/runupdates:387: Can't write to KDBF file /db/tables/prod/books.tbl: Corruption detected in the function kdbf_put
100 /db/maint/runupdates:387: Record write failed

when doing an insert. I ran kdbfchk on the table and it ran out of memory the first time I did it. So I restored the database from a known good copy but yet am having these errors. Any ideas...??

Post by **Kai** » Mon Mar 17, 2003 4:46 pm

Check the usual culprits: is plenty of space free on the filesystem where this table is?

Also, when restoring the table from backup, did you stop all activity (read and write) on that table during the copy? Did you also drop and re-make all indexes on the table afterwards? Last, during the original save of the table, was table write activity stopped (so an atomic copy would be made)?

MiniMe · Post by **MiniMe** » Mon Mar 17, 2003 5:01 pm

Yes. the slice is only at 63 %... I didn't remake all of the indexes.. do you recommend I do that...

Yes an atomic copy was made..

Post by **Kai** » Mon Mar 17, 2003 5:14 pm

Yes, drop and re-make all indexes. Any time any Texis files are modified outside of Texis (eg. a backup restore), indexes may be out of sync and can cause corruption.

(Not sure what you mean by "slice is only at 63%": do you mean the #-mark progress meter for kdbfchk?)

MiniMe · Post by **MiniMe** » Mon Mar 17, 2003 5:25 pm

You had asked if the disk was full. No.. its only 63% full.

M.

Post by **Kai** » Mon Mar 17, 2003 5:44 pm

Oh, right, the disk-space pie slice. I'm too used to df...

MiniMe · Post by **MiniMe** » Tue Mar 18, 2003 12:42 pm

I dropped one of the indexes and during the creation of the new one it said I had a corrup block at 23440009766. So I went in and tried to calculate the block size so I could delete it but the shell script is still running after 12 hours. Does this mean that there is something majorly wrong with the table. Its almost 25 gigabytes so I hate to have to recreate it..

Post by **Kai** » Tue Mar 18, 2003 1:08 pm

You could scan for potentially valid headers after the corrupt one with kdbfchk -L <offset>, and use the offset of the next valid header to compute the corrupt block's size for kdbfchk -d <offset> <size>. But -L will pick up lots of spurious data; determing the true next valid header is difficult (try printing each with kdbfchk -p until no error results). Also, the corruption may not end there anyway.

Since the corruption is 23GB into a 25GB table, an easier method might be to truncate the corruption and re-append the remaining valid data, if it's possible with your dataset (ie. it's linearly import in table order from its source). You could copydbf the existing table to truncate the corruption (you can copydbf onto itself if your Texis is July 2001 or later, to save temp space), then append. Make sure to drop and re-make all indexes.