db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Derby architecture/design documents
Date Mon, 07 Feb 2005 19:07:04 GMT
comments below

RPost wrote:
>>"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)?
log records are not of type redo, undo, ...   Redo is the recovery phase
and during redo you ask every log record to perform redo.  And during
undo you ask it to do undo.
> 2. Is the type of record at all related to the "Groups" defined in
> iapi\store\raw\Loggable.java?

Groups are mainly used so that a scan can ask for just that kind of log
record, or during a scan make it easier to code for a particular type of
log record which might need special handling - for instance a FIRST log
record indicates the first log record of a transaction which needs some
special handling.  It allows for log records to be logged that store
need never look at.
> 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?
There are 2 important flush guarantees:
    1) before any change to a data page goes to disk the associated log
record will be flushed to disk.
    2) before returning to a client application after a commit request,
all log records associated with the transaction must be flushed to disk.

In derby this is always done by flushing all records up to and including
the interesting log record.
> 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?

see above
> 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.

yes all the changes are there, this is how current roll forward recovery
works.  I don't think any log operation changes would be necessary other
than adding some way to determine "time" for point in time recovery.  As
has been suggested, adding some time field to the begin or end
transaction log record probably is needed.


View raw message