"Jim Starkey" <jas@...> wrote:

>
> >AFAIK, the main problem is in GBAK that will need to manage more
> >dependencies.

Adriano is correct.

> Gbak? Gbak is a backup and restore utilities -- it serializes metadata
> and data in an order than can be readily restored.

Exactly. And a simple default clause referencing UDF (even not considering
selects and procedures) makes a database backup unrestorable. The same issue
exists with computed fields. You may find an example in SF #1047576. So far
the conclusion is that both backup order and restore transaction management
require modifications.

From the top of my head: all metadata containing BLR is globally committed
at the end of the restore process. But relations must be committed in
advance (in order to store data) and IIRC also in different transaction.
When table BLRs (defaults, computed, etc) are parsed, we cannot resolve
references to other stored objects in the cache and get the restore failure.
The known workaround is to use -one_at_a_time switch (which AFAIU commits
metadata step by step), but I'm not 100% sure it works for all cases.

There were suggestions to adjust the backup order to take all possible
interdependencies into account. But I'd better teach GBAK to modify objects
(instead of always storing them) and then separate "physical" table metadata
(the one defining its format) and BLR table metadata. The former would be
committed immediately while BLRs would be added in the context of the global
transaction and committed later (as other objects are processed).


Dmitry