Steve,

> I've looked all over for the answer to this, but can't find it.
> There's obviously no parameter to control it, and logically, there
> would be no reason to worry about corruption in a database you're
> RESTORING anyway. (if the power fails or something goes wrong, you
> have to start over whether it's doing synchronous or asynchronous
> writing, so why not do the writes as fast as possible?) So it would
> make sense that it is already doing this, but I'd like to know for
> sure. If it's NOT, it might also be possible to control it - perhaps
> by setting the DB to forced=off before backing it up.
>
> Anyone know the answer to this, or do I need to spend some time
> experimenting?

My review of the GBAK sources, though from a while ago, suggests that
the new database is created with the same characteristics as the
original database, right from the start.

Accordingly, Forced Writes could be set for the entire restore period,
and thus slowdown the restore process.

It would be good suggestion to have all databases initially set as
Forced Writes = OFF, and then as part of the restore
finalization/cleanup to set the Forced Writes = ON (where appropriate).

You should enter this in the project tracker.


Sean