Subject | Re: [firebird-support] Re: corrupted database |
---|---|
Author | Helen Borrie |
Post date | 2005-11-29T03:31:34Z |
At 11:15 PM 28/11/2005 +0000, you wrote:
would be a dying hard disk, especially if you're not in the habit of
scanning your hard disks for danger signs. Such things should not be
neglected on a filesystem that stores databases.
tool that Borland ditched years ago, though it still works, even with
Firebird. You can search the IBPhoenix site for the resurrected user
documentation for QLI but, even with that, it's going to anything but the
quick fix you seem to be looking for.
You're probably going to need professional help to recover this database,
since you appear to have gone past the point of logical repair . I hope
you've got a recent backup as it will help a lot with the reconstruction.
Keep the corrupted database on ice and work ONLY with copies. It's a
relatively good sign that gfix and gbak can actually connect to the
database copies. Go to IBSurgeon and get the free analysis tool, which may
be able to pinpoint exactly which page is corrupt. (Pages come in
different "types"; if the page happens to be an index page, the cure might
be something as simple as dropping an offending index...)
IBSurgeon's developer watches this list, as does Ann Harrison. Both have
lots of experience working out what's going on when a DB gets
corrupted. Keep watching the list - one or both will have the antenna up
for the word "corrupt".
./heLen
>Thanks Helen for the link. I don't know how this corruption occurred....and you had Foreced Writes turned off? If not, a more likely cause
> One day it was running fine on my server, and next thing it stopped
>working. I certainly didn't touch the server in any way. I can only
>think it was because the hard drive had only a few hundred MBs free.
would be a dying hard disk, especially if you're not in the habit of
scanning your hard disks for danger signs. Such things should not be
neglected on a filesystem that stores databases.
>Anyway, I tried the link you gave me by Paul Beach, and got stuck.IMO, you are out of your depth. QLI is an old InterBase command-line query
>
>gfix failed, and so I moved to step 6. gbak also failed complaining
>that a page was of the wrong type.
>
>So, now I'm on step 10.2. I've edited the get_tables.sql file to
>point to my file, but I'm not clear on how I execute this file. I've
>never used these command line utilities before, and am not sure what
>he is writing about regarding an output file.
tool that Borland ditched years ago, though it still works, even with
Firebird. You can search the IBPhoenix site for the resurrected user
documentation for QLI but, even with that, it's going to anything but the
quick fix you seem to be looking for.
You're probably going to need professional help to recover this database,
since you appear to have gone past the point of logical repair . I hope
you've got a recent backup as it will help a lot with the reconstruction.
Keep the corrupted database on ice and work ONLY with copies. It's a
relatively good sign that gfix and gbak can actually connect to the
database copies. Go to IBSurgeon and get the free analysis tool, which may
be able to pinpoint exactly which page is corrupt. (Pages come in
different "types"; if the page happens to be an index page, the cure might
be something as simple as dropping an offending index...)
IBSurgeon's developer watches this list, as does Ann Harrison. Both have
lots of experience working out what's going on when a DB gets
corrupted. Keep watching the list - one or both will have the antenna up
for the word "corrupt".
./heLen