Subject | Re: Transaction log or alternative |
---|---|
Author | rcrfb |
Post date | 2004-06-21T07:19:05Z |
Hi all,
there's another advantage of transaction logs (sometimes also called
'redo logs'): the possibility of recovering a database to a time
between the last (full) backup and 'now'.
Given the last (or some previous) backups and a continuous list of
transaction logs (most databases will write more than one redo log
file instead of writing into one single file), it should be possible
to install the database from the backup and make the recovery process
reading all needed redo logs until a given timestamp has reached.
This will make it possible not to only recover from system crashes,
but it is (partly) possible to recover from "damagign SQL statements
(like 'dropping tables' or other such stuff). Such things cannot be
handled by shadow databases (as the table will be dropped there too:-).
Roger
there's another advantage of transaction logs (sometimes also called
'redo logs'): the possibility of recovering a database to a time
between the last (full) backup and 'now'.
Given the last (or some previous) backups and a continuous list of
transaction logs (most databases will write more than one redo log
file instead of writing into one single file), it should be possible
to install the database from the backup and make the recovery process
reading all needed redo logs until a given timestamp has reached.
This will make it possible not to only recover from system crashes,
but it is (partly) possible to recover from "damagign SQL statements
(like 'dropping tables' or other such stuff). Such things cannot be
handled by shadow databases (as the table will be dropped there too:-).
Roger
--- In firebird-support@yahoogroups.com, Lester Caine <lester@l...> wrote:
> Alan McDonald wrote:
>
> >>There are several answers to this. The first is probably the obvious -
> >>if the data is critical, the the machine it is running on would be
using
> >>a RAID disk, so allowing 'hot' handling of live data. The second
option
> >>is 'replication', where there is more than one set of hardware, each
> >>maintaining a live copy of the data.
> >>
> >>Firebird supports an internal SHADOW facility which will allow it to
> >>maintain two local copies of the data, and the second copy can be
> >>accessed should the first become corrupt. This should be viewed as a
> >>secondary method of 'backup', depending on the level of availability
> >>required.
> >
> > Lester - I think this is misleading. Shadows are only good when
there has
> > been a hardware failure on one disk. In the event of corruption on
one copy,
> > the shadow mechanism is MOST likely to provide two databases with
corruption
> > since it is mirroring the disk writes to two places.
> > Alan
>
> That is why I said it was secondary. I think Jim put it in at a time
> when RAID and things like that were not even thought of :) 30Mb of DISK
> space was a luxury ;) so the alternative hardware solutions available
> today should be checked out first. And THAT is independent of the
> database engine.
>
> --
> Lester Caine
> -----------------------------
> L.S.Caine Electronic Services