Hello.

Did you try early creating the DB structure and  changing  "field1
                INTEGER Not Null" to "field1
INTEGER " and after that restore with -REP option?

One or more records could be writing, in someway, in the FBK with a null
value. It happens when a NOT NULL column is created when a table has
records.

Atenciosamente,




Em sex., 29 de mai. de 2020 às 11:59, Rodrigo Gonçalves (JIRA) <
trac...@firebirdsql.org> escreveu:

> GBAK can't restore database due to 'do not recognize table attribute'
> ---------------------------------------------------------------------
>
>                  Key: CORE-6321
>                  URL: http://tracker.firebirdsql.org/browse/CORE-6321
>              Project: Firebird Core
>           Issue Type: Bug
>           Components: GBAK
>     Affects Versions: 3.0.5, 2.5.9
>          Environment: Both Linux (CentOS 6.8 64bit) and Windows
>             Reporter: Rodrigo Gonçalves
>
>
> Dear all,
>
> one of our clients has a large database (around 196GB) and the disk where
> it was hosted has crashed (without change of recovery).
>
> Thankfully they had a backup (made with with gbak) but did not perform a
> restore to check the integrity of the backup, thus we have only the FBK
> file.
>
> Now they are trying to restore the database but the following error
> appears at about 80GB of data restored:
>
> gbak:do not recognize table attribute 0 -- continuing
> gbak:do not recognize table attribute 0 -- continuing
> gbak:do not recognize table attribute 0 -- continuing
>
> Trying to restore just the metadata, for testing, results in the same
> error.
>
> This happens at a table with the following structure:
>
> SQL> show table table_name;
> field1                          INTEGER Not Null
> field2                         INTEGER Nullable DEFAULT NULL
> field3                         INTEGER Nullable DEFAULT NULL
> field4                         CHAR(40) Nullable DEFAULT NULL
> field5                         BLOB segment 80, subtype BINARY CHARACTER
> SET NONE Nullable DEFAULT NULL
> field6                         BLOB segment 80, subtype BINARY CHARACTER
> SET NONE Nullable DEFAULT NULL
> field7                         INTEGER Nullable
> field8                         INTEGER Nullable
> field9                         INTEGER Nullable
> field10                         INTEGER Nullable
>
> After trying all gbak standard options, while looking at its source code
> I've found the "SKIP_BAD_DATA" option to try. I've tried it using both a
> large number (16384) and a small number (1) with no success. Is there a way
> to find out the possible numbers to try?
>
> The command used was:
>
> /opt/firebird/bin/gbak -REP -K -N -I -r -v -p 16384  backup.GBK
> database.FDB -user sysdba -pass masterkey
>
> Also, I've tried finding some documentation regarding the FBK/GBK file
> format, so that we could build a tool to extract the data manually and pump
> it to a clean database. But did not find any documentation. Is it available
> online somewhere?
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://tracker.firebirdsql.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
>
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to