--- In IB-Architect@onelist.com, "Markus Kemper" <mkemper@i...> wrote:

>
> I'll offer my opionon and duck out of this one. If a user/hacker
> can gain access to (ie. connect to) a database and manipulate data
> (ie. circumvent SQL security), your problems are larger than the
> benefits that a journaling/logging feature for recovery from such
> violations would provide.

Markus,

I think that you're making an unwarranted assumption that journaling
is another security layer. I view journaling as a tool for disaster
recovery. In addition to backup, which is a snapshot in time,
journaling is an effective way of keeping up to the minute
incremental backup. This is how we do hot backups with Oracle
and Informix.
With Interbase, we run gbak against a live database, and keep the
database on a RAID 5 device. Still, we've had crashes which
left us with a corrupted database file and IB was unable to repair
the database. In our environment (essentially and engineering data
warehouse) we were able to use the backup and reinsert the raw
data, however, this wouldn't be acceptable for an OLTP system.

Replication or shadowing don't really solve these problems, even
if it was true that "disk was cheap." True, if you have a 10GB
database, it's easy to buy another "Fry's special" and have
a mirror on another physical device. However, when you approach
hundreds of GB, suddenly you're up against the number of physical
slots that you can install on a machine. Less than two years ago
we bought a HW RAID 5 with 220GB of disk space for about $100K.
This is not cheap by my standards. Of course, NetApps support
would help here :-)

I like Jason's idea of the freezepoint. I think it would be an
elegant solution to my needs. I think it would be really neat
if it worked closely with journaling file systems (e.g. Veritas).
What I'd like to see is the ability to create a freezepoint
and take a consistent snapshot of the file at that time.


Bye,
Jerzy