corrupt blocks

Post Reply
MiniMe
Posts: 210
Joined: Thu Mar 15, 2001 4:30 pm

corrupt blocks

Post by MiniMe »

I am trying to track down some corrupt blocks in a rather large table. I prefer to not have to do the entire table copy, drop and scan routine as this table has 20+ indexes on it and over 30 million rows. Time is not a luxury here. So I ran a kdbfchk on it and told it to save the bad blocks info to a file. How do I tell which ones I should delete and which ones I can leave alone as there are a variety of comments in the output from Free orphaned block truncated away to Free block was marked allocated in header.
User avatar
Kai
Site Admin
Posts: 1272
Joined: Tue Apr 25, 2000 1:27 pm

corrupt blocks

Post by Kai »

If you let kdbfchk output a fixed table with -o, existing indexes are usually still compatible with it (ie. you can copy the fixed table over the original without dropping and re-making indexes). Then you don't have to manually delete individual blocks, and the table will be writable.

If you want to just delete individual blocks quickly, ignore any messages about free blocks/pages and just delete allocated or other blocks. You'll still need to run kdbfchk -q on the table so the free tree is cut off and re-started; otherwise any mods to the table will hit the bad free blocks again (manually deleting those still leaves a corrupted tree).
MiniMe
Posts: 210
Joined: Thu Mar 15, 2001 4:30 pm

corrupt blocks

Post by MiniMe »

I have a bad block list of 1329 blocks.. Is there an easy way to feed this back in kdbfchk to delete them?? Also here is the summary.

2 underfull free-tree pages found
1291 bad free block headers found
27 free blocks truncated
170997 orphaned free blocks found
16609 orphaned free-tree pages found
4 free block pads inserted
User avatar
Kai
Site Admin
Posts: 1272
Joined: Tue Apr 25, 2000 1:27 pm

corrupt blocks

Post by Kai »

There's no automated way to pipe the list back into kdbfchk.

Since all the errors appear to be free-tree related, you coould just use kdbfchk -q -O (runs instantly) to start a new free-tree on the table, and you should be all set. (This assumes the indexes are not corrupted.) The bad free-tree blocks would just be orphaned (lost) space in the table, not accessed again.
Post Reply