den 2018-04-06 18:08, skrev hvlad@... [firebird-support]:

>
> > Thanks! As a workaround, I attempted gfix -write sync, but alas, it
> will
> > work only if no other attachments. We start the copy at midnight, when
> > it's likely there won't be other connections, but can't be guaranteed.
> >
> > For now, I've added, between lock and copy, a dummy isql script that
> > does a select and commits, and then a 1 hour delay before starting
> copy.
> > But I fear this won't guarantee that the flush happens before copy
> starts.
>
> > While waiting for a fix(?) I'd appreaciate other suggestions how to
> > force that flush to happen sooner.
>
> How often Firebird flushes database is ruled by two configuration
> parameters:
> MaxUnflushedWrites and MaxUnflushedWriteTime. Also, note - for database
> with ForcedWrites = ON there is no explicit flush at all.
>
> I've made a quick look at FastCopy source code and found that if
> "Nonstop"
> checkbox is checked - it will ignore changed timestamp of source file
> (while
> still should react on real copy errors).
>
> Or, you may want to disable updating of "modify file" timestamp at OS
> level -
> this is often used at Windows servers to reduce IO load.
>
> Hope it helps,
> Vlad
>

Many thanks for your efforts. I have force writes off (gfix -write
async). I realize that forced writes on might solve the problem, but I'm
not sure we will get acceptable performance in that mode. Might give it
a try though.

I had the flush params commented out = set to defaults.
Now trying with:
MaxUnflushedWrites = 1000
MaxUnflushedWriteTime = 300

I assume that should imply that a delay of 300 seconds (5 min) after
NBACKUP -L should be sufficient. Will try with ten minutes.

I'm reluctant to use a script/mode/setting that essentially ignores the
flush and copies anyway. I assume this would imply a risk of a corrupt
copy. If not, please explain why.

Regards,
Kjell