Re: Do log files demand serialization?

> While I understand how a database can achieve good isolation using
> logging, what I do not understand is how that log can be consistent.
>

I can only give you a partial answer, and that's based on DEC Rdb (now Oracle Rdb)
one of the less well known engines, only about one tenth the market share of Oracle classic.

Rdb keeps two kinds of journals, one to support rollbacks, and one to support rolling forward from a
database backup.

The rollback journal, officially called "Run Unit Journal", and sometimes called the short term journal,
contains all the information needed to undo updates to the database done in the context of one transaction.
If the transaction performs inserts and deletes, that's pretty easy to roll back. Updates contain a before image
of the updated data item (table row segment or index node). On rollback, the RUJ gets used to restore the status quo ante. On commit, the contents of the RUJ become expendable, and the RUJ can be reused for the next transaction begun in the context of the same session.

The roll forward journal, officially called the "After Image Journal", and sometimes called the long term journal, exists to permit a backup copy of the database to be rolled forward. This is like the "redo log", in Oracle classic. This journal tracks changes made to the database, and in the same order that they were made to the database. The issue of serializability is sidestepped neatly here. If the original updates were serializable, then the redoing of them will be serializable as well. This prevents an AIJ from getting all bottlenecked when one transaction remains open for hours, and thousands of other transaction come and go in the meantime.

Now, making updates to the database tables and indexes themselves, in an order that is not strictly serial, but is, in fact serializable, is a whole other topic, with a lot of detail to it. Incidentally, there are levels of isolation that are less isolated than serializable, but serializable is the only level that I understand to even a moderate level. I'm going to leave it at this, for now.

--
Regards,
    David Cressey
    www.dcressey.com
"tj bandrowsky" <tbandrow_at_unitedsoftworks.com> wrote in message
news:52e031b9.0202121030.5ad2235f_at_posting.google.com...


> Oracle, SQL Server, etc, all use transaction logs to preserve


> isolation, and to offer rollback and commit.

>

> While I understand how a database can achieve good isolation using

> logging, what I do not understand is how that log can be consistent.

>

> Assume two kinds of logging scenarios:

>

> A.  the log is written with the "prior" contents of the database

> table.  The active writer directly updates the table.  On rollback,

> the contents of the log are put back into the table.  On commit, the

> log entry is marked as such.  When users want to do a read on an area

> of a table where another transaction may be writing to it, the system

> reads from the log for those users.

>

> B.  the log is written with the "new" contents of the database table.

> The active writer updates the log. On rollback, nothing happens.  On

> commit, the contents of the log are copied into the table.  When

> another reader wants to read where the writer may be writing, the

> contents of the table are returned.

>

> In both cases, a user can read the "old stuff" while another user may

> be writing a newer version.  In both cases, commit and rollback are

> supported.  However, in both cases, it seems that it is necessary to

> serialize access to the transaction log itself.

>

> In fact, I'm not even sure how one would have a commit and rollback

> scheme that does not demand serialized access to a transaction log.

> Is this true in general?  I might, if I have 50 users doing inserts,

> updates, etc, wouldn't Oracle, SQL Server, etc, always have to

> serialize the log?  If so, doesn't the serialization to the log

> ultimately limit its scalability?  Doesn't ACID ultimately mean

> serialization at some point, or I am just completely wrong?

>

> Please let me know.

>

> Thanks!