""Henner Kollmann"" <Henner.Kollmann@...> wrote in message
news:000001c1c9a0$26334890$1e5562c1@......

> Hello,
>
> I have a problem with FireBird RC2 using gbak on a large database (1,2
> Gbyte) with a large table (2500000 records).
> When gbak reaches this large table work stops - you only can kill the
> job.
> The interresting thing: This only happens when i use gbak the second
> time in an backup - restore cycle.
>
> So:
> 1. backup works
> 2. restore works.
> 3. backup failed.
>
> Does anybody have an idea?

It seems as if the metadata that was restored causes gbak to go into an
endless cycle the second time. Each time a backup/restore happens, records
may be reordered. Field ID's change, field positions make the table appears
as it was before.

My only suggestion for now is to use gbak -v and watch the output. Is that
the option you already used? You didn't say the platform, but in any OS
should be possible to know if either the engine or gbak is wasting CPU
resources, for example.

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