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) <
[email protected]> 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
