At 01:25 AM 1/03/2003 +1100, you wrote:

>when you say yes helen, surely you do not mean that the remaing gdb file has
>had garbage removed. The option of garbage collection only removes garbage
>from the gbk file which is created... No?

Do I answer Yes or No to this double-triple negative? Garbage collection
of the *live* database will be performed if the -g switch is not used.

>So if you do not collect garbage, the gbk file created from a backup
>CONTAINS garbage but will backup faster than when garbage is removed.

No, a freshly restored database contains no garbage. Gbak is not an
image-copying process that stores any structured data. It takes the
database apart and stores what it needs for the restore in a compressed
text format. First, it saves the metadata descriptions, then it saves the
data (but not in tables). Effectively, it "leaves the garbage behind". On
restore, it uses something like a "DDL script" to rebuild the
metadata; then it pumps in the data; adds constraints and recompiles code
modules. Lastly, it rebuilds all indexes that were backed up as active.

>In the latter case, the gbk file will be smaller.

In all cases the gbk file will be smaller (than the database). It simply
doesn't contain the objects that a database contains.

>Also, when garbage is removed and thus a smaller gbk file is created, the
>restore process is faster (a little)

No. The restore process will take as long as it takes to restore all of
the database objects. It never restores obsolete record versions (which is
what garbage is) because it never saves obsolete record versions. And
because gbak doesn't save structures, the space occupied by deleted stuff
is no longer "occupied" - the page-fills will be at their most optimal
after a restore.

Helen