den 2018-04-06 18:08, skrev hv...@users.sourceforge.net [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
