Exchange transactions - I'm confused!

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Based on some E2003 DR experimentation, I'm having some confusion as to
what happens when the transaction logs are spontaneously lost in a live
database (e.g. disk controller failure). I'm assuming that:

1. Transactions happen in memory and the transactions are immediately
logged in the transaction logs sequentially.
2. The changed pages remain cached in memory.
3. When the server is "idle", the pages are commited to the database
_from memory_ (unless the database gets too far behind in which case
the transaction logs have to be read?). The checkpoint file records
which transactions were committed.
4. The open database is permamently marked dirty unless it undergoes a
clean shutdown.
5. After transactions are commited, the jet database integrity is
intact (i.e. no bad jet links and so on).

Question 1: (this is more idle curiosity than affecting the main thrust
of my questions below): does Exchange literally commit the transactions
in the order they happened, or does it simply dump all the dirty pages
currently in memory without regard to the individual transactions
themselves?

When testing, what I've noticed is that if I spontaneously destroy the
logs (but leave the database and checkpoint file available) on a low
load server, the database shuts down leaving it with numerous bad links
between the jet pages (I'm assuming it goes into panic mode!). I'm not
simply talking here about the dirty flag in the header, I'm talking
about the actual integrity of the database itself. I find this puzzling
behaviour because even if the logs are lost, the transactions are still
present in memory and so I can't see a reason why those transactions
can't be committed from memory just before the database is dismounted
leaving the database integrity intact. (Again, I'm not talking here
about the clean / dirty flag in the header - I'd expect that flag still
to say "dirty".) So...

Question 2: In the event of loss of transactions, why does Exchange not
commit the transactions just before bailing out? (OK, on a heavy load
where it's got so far behind the transactions that the uncommitted
transactions are no longer in memory, I can understand, but I'm talking
here about a low load server.)

A consequence of this is that even if all the best practices are
followed, Exchange can still end up corrupted (requiring an eseutil /p
and so on) with consequent loss of data and of course restoring from
last nights backup can lose a whole day's data. Or have I misunderstood
something fundamental?

TIA
Mark

.

Relevant Pages

  • Re: Do Transactions guard against corruption?
    ... when the database is opened and closed. ... meant by 'corruption'. ... Transactions have NEVER been designed as safeguard for those previous ... not used by Access to protect the structure of the database. ...
    (microsoft.public.access.modulesdaovba)
  • Re: Do Transactions guard against corruption?
    ... Have you ever had a database in a 'suspect' state? ... meant by 'corruption'. ... Transactions have NEVER been designed as safeguard for those previous ... not used by Access to protect the structure of the database. ...
    (microsoft.public.access.modulesdaovba)
  • Re: Portents of VMS death
    ... "HP NonStop servers are at the top of the single-system ... databases for each primary database or a single backup for multiple ... no matter how many transactions per second your application ... processing can continue using the backup database with minimal service ...
    (comp.os.vms)
  • Re: Do Transactions guard against corruption?
    ... the last user disconnects. ... Have you ever had a database in a 'suspect' state? ... meant by 'corruption'. ... Transactions have NEVER been designed as safeguard for those previous ...
    (microsoft.public.access.modulesdaovba)
  • Re: Do Transactions guard against corruption?
    ... Have you ever had a database in a 'suspect' state? ... meant by 'corruption'. ... Transactions have NEVER been designed as safeguard for those previous ... not used by Access to protect the structure of the database. ...
    (microsoft.public.access.modulesdaovba)