Subject | Re: [firebird-support] Re: Gbak utility |
---|---|
Author | Ann W. Harrison |
Post date | 2010-08-16T18:21:59Z |
paulfirebird@... wrote:
thread appears to have started at the end of January which is even
longer than my average mental vacation, but ...
If I remember, you're creating backups that you can distribute.
And maybe you want to distribute them on different platforms, you
you really need to use a gbak backup rather than a compressed
database - though I would use a compressed database at the cost
of having to make several kits, or have logic in the installation
to determine the nature of the target and use the appropriate
compressed database. Anyway, I'm assuming that you'll fill
the database once, backup it up once, and restore it one time
per installation. So your customer sees one 6 hour restore, not
the original load and index creation.
If by any chance you're loading, backing up, and restoring all
on the customer site, stop it! The load and index creation is
all you need to do ... or for additional security, backup the
database once it's loaded to test the backup procedure.
Cheers,
Ann
>Maybe I've missed something while I was on vacation ... though this
>>>> To summarize:
>>>> Fill database
>>>> Set index (takes about 6 hours)
>>>> Create backup (which removes index)
>>>> Create database from backup (which adds the index, again 6 hours)
>>>> So the index is created twice.
>>>> Is there a way to improve this? F.e. by putting a inactive index in
>>>> the database that gets activated at the create database from backup?
> Does anyone have an idea/solution for this?
thread appears to have started at the end of January which is even
longer than my average mental vacation, but ...
If I remember, you're creating backups that you can distribute.
And maybe you want to distribute them on different platforms, you
you really need to use a gbak backup rather than a compressed
database - though I would use a compressed database at the cost
of having to make several kits, or have logic in the installation
to determine the nature of the target and use the appropriate
compressed database. Anyway, I'm assuming that you'll fill
the database once, backup it up once, and restore it one time
per installation. So your customer sees one 6 hour restore, not
the original load and index creation.
If by any chance you're loading, backing up, and restoring all
on the customer site, stop it! The load and index creation is
all you need to do ... or for additional security, backup the
database once it's loaded to test the backup procedure.
Cheers,
Ann