Thanks for your reply, and for the abundant explanations!

Ann W. Harrison wrote:<>

>>The reason I would like to understand this more fully, is because I'm
>>wondering how it would be possible to make FireBird 100%
>>corruption-proof. In other words, how can we make every single disk
>>operation atomic?
>>
>>
>
>It is. That's what careful write is about. And we have it.
>
>

Sorry, but what exactly is a careful write? Is that what you were
describing above. Besides, FireBird isn't 100% corruption-proof, so...

>> Naturally, there is already a degree of atomicity due
>>to the transaction system, but what would be good, would be to make
>>every single write atomic; that is, if it gets cut off in the middle,
>>have some flag somewhere, or something that can tell us that the write
>>wasn't completed, and that it can therefore be treated as though nothing
>>had happened at all.
>>
>>
>
>That's the way it works, with the single exception that a partial page
>write is would be a problem. But they don't occur.
>
>
>
>
>>For instance, if I perform several inserts into a table of my database,
>>within the scope of my transaction, these inserts are atomically grouped
>>together, and I either commit them all, or roll them all back.
>>
>>
>
>Right. Database 101. ACID and all that.
>
>
>
>>Therefore, if the client disconnects abruptly after the first insert,
>>everything will get neatly rolled back. However, if, during one of the
>>inserts, there's a power failure, the record will only partially be
>>written to disk, resulting in an incorrect structure, worse than if
>>nothing had been written at all. We need to have a way of telling that a
>>certain operation was not completed successfully, and can therefore be
>>discarded.
>>
>>
>
>The worst that happens is that you get some orphaned back versions, no in
>use. Or if the problem happens in some structural area, you may get an
>orphaned page. Anything else is a bug. Plain, simple, ugly bug.
>
>
>

Well, in that case, what is corruption due to? Why can the database
sometimes get corrupted upon power failure or system crash? It may not
happen often, and it may not be likely to happen, but it does happen...

>>Of course, I also know that there is an option called ForcedWrites,
>>
>>which, if it is used (which of course, it is on all my databases), makes
>>the database perform synchronous writes instead of asynchronous writes.
>>
>>
>
>Unless the database can determine the order in which pages are written,
>careful write is impossible.
>
>
>
>>This helps a lot of course, because it greatly reduces the likelyhood of
>>there being unwritten data pending in the event of an abrupt shutdown.
>>However, it's not good enough in many cases. It's still theoretically
>>possible to have corruption due to a power failure.
>>
>>
>
>Oh yeah? Under whose theory? (Ann, dear, calm yourself.) Where have you
>found errors in the theory or practice of careful write?
>
>
>

I don't understand why you're getting upset. I'm not pretending to have
understood everything, nor am I claiming that I have found errors in
FireBird. As I said, I don't know precisely what you mean by "careful
write", and of course I haven't found errors in its theory.

I'm not talking about the theory of "careful write", I'm talking about
the practice of database corruption. I don't know exactly what it's due
to, and I was just imagining what might be the cause. If the cause I
suggested is not actually the real cause, that still doesn't mean that
the problem doesn't exist.

>> Also, a badly coded
>>SP of trigger can make the database to loop indefinately. In such an
>>event (I've had this happen to me), the only solution is to kill the
>>server process (killing the client isn't enough).
>>
>>
>
>Sure. The server dies, the server is reborn, long live the server. And
>the database. (Ann, dear, you're really not doing much of a job of calming
>yourself.)
>
>

What do you mean by this?

>> If the SP was
>>performing database writes, and not mere reads, it's very likely to
>>corrupt the database, for obvious reasons (this is what happened in my
>>case). And of course, there are other ways of corruption a DB as well.
>>
>>
>
>Obvious to whom?
>
>

To me of course. If it's not obvious to you, then my assumptions must
have been wrong. But that doesn't make the problem disappear. It just
means that we don't know why it happened.

>>And if so, would this entirely
>>solve the problem, or am I missing something. It seems to me that in
>>such a case, we could even afford to turn ForcedWrites off, without it
>>affecting the stability of the database at all.
>>
>>
>
>No. Inter-page dependencies are a fact of life. By avoiding loops in the
>dependency graph, you can establish an order of page writes that will never
>create a dangling dependency. But if you let the operating system choose
>the order of page writes all bets are off.
>
>

Well, I guess my understanding of the structure is lacking, because I
can't quite follow the above reasoning. I'll look up the documents you
refered to, and perhaps I'll see things more clearly.

Anyway, if the structure is such that it makes this sort of thing
impossible, couldn't be structure be altered? :-) (I realise of course,
that this is a rather superficial way of putting it, and that it's
probably much easier said than done...)

Anyway, thanks for your reply,

Jonathan Neve.


[Non-text portions of this message have been removed]