Subject | Re: [firebird-support] URGENT : Corrupt Firebird dabase |
---|---|
Author | Alexey Kovyazin |
Post date | 2013-01-23T11:30:39Z |
Gary,
I don't think this is good set of options
-c means create database from backup
-r means replace existing file. This is dangerous option, but if you
specify it, you don't need to specify -c
-k restore without creating shadows. Useful for those who use shadows.
-Bu 10000 -sets 10000 page buffers. It will be very bad for Classic.
-p 8192 specifies page size to 8192. Some people prefer bigger or
smaller page sizes.
gbak -c -v will preserve current settings and lead to the less potential
problems.
Regards,
Alexey Kovyazin
IBSurgeon
>gbak.exe -user SYSDBA -password masterkey -c -R -K -BU 10000 -P 8192 -vc:\data\yourdb.bak c:\data\yourdb.gdb
I don't think this is good set of options
-c means create database from backup
-r means replace existing file. This is dangerous option, but if you
specify it, you don't need to specify -c
-k restore without creating shadows. Useful for those who use shadows.
-Bu 10000 -sets 10000 page buffers. It will be very bad for Classic.
-p 8192 specifies page size to 8192. Some people prefer bigger or
smaller page sizes.
gbak -c -v will preserve current settings and lead to the less potential
problems.
Regards,
Alexey Kovyazin
IBSurgeon
> This works for me:[Non-text portions of this message have been removed]
>
> gfix.exe -user SYSDBA -password masterkey -m -f -ignore c:\data\yourdb.gdb
> gbak.exe -user SYSDBA -password masterkey -b -v -limbo -ignore -garbage
> c:\data\yourdb.gdb c:\data\yourdb.bak
> ren c:\data\yourdb.gdb c:\data\yourdb_corrupt.gdb
> gbak.exe -user SYSDBA -password masterkey -c -R -K -BU 10000 -P 8192 -v
> c:\data\yourdb.bak c:\data\yourdb.gdb
>
> Regards
> Gary
>
> On 1/22/2013 11:19 PM, rddymanohar wrote:
> >
> > Hi,
> >
> > One of our clients has a corrupted database (we are getting internal
> > gds error). Its a Firebird Database version 1.5.6, the files size is
> > almost 7.5GB, we are unable to recover it with the normal tools, we
> > have run the Repair procedure in IBFIRST aid and followed the
> > recommended steps following that, using GFIX and GBAK command lines.
> > Backup fails with the following error on a table
> > gbak: ERROR: Internal gds software consistency check (wrong record
> > length (183))
> > gbak: ERROR: gds_$receive failed
> >
> > We are not able to even delete the table or its data to continue with
> > the backup.
> >
> > The client is down for the last one day. I would really appreciate if
> > any one can help me in find a way to get this database up and running.
> >
> > Thanks
> >
> >
>
> [Non-text portions of this message have been removed]
>
>