""Ing. Helmut Neureiter"" <sales@...> wrote in message
news:MEEAJJNKCJEPMLOPGJFKCECMCAAA.sales@......

> Trying to restore a database on Linux Redhat 6.2 we can see the

restoration

> of all table - structures and gbak starts to restore the first and biggest
> table (images in blob) after about 1.7 gbyte the data - restauration stops
> and we get the infinite message
> "gbak: do not recognize table attribute 0 -- continuing"
> this message seems to run for ever.
> If we cancel with ctrl c the tablestructures exist but no data are in.
> Does anyone know a solution?

Hi, Helmut, it won't help you much, but here are the places that may throw
this error in gbak while restoring:

- get_relation() is a function that writes metadata and data for a given
relation. If it gets a field that doesn't recognize as one that should be
recovered, it says the attribute value it doesn't recognize. Things that are
backed up and restored are for example the relation name, the source if it's
a view, the flags, the system flag, the owner, etc.

- get_relation_data() is a function that only restores data. I'm not 100%
sure if still this and the previous functions are being used to deal with
data. This function only accepts the relation name as an attribute and
complains otherwise. After that, it gets data. I think that this function
was made since data and metadata are no longer kept in the same chunk. It
has a second place where it can complain: once data has been found, it
cycles through it, expecting to find data, a gen_id call, an index, an
old-style trigger and nothing more.

IT WOULD BE FINE IF THOSE FUNCTIONS REPORTED THEIR NAMES WHEN FAILING.

When an error appears, an attempt is made to skip the bad tag and continue
later. However, it seems that either the recovery algorith does't succeed or
it doesn't skip a few bytes. By default, there's an attempt to skip a block.
It may be as small as one byte. There's an undocumented parameter,
-SKIP n
where <n> is the number of bytes to skip when an error happens. Since you
get only zeroes, it seems as if either gbak is stuck always in the same
position or you stepped into a blob or something that's interpreted as only
zeroes. Try to experiment with n being one or two. Trying to sync with the
next attribute by augmenting the skip value should be a tiresome task.
Otherwise, try to restore one table at a time, at least you can get the data
in the other tables prior to the failure.

Do you have the original db that was backed up at hand still? Really, it
seems that either the backup was wrong or there's some special case when
backup and restore go out of sync.

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing