l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2003 Apr 25 18:54

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Unnecessary RDBMS features [was Need your help in recovering database.]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Unnecessary RDBMS features [was Need your help in recovering database.]

--- Tim Riley <timriley@timriley.net> wrote:
> > Are you actually saying you believe commit/rollback is a *bad* thing?
> Yea--it's not worth its weight.
> >
> > If so, you are definitely the first person I've ever heard say that...
> >
> > I'm not criticizing your opinion; I'm just trying to understand.
> Commit/rollback requires that a copy be made of each datum involved
> in an insert, update, or delete statement. This is very expensive. But
> why make the copy? I know my insert, update, or delete is the correct
> thing to do at the time. If I'm making a mistake to the database,
> I'll fix it when I catch it.

Commit/rollback is invaluable, depending on what you are doing.  There are some
very good reasons to use commit/rollback functions in your RDBMS.  How exactly
the rollback is done is implementation specific; the cost should not have much
effect on performance.  The database system that we use in our shop
(intersystems Cache) has no problem with gigabytes of database and thousands of
updates daily, with full rollback functionality.  There's no good reason why
the SIZE of a database has anything to do with it's ability to audit db
transactions (commit/rollback).

We have been doing testing of DB systems, when we encounter strange errors. 
So, we take a current snapshot of the db, rollback to just before the time that
the error occured, and step one by one through transactions until the error
occurs.  It _really_ gives clues as to what _EXACTLY_ was going on when an
error occurs.  There have been times that it's worth it's weight in gold,
because it has saved hours upon hours of: 1. reentry of information, 2. testing
of systems, 3. recovery of damaged or corrupted files.  It's for this reason
why we use intersystems cache, because of it's ability to do this for the past
3 or 4 major releases (with no hit on performance).

Commit/rollback is just another feature for an admin to decide if the cost is
worth the benefits, IMHO.  But just because some RDBMS's can't implement a good
transactional system (oracle, MySQL) doesn't mean you should throw out a baby
with bathwater.

My $0.02


PS: Dump your databases often so your databases don't take a dump on you ;)

Nothing is as sad as gigabytes of corrupted db files.  Sorry to hear :(

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.