| Subject | Re: [firebird-support] Re[2]: OT: Survey about database corruption (for portuguese speakers only) |
|---|---|
| Author | Ann Harrison |
| Post date | 2003-07-10T15:31:22Z |
Yang Jin wrote:
with the IBSurgeon people, I just want to warn you that it's not a
simple problem.
There are three classical ways to corrupt an InterBase database. The
first is to open it on windows using two (or more) different name
strings. That leads to wrong type page errors. The second is to run
without forced writes, again on windows, and without an uninterruptable
power supply. That gives an error like "attempt to read beyond end of
file". The third is to exceed the 4GB limit on file size. That gives an
error like Page 0 is wrong type.
In the first case, you've got to find all the places that reference the
page that was written twice in error and decide how best to handle that
particular case. For example, if you've got something that is a data
page (type 5) but should also be a pointer page (type 4), then you'll
have to rebuild the pointer pages for whatever table had its pointer
page sat on. If the pointer pages sat on a data page, then that data
page must be removed from the table's pointer page. If you've lost a TIP
- type 3 - you'll need to build a new one and put it into the pages
relation and guess the outcome of any transactions registered on that page.
In the second case, you've got pointers to pages that were never
written. One is most likely a TIP so you'll have to reconstruct that,
again guessing the outcome of the lost transactions. For data pages,
you'll have to fix the pointer pages, for pointer pages you'll have to
recreate them from the database. Indexes I never worry about when fixing
up a database - they're easy to rebuild once the data is in place and
can be found.
In the third case, you've probably lost all your metadata information
and possibly bits of blobs. Cleaning up bits of blobs is a major hassle.
In short, more of an art than a science still.
Regards,
Ann
> I agree with the view that loss power make database corrupt.But IHaving built and used such a tool and having exchanged some experiences
> think It is most important to solve the problem by user when the
> database corrupt.
>
> How to restore the normal by user so that they can continual use the application?
>
> A tool is need to use by user to restore the corrupt database.Let's make it.
>
>
with the IBSurgeon people, I just want to warn you that it's not a
simple problem.
There are three classical ways to corrupt an InterBase database. The
first is to open it on windows using two (or more) different name
strings. That leads to wrong type page errors. The second is to run
without forced writes, again on windows, and without an uninterruptable
power supply. That gives an error like "attempt to read beyond end of
file". The third is to exceed the 4GB limit on file size. That gives an
error like Page 0 is wrong type.
In the first case, you've got to find all the places that reference the
page that was written twice in error and decide how best to handle that
particular case. For example, if you've got something that is a data
page (type 5) but should also be a pointer page (type 4), then you'll
have to rebuild the pointer pages for whatever table had its pointer
page sat on. If the pointer pages sat on a data page, then that data
page must be removed from the table's pointer page. If you've lost a TIP
- type 3 - you'll need to build a new one and put it into the pages
relation and guess the outcome of any transactions registered on that page.
In the second case, you've got pointers to pages that were never
written. One is most likely a TIP so you'll have to reconstruct that,
again guessing the outcome of the lost transactions. For data pages,
you'll have to fix the pointer pages, for pointer pages you'll have to
recreate them from the database. Indexes I never worry about when fixing
up a database - they're easy to rebuild once the data is in place and
can be found.
In the third case, you've probably lost all your metadata information
and possibly bits of blobs. Cleaning up bits of blobs is a major hassle.
In short, more of an art than a science still.
Regards,
Ann