--- In firebird-support@yahoogroups.com, "robertgilland"
<robert_gilland@...> wrote:

>
> > Forced Writes Off is unsafe by definition, you mention that you are
>
> So this means we should never allow forced writes to be off?

Some people do not care about the durability of a given database.
Perhaps they are running batch processes where they can easily
recreate the database if corruption occurs. Obviously they would
prefer it didn't get corrupt, but if it does, it is not a huge problem
for them and they want the 'performance gain' offered by asynchronous
writes.

Other databases must be durable. The information is difficult to
locate or requires manual process to retype everything etc. For those
databases, forced writes really should be enabled. From what I gather,
IB6 used to run with Forced Writes off as a default. With Firebird it
uses Forced Writes on as default (which is safer).

Note that something that in some Windows builds and some versions of
IB/FB, the write cache was not flushed until the service is shutdown,
meaning hours of writes may be stored. (I do not know which version
changed this but I think 1.5 flushes it every few seconds, so you have
to be a bit more unlucky now, it used to be a timebomb).

>
> > using some RC builds but fail to mention the version. FB 1 / 1.5 /
> > 2?? Do you notice a performance gain switching it off?
>
> Firebird 1 Release
> Firebird 1.51 Release
> Firebird 2 Release Candidate 1
> Firebird 2 Release Candidate 2
>

I do mean the question about noticing a significant performance gain.
Now hard drives have their own caching, and pretty soon they will come
with flash based memory cache, which means the improvement may not be
what it was 5 years ago.

> >
> > If Firebird happens to write the data to the data page before
> > populating the index page (is this possible??) and there is a
> problem
> > such as hardware failure before the index is updated then I can see
> > this happenning.
> >
>
> Oh I see, so say for instance. We were using classic and RAM runs out,
> as has happenned quite a lot. this would definitely fail.
>

With forced writes off, you are at the mercy of the OS to save the
data in the right order. When running out of memory, well who knows
what the OS is able to flush.

You need to resolve your problem with classic and RAM, perhaps
reducing your cache sizes so you can support the number of connections
that are made (or increasing the amount of available RAM). When
running out of memory, do you have Virtual memory configured? If so,
it means that your database cache is too big. You should configure
your cache in firebird.conf so that no fb_inet_server process needs to
be paged into virtual memory. This will be a much more significant
boost to performance than any asynchronous writes could ever offer.

>
> > Have you (or someone else) been using a tool like xcopy to move the
> > database around, because I can imagine that can quite easily cause
> > this. Make sure appropriate exceptions are in place in any virus
> > scanning package.
> >
>
> No this has not been happenning.

(Although we find out later that System Restore is taking file system
copies)

> > >
> > > Could this be a firebird bug? If so we do have the the GDB from
> > > example #1 and a GBK from example #4.
> >
> > Rename to gdb to fdb or you will get into trouble in some windows
> > platforms.
>
> Can you be more clear as to what trouble we would get into?

System Restore will take a backup when you first connect to your
database. For small databases, it is not too noticable, but for larger
databases there is a significant delay for the first connection and a
lot of hard disk activity.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sr/sr/monitored_file_extensions.asp

Adam