Thanks Philip, those are interesting thoughts.

It would seem to me that a) is not so important (OK... one might lose
the speed advantage if the sort file was also being held in
persistent storage). I guess it might be more of a problem if the
ramdrive held both db & sort files, and it ran out of space...

Your second point looks much more important. But I would think that
any commit that happens at the time that a server crashes is to be
considered questionable. For instance, if one is using asynchronous
writes, then any data in the cache would be lost if there is a server
crash. Obviously, if one just reset the OS gracefully (or downed the
Firebird server process) the file system cache would be written out
to disk.

I imagine that what you are suggesting is also a potential problem
with any two-phase commit, or with the workings of the Firebird
shadow system per se e.g. what if both primary db and shadow are
being held on persistent drives, and the shadow drive is slower. If
there's a crash at commit time, then the shadow db may not be updated.

Given that in my scenario on an OS reset the primary db is just not
there any more, it is not an issue that the primary and the shadow
are not consistent. In fact, in my scenario I think the data is
likely to have more guarantee of consistency; the primary and the
shadow cannot be inconsistent if the primary no longer exists.
However, in the scenario where they are both on persistent media, and
there is a crash before the shadow is updated, then the primary and
shadow could be inconsistent.

I'm assuming that the Firebird shadow process is nothing more than a
two-phase commit. Hopefully, someone with more knowledge about these
things will step in and enlighten me. This would guarantee the
consistency of primary and shadow in all circumstances.

I think maybe I've not even understood the importance of your second
point. Please elaborate if I seem a bit dense!

I forgot to mention where I found the ramdrive software (my test
machine is running XP, but they have many variants for win32 at this
site):
http://www.cenatak.com

My understanding is that the facilities to use ramdrive filesystems
are built into Linux.

I'd be really interested to hear if you see the same kinds of
performance gains I mention.

Regards,
Bernard



--- In firebird-support@yahoogroups.com, "unordained"
<unordained_00@c...> wrote:

> Bernard: random comments (i'm just a firebird user) --
>
> a) watch out for the sort file. i've noticed rather large files

in /tmp/ on my linux box (hey, the

> query wasn't done yet, okay?) and you'd want -that- in memory too,

so unix sort can run quickly on

> it. maybe. (assuming new versions of firebird still do this ... i'm

lost somewhere in the past.)

>
> b) just hope the shadow file is required to finish committing

entirely to disk before commit()

> returns successfully. you'd hate to have transactions lost in lala

land because your RAM instantly

> said it worked, right before the machine crashed. (again, i dunno

what i'm talking about.)

>