Helen,

there is one big wrong assumption in your post: there was NOT power
outage in my case. Neither any error, returned by the application or
the DB engine. Just running the application second time I got this
message (after writing many, many records to the DB). Then checked
with isql - the same. The PC never went down, rebooted, crashed or
anything else like this. The DB connection was properly closed. I
said 'supposed' only to discuss such a case - I need to provide a
reliable application, so I explore all cases.

About open-source... I am involved in 3 open source projects, and,
no, this is not free beer. I guess (wrong again?) that open source
software is driven by the will of people to share and provide others
with the fruits of their experience and knowledge. But there is
something totally wrong behind the concept "get the software for
free, but you must pay for support". Of course, there is sometime
need for such support, but even for a DB maintenance?... DB
maintenance should be part of a DB software. From my point of view,
of course.

About Windows... Hey, there are CUSTOMERS and bosses out there - they
decide what to run the software on. If FB doesn't work well on
Windows... well, don't advertise it does so.

I was asking for help and advice. This is what forums and news groups
are for - support and collaboration. Between colleagues and
professionals. Anyway, may be this thread will be useful for me from
another perspective.

BTW: Is Force Writes enabled by default? I never changed this option.

Cheers (with a beer, yes! :) )

Kiril.


--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> 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