At 01:08 AM 12/03/2005 +0000, you wrote:

>Well,
>
>thanks and.. excuse me for insisting on this:
>Is it true that if I don't get the paid support from the site you
>mention, there is no tool that can help me recover the database?..

That is true. The IBFirstAid tool can be quite helpful in finding the
places affected by this type of corruption, though.

>If so, the whole idea of open source and free DB solution is
>meaningless..

How do *you* define "open source"?

What does "free" mean to you? Free beer for everyone? A world full of
volunteers just waiting to rescue you, at no cost, from the messes that you
got yourself into by ignoring advice?

>Forced writes are may be secure and ensure data consistency in such
>cases,

Not "maybe" - disabling forced writes on any Windows platform is
hari-kari. Data consistency happens as the result of writes to the
database. If you insist on allowing the Windows operating system to decide
when or IF these writes occur, then you play Russian Roulette. You'd
better be pretty darned sure that nobody is going to do anything to wipe
out that OS cache by disconnecting the power or corrupting the server's memory.

If you keep FW on, then control of the database disk state is where it
should be: the server engine decides when it needs a page written to
disk. The worst that happens then, when a power abruption happens, is that
a page that was being written to was lost. Gfix will find this kind of
corruption and will be able to restore your database to a usable state.

>but you pay in performance.

That's a delusion. Some tasks might go faster if FW are disabled
temporarily; but all writes must happen eventually. For normal operation,
when hosting the server on Windows, there is no gain in performance that
could hope to outweigh the risk that, sooner or later, Windows OS caching
is gonna burn you. In an environment as precarious as yours, it will be
sooner, rather than later.

>The DB should be capable to
>recover valid records and inform what records/pages are lost.. Basic
>requirement from a database, I guess...

You guess wrong. The DB cannot recover what it never had. If you prevent
data state changes from being written to the disk, or if you overrule the
database server's control over what gets written and when, then what is
there to recover if you kill the OS cache?

>The physical file is still there. So there MUST be some tool that is
>capable to 'walk' it, analyze and fix - for instance gfix does so
>with the -i option. If the checksum is 'fake', then DBA must be
>capable to decide to rollback the DB to the 'last known safe state'.
>Even for the price of loosing open transactions, but not the ENTIRE
>data.

Which is what *does* happen, if you have not prevented the engine from
doing what it's meant to do. The DBA doesn't have to "decide" anything,
normally. Just flash up and go. Normal GC will take care of uncommitted
work. In the rare instance when some abruption caught the engine in the
middle of a write operation, a page might end up out of whack and the
engine will report a corruption. This kind of corruption can be bypassed
using gfix. But gfix can't detect or fix breakages caused by the OS
failing to write to disk. (Nor can it repair a database where disk surface
damage has occurred since the page was originally written - another very
strong reason to protect the power supply!!)

>Am I wrong assuming that FB doesn't support this? (Hope I am!)

You do seem to be making a lot of wrong assumptions....even if FB had
write-ahead logging (which it doesn't, since it relies on record versioning
technology to ensure a sound fallback state) you are dreaming if you
believe that you can disable database writes AND somehow get log entries,
state changes, or anything, written to disk.

The most faulty of your assumptions is that running a database server with
its disk-write capability switched off is a desirable mode for regular
use. While FW-off is there for temporary use for the odd huge batch job,
it is not recommended for *any* environment that is not power-safe. Under
these conditions, "Absolute power-off corrupts absolutely."

If you have no choice but to run database servers on Windows, and you have
an environment where there is no power backup and people are allowed to go
around pulling plugs on servers, then FORGET about asynchronous writes.

Why point the bone at Windows? Because, by default, Windows NEVER flushes
its cache until the database file is closed. Before Fb 1.5, a 24/7
operation with FW off was a simply a disaster waiting to happen. From Fb
1.5 on, you can configure the frequency with which the OS cache is flushed
and hope that it happens.

Even with this capability, myself, I would not trust a Windows OS to
perform flushes on schedule **until and unless** I had tested and proved
beyond doubt that it would happen according to configuration AND in the
exact operational environment where my databases were being accessed. From
my (often bitter) experience, there are just *too* many things in Windows
that don't work as designed, because of undocumented sensitivities to other
things happening in the OS.

./heLen