db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "RPost" <rp0...@pacbell.net>
Subject Re: Derby architecture/design documents
Date Sun, 06 Feb 2005 23:52:31 GMT
> "Dibyendu Majumdar" wrote:

> As this is a complex area to describe . . .

You got that right!

1. Where in the format does a log record indicate the type of record (redo,
undo, etc)?

2. Is the type of record at all related to the "Groups" defined in

3. If not, how do these groups fit into things?

4. Are log records always flushed to disk? I have seen references in the
code to the possible use of an "in memory" database where log records might
not be flushed. Also, in the simple case of a change to a single field on a
single page being made by a transaction and then the transaction rolled back
is it possible that 'no' log record will be flushed to disk or will two log
records always be flushed even though no commit was ever performed?

5. When are log records flushed to disk? Are they buffered in memory until
the buffer is full or until one of the underlying transactions commits?

6.  Mike suggested a possible change to copy the log files to another disk.
Do the current contents of the log files contain all of the data needed to
effect "change data capture"? For example, assume that at 8am a backup copy
of database A is made to another disk. Changes are made to database A
throughout the day but no changes are made to database B (the copy). At 5pm
could the log file(s) from database A be used to update database B so that
database B would again be identical to database A? Or would some log
operations need to capture additional info (e.g. physical undo vs. logical
undo) for this to be possible?

I would be interested in working on this type of 'log mining' for both
'point in time' recovery and 'change data capture' type functionality.

View raw message