[comp.databases] Multiversion Concurency Control

geller@bnrmtv.UUCP (Phil Geller) (01/24/89)

Is anyone in netland familiar with any commercial DBMS products that
support multiversion concurrency control (where previous versions
of a changed row are kept around for recovery purposes)?  Or has
anyone implemented such a scheme on top of an existing DBMS product?


Phil Geller
Voice:  (415) 940-2376 
UUCP:   ...{hplabs | amdahl | ames}!bnrmtv!orion!geller
arpanet:   bnrmtv!orion!geller@ames.com
mail:   BNR, P.O. Box 7277, Mountain View, CA 94039-7277

davek@rtech.rtech.com (Dave Kellogg) (01/30/89)

In article <4795@bnrmtv.UUCP> geller@bnrmtv.UUCP (Phil Geller) writes:
>Is anyone in netland familiar with any commercial DBMS products that
>support multiversion concurrency control (where previous versions
>of a changed row are kept around for recovery purposes)?  Or has
>anyone implemented such a scheme on top of an existing DBMS product?

	I guess a lot of this depends on what you mean by "kept around."
	Do you require something internal like the DBMS to keep a physical
	before image of the page around, or do you simply want the ability
	to re-build the database up to a particular point in time?

	INGRES, like most commerical DBMS's in our market, allows you to take
	a "checkpoint" (i.e. consistent snapshot of the DB) and then record 
	"logical" changes to it ("journaling").  We use logical journaling
	(i.e. journal file says "fred changed x to y at time t"), rather than
	physical journaling (storing old copies (before images) of changed
	pages) because in many cases it's more efficient in terms of disk
	space to store logical changes.  For example, if you change one byte
	on a (2048 byte) page, INGRES stores only a change record (much less
	than 2048 bytes) rather than a 2048 byte copy of the old page.

	I think we need to know more about what you actually need to do before
	discussing this further.  If all you want is to recover up to a moment
	in time (e.g. ten minutes before someone ran a dis-joint delete) 
	then most of the DBMS's you hear mentioned in this newsgroup 
	can do the job.

	David Kellogg
	davek@rtech.rtech.com




>Phil Geller
>Voice:  (415) 940-2376 
>UUCP:   ...{hplabs | amdahl | ames}!bnrmtv!orion!geller
>arpanet:   bnrmtv!orion!geller@ames.com
>mail:   BNR, P.O. Box 7277, Mountain View, CA 94039-7277