HP3000-L Archives

July 2003, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Tue, 8 Jul 2003 17:23:02 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (51 lines)
John writes:
> Well, if you want your databases to be logically consistent after
> a system crash, you'd better use DBBEGIN/DBEND or
> DBXBEGIN/DBXEND.

I believe DBBEGIN and DBEND are NO-OPs unless you have logging enabled, and
then for them to be any use you have to initiate either roll-forward or
roll-back recovery after each system failure.

BDBEGIN and DBEND (with logging) don't do anything (apart from providing an
audit trail in the log file) to help you with application failures (program
aborts in the middle of a transaction do not cause a rollback).

No feature of Image (apart from locking) provides transaction isolation that
will prevent one "transaction" from seeing the partial (and potentially
rolled back in the future if your using DBX transactions) changes, hence the
requirement for using strong and correct locking around DBX transactions.

The DBX transactions (DBXBEGIN/DBXEND) provide transaction management
layered on top of the system Transaction Manager, and will automatically
ensure that all such transactions are either fully committed or completely
rolled back in the face of both application aborts and system failures.
Once again individual updates done as part of a DBX transaction are visible
to other processes, so it's possible for another program (that isn't locking
strongly) to read and act on a change made by a transaction that will be
rolled back in the future.

The different types of transactions and recovery have different requirements
for where the log files (if any) reside relative to the volume set
containing the database(s), since the system XM does recovery on a
per-volume set basis.

Each has its own effect on performance, limits on transaction size or
simultaneous user counts, etc.

Logging without DBBEGIN/DBEND is only useful for roll-forward recovery if
something happens to your database but not to your log files (it may also be
useful for things like auditing, replicating your data, etc.).

DBX transactions won't help you with disk failures at all.

DBXBEGIN/DBXEND get logged to log files, so I presume (but have never tried)
that you could do at least transactionalized roll-forward recovery from a
log file with an application that used the DBX calls instead of the older
DBBEGIN/DBEND calls.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2