Subject | Re: "Corrupt" FDB |
---|---|
Author | s3057043 |
Post date | 2013-02-26T04:36:37Z |
Hello All,
I have solved this problem. Details of how to solve this below in case anyone else encounters this:
Step 0: Have a copy of the FDB stored safely (as always for DB repairs).
Step 1: Use gfix -mode read_only ....... to make the DB read-only.
Step 2: Now gbak works, make a backup
Step 3: Restore that backup (to a different name FDB!)
Step 4: Use gfix -mode read_write ....... to make the newly restored DB writeable again.
Thanks anyhow.
Adam
I have solved this problem. Details of how to solve this below in case anyone else encounters this:
Step 0: Have a copy of the FDB stored safely (as always for DB repairs).
Step 1: Use gfix -mode read_only ....... to make the DB read-only.
Step 2: Now gbak works, make a backup
Step 3: Restore that backup (to a different name FDB!)
Step 4: Use gfix -mode read_write ....... to make the newly restored DB writeable again.
Thanks anyhow.
Adam
--- In firebird-support@yahoogroups.com, "s3057043" <s3057043@...> wrote:
>
> Hello Group,
>
> I have been passed on a database to review which appears to be corrupted.
>
> It is running win 2008 R2 and Firebird 2.5.
>
> I was passed the raw FDB file after Firebird was stopped (and the FDB renamed)
>
> When I try to run gbak, I receive the following error:
>
> Backup started at 26/02/2013 1:54:54 PM
> gbak:creating file C:\Test\test.fbk
> gbak:starting transaction
> gbak: ERROR:invalid transaction handle (expecting explicit transaction start)
> gbak:Exiting before completion due to errors
> Backup failed!
>
> There are no messages in Firebird.log
>
> I tried to run gfix (with -v and -full options). gfix ran without error (but the backup still fails).
>
> I then ran gstat -h and got the following output:
>
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 2150891499
> Page size 4096
> ODS version 11.2
> Oldest transaction 2147483644
> Oldest active 2147483645
> Oldest snapshot 2147483645
> Next transaction 2147483646
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 3407803
> Implementation ID 16
> Shadow count 0
> Page buffers 0
> Next header page 0
> Database dialect 3
> Creation date Dec 15, 2011 14:37:36
> Attributes force write
>
> Variable header data:
> Sweep interval: 20000
> *END*
>
> Those transaction IDs look suspiciously close to 2^32. Could this be the problem? If so, is there a way to fix this?
>
> If I have not provided necessary information, please let me know and I will try and get some clarity.
>
> Thanks in advance.
>
> Adam
>