Boguslaw,

The benefit you state is being able to roll-back the data to a point in time
or view the data "as was". It could work, you could write the code to be
able to:
1) View DB as a read only connection as if you are transaction ABC => a
time.
2) Rollback to a transaction number.

The problem here is that rolling back to a time depends heavily on the
commit time, not the TX start time. The TIP page is AFAIK a couple of bits
per transaction in an array of transactions. To add a commit number (=>
timestamp) would be a fair amount of work and space usage. Alternatively
you could make a copy of the TIP and store in a BLOB every minute I guess.

Anyway, I think the benefits of this over "shadowing", "clustering",
"incremental backups", all of which require a plug-in at about the same
point, deliver more benefits. Do you agree?

Jason Chapman
JAC2 Consultancy

Training - Development - Consultancy
Delphi, InterBase, Firebird, OOAD, Development lifecycle assistance,
Troubleshooting projects, QA.....
www: When I get round to it....
Mob: (+44) 07966 211 959 (preferred)
Tel: (+44) 01928 751088


""Boguslaw Brandys"" <brandysb@...> wrote in message
news:001a01c254a1$02b9bcf0$3e104cd5@DOM1...

> Jim,
>
> As I understand You are talking about a journal to separate process (an
> later to an external file). This would be great for some replication

schemma

> (one database is Master another - Slave like in MySQL) and if sources

still

> exists in Firebird it is quite enought I think to build internal

replication

> , so my idea would be worth not much. (IBReplicator exist but it is not

Open

> Source and free as I know. Could it be based on journaling process You
> mention ?)
> I was thinking about something different : how to use existing feature of
> Interbase (record versioning) for avoid redo log completly.
> Unfortunately I don't know InterBase source quite well, I'm rather

database

> manager and use InterBase as a programmer so maybe I misreported

something.

> The idea was to sign each record (or each transaction in TIP - keep in

mind

> that I don't know sources so I don't know what is better) with current
> server timestamp and don't let database engine to throw away old committed
> versions of record (as usual even without sweep) which timestamp is above
> some limit (for example Now() - 12 hours).
> This of course will cause database to grow fast (if this option is used)

but

> allow to get snaphot of records below requested timestamp (so it is

internal

> redo log).
>
>
> Best Regards
> Boguslaw
>
>
>
> ----- Original Message -----
> From: "Jim Starkey" <jas@...>
> To: <IB-Architect@yahoogroups.com>; <IB-Architect@yahoogroups.com>
> Sent: Wednesday, September 04, 2002 8:54 PM
> Subject: Re: [IB-Architect] Fw: [ib-support] One interesting idea (fixme

if

> I'm wrong)
>
>
> > At 08:35 PM 9/4/02 +0200, =?iso-8859-2?Q?Bogus=B3aw_Brandys?= wrote:
> > >>
> > >> I've just read technical paper from Borland's Intebase Web about
> > >Transaction
> > >> Inventory Pages(TIP) , Oldest interesting Transaction (OIT) and

Oldest

> > >> Active Transaction (OAT) .
> > >> Not all are clear for me, but I have an interesting idea.(at the user
> > >point
> > >> of view)
> > >> Firebird is known from good shadowing and backup but do not have any
> log
> > >> file to rollback to some time point in the past .
> > >>
> > >> This is not quite exact , i think :-)
> > >>
> > >> I don't remember how this log is called in another database

systems,but

> > >is
> > >> sometimes used becouse someone deleted critical information from
> database
> > >> (very bad database ;-) .
> > >>
> > >> Let me explain.
> > >> Firebird database manager does good housekeeping with old versions of
> > >> records,and here my idea occurs.
> > >> Assume we have ordinary database which is not swept during day but at
> > >night,
> > >> and backup is done once a week.
> > >> Define some server feature like "VANISH_TIMESTAMP":
> > >> VANISH_TIMESTAMP 12 (default = 12 hours)
> > >> Now all records should have not only transaction id but also a
> timestamp
> > >> when were created
> > >> (sufficient is to store one double value for record).Alternatively

all

> > >> transactions in TIP could use timestamp, I don't know which is better
> (?)
> > >> When "VANISH_TIMESTAMP" is declared database manager should not

delete

> > >> committed records which are "younger " than 12 hours from now ,even

if

> are
> > >> many such records.
> > >> Gbak would have a feature to rollback database to some point in the
> past
> > >12
> > >> hours.
> > >> Making all records with timestamp also give us an option to easy
> replicate
> > >> database by just periodically check if there is new committed record
> and
> > >> replicate such record in another database (replication could stand
> > >internal
> > >> Firebird feature)
> > >>
> > >> This is of course an idea (and most of admins won't use it) but

allows

> > >many
> > >> interesting things.
> > >>
> >
> > Interbase actually had this functionality from the beginning of
> > time until Borland's version 5. The database journalled either
> > page changes or pages images (whichever was smaller) to a journal
> > server process that could be shared across any number of database
> > on a network.
> >
> > During development of version 5, some crackerjack manager had a hot
> > idea on how to use the journal for a sequentially write redo log
> > in case of system failure, apparently getting something for close
> > to nothing. Unfortunately, when reviewed, it turned out that what
> > he gave up was the very nice principle that when journalling was
> > enable, a transaction wasn't reported as committed until the bits
> > were safely written on two pieces of oxide, eliminating all danger
> > from a single point of failure. So the old journalling system
> > was pitched with the new one.
> >
> > I haven't checked the code, but there is no evidence that the
> > Borland developers knew that text editors could also delete
> > stuff from a source file, so I wouldn't be surprised if most
> > of the code was present but latent. The journal subsystem
> > itself was next to trivial, so re-writing it in modern C would
> > make as much sense as an archeological dig.
> >
> > Journally has its problems, mostly the expense and gross
> > unreliability of tape driver (oh, ugh). But a journal to
> > a CDR or DVD-R drive might actually be worth thinking about.
> >
> > Jim Starkey
> >
> > To unsubscribe from this group, send an email to:
> > IB-Architect-unsubscribe@onelist.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to

http://docs.yahoo.com/info/terms/

> >
> >
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>