Subject | Re: --* Please Help*--- Database corruption and cannot backup & restore |
---|---|
Author | Alexander V.Nevsky |
Post date | 2001-08-08T13:33:04Z |
--- In ib-support@y..., Louis van Alphen <lja@b...> wrote:
database or while doing backup or restore or on restored database. You
can find fine article about database repair at
http://www.ibphoenix.com/ibp_db_corr.htm
If 'decompression overran buffer (179)' is on damaged database and it
is the only problem, from my own experince:
1. Be shure you have file copy
2. gfix -v -f
3. gfix -m -f - you can lost some data at this point
4. gbak (backup) with -ig -g options
5. gbak (restore) with -v option into ANOTHER file
if 5 fail you will have information why. If so, connect to source
database, find (try to build select to no use indexes) and delete
damaged records, goto 4. Dependent on kind of problems on step 5 you
can be forced to use some other restore options: -o -n -i (See
Operations Guide - DataBase Backup and Restore - gbak command-line
tool - restoring a database) and find broken constraints/unique
indexes in destination database or delete some records in source one
and make loop backup-restore.
Sorry, my English don't allow me to give more detailed advice.
Good luck.
> I have DDL scripts and SP sources, but a lot of the application isactual
> data including blobs, which is a problem. We have fixed a few thingsand
> could do a backup & restore, but still get an abnormal servertermination
> with the problem being the old 'gds consistency check' problem dueto
> 'decompression overran buffer (179)'.Hi, Louis. I'm rather confused - do you get this message on damaged
>
database or while doing backup or restore or on restored database. You
can find fine article about database repair at
http://www.ibphoenix.com/ibp_db_corr.htm
If 'decompression overran buffer (179)' is on damaged database and it
is the only problem, from my own experince:
1. Be shure you have file copy
2. gfix -v -f
3. gfix -m -f - you can lost some data at this point
4. gbak (backup) with -ig -g options
5. gbak (restore) with -v option into ANOTHER file
if 5 fail you will have information why. If so, connect to source
database, find (try to build select to no use indexes) and delete
damaged records, goto 4. Dependent on kind of problems on step 5 you
can be forced to use some other restore options: -o -n -i (See
Operations Guide - DataBase Backup and Restore - gbak command-line
tool - restoring a database) and find broken constraints/unique
indexes in destination database or delete some records in source one
and make loop backup-restore.
Sorry, my English don't allow me to give more detailed advice.
Good luck.