Subject | How to locate and delete records connected to a bad sectors ? |
---|---|
Author | stephane |
Post date | 2012-11-01T08:49:23Z |
Hello,
On our database (FB 2.5) of 150 GB we have 21 bad sectors of 512 bytes (all in the same block). because of that the backup/restore not work (even with the -ignore option). And gfix not help us too much because it's freeze and crash the fb_inet_server (but it's was also the case before the bad sectors problem, so it's a bug in gfix i guess).
Now i need to know with table/records are involved in the 21 bad sectors and how to delete them. I already locate one table involved (and successfully drop it, it's was not a very important table), but their is also another table involved that i need and can't drop it. so i locate exactly the record ID in error (by doing select until error appear) and try to delete them but without success because engine answer me :
Statement failed, SQLSTATE = XX001
database file appears corrupt ()
-bad checksum
-checksum error on database page 7456994
what are now my option ?
i thing of manually update the checksum (by 12345) on the database page 7456994 (and the page type too), but i hope their is a more convenient way than hex edit my database ?
another problem from reading Ann articles :
"Here's the full scoop on checksums. Once upon a
time, in a cute little town called Groton, there was a database and
to be extra safe, it computed a checksum of every page just before
it wrote the page to disk,and wrote the checksum in the page header.
Immediately after it read the page, it computed the checksum again,
and if the stored checksum didn't match the computed checksum it
produced an error. The error almost never occurred, and when it did occur, the stored checksum was zero, and so was every other byte on the page. Then the database moved to a lovely town in California called Santa Cruz, where it had different friends who took care of it. Those friends were looking for ways to make the database faster and their tests showed that the database was spending a lot of time (5-10%) computing checksums. So, they said, OK, 12345 is different from zero, so we'll still catch the same errors, but we won't waste time computing something that never fails."
it's mean that engine report error only if the checksums is different from 12345 (and i imagine the checksums is written only on the page header not on every disk sector of 512 bytes). as my page header is 8kb and my bad sectors is only 512 bytes, what happen if the page header is not on a bad sector (so page will return good checksum) BUT the the page content contain bad sector ??
thanks by advance
stéphane
On our database (FB 2.5) of 150 GB we have 21 bad sectors of 512 bytes (all in the same block). because of that the backup/restore not work (even with the -ignore option). And gfix not help us too much because it's freeze and crash the fb_inet_server (but it's was also the case before the bad sectors problem, so it's a bug in gfix i guess).
Now i need to know with table/records are involved in the 21 bad sectors and how to delete them. I already locate one table involved (and successfully drop it, it's was not a very important table), but their is also another table involved that i need and can't drop it. so i locate exactly the record ID in error (by doing select until error appear) and try to delete them but without success because engine answer me :
Statement failed, SQLSTATE = XX001
database file appears corrupt ()
-bad checksum
-checksum error on database page 7456994
what are now my option ?
i thing of manually update the checksum (by 12345) on the database page 7456994 (and the page type too), but i hope their is a more convenient way than hex edit my database ?
another problem from reading Ann articles :
"Here's the full scoop on checksums. Once upon a
time, in a cute little town called Groton, there was a database and
to be extra safe, it computed a checksum of every page just before
it wrote the page to disk,and wrote the checksum in the page header.
Immediately after it read the page, it computed the checksum again,
and if the stored checksum didn't match the computed checksum it
produced an error. The error almost never occurred, and when it did occur, the stored checksum was zero, and so was every other byte on the page. Then the database moved to a lovely town in California called Santa Cruz, where it had different friends who took care of it. Those friends were looking for ways to make the database faster and their tests showed that the database was spending a lot of time (5-10%) computing checksums. So, they said, OK, 12345 is different from zero, so we'll still catch the same errors, but we won't waste time computing something that never fails."
it's mean that engine report error only if the checksums is different from 12345 (and i imagine the checksums is written only on the page header not on every disk sector of 512 bytes). as my page header is 8kb and my bad sectors is only 512 bytes, what happen if the page header is not on a bad sector (so page will return good checksum) BUT the the page content contain bad sector ??
thanks by advance
stéphane