Re: optimal size for rollback

I would phrase it as: a properly written application should not let the users leave uncommitted transactions for undefined amount of time. Not only because of rollback segments.

These systems should not exist but they do. And these problems do happen. Speaking of DBA's take on this, their involvement should be limited to spotting such things and preventing service loss that might be caused by them. Speaking of application support or development, they should redesign or fix these things if at all possible.

Regs
AK

Igor Laletin wrote:

> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:<3d86f3de_at_dnews.tpgi.com.au>...
> > "Igor Laletin" <ilaletin_at_usa.net> wrote in message
> > news:f9226414.0209162108.451dfc8_at_posting.google.com...
> > [snip]
> > > Users leaving transactions uncommitted? It's an exception in a
> > > production environment. May happen but "essential problem"? C'mon.
> >
> > Yeah, "c'mon". It happens.
>
> The most of the (front-end) applications I've seen were written in
> such a way that user clicks on a button and a short-running
> transaction is generated. User just doesn't have a chance to start
> transaction and forget about it. Sometimes developers or advanced user
> could sneak into production and forget to commit but they get a
> criminal record for that :) That's my experience anyway. Yours is
> obviously different.
>
> Hey, why not create a new thread? Something like:
> "I have N years experience in the production environments. I've seen a
> lot of different applications. Most of them share the same essential
> problem - users start transactions and forget to commit. What's your
> experience?"
>
> Wanna try? We have different experience in this respect and it would
> be interesting to learn who's more common.
>
> Another opinion you may want to check with production DBAs could be:
> "Occasionally I have some big jobs. Usual short transaction takes much
> longer when it hits rollback extended by the job. A user sees a
> responce time up to 2.5 sec instead of 1.0! It happened to four
> transactions per day out of thousands and I had to get rid of optimal
> to prevent it. I'm willing to pay with my time and disk space for
> dozens of dbs I support. Now I always advice - 'Don''t set optimal.
> Period.'"
>
> > I see. You think this is all just training room theory. Think again.
>
> Frankly? Yep, I do think so.
>
> My personal experience is different from yours. Of course it's one
> man's experience and I may be wrong. But just your opinion is not
> enough to change it. Why?
>
> I don't feel that you have an extensive production experience. As far
> as I know you're an instructor. I don't remember reading on your
> website anything about "real life encounters" or your DBA career
> before joining certain software vendor. My apologies if it's
> incorrect. I did try to check it but the site was unavailable.
>
> > End of thread.
>
> Indeed.
>
> Regards,
> Igor
>
> > HJR
Received on Fri Sep 20 2002 - 00:23:20 CDT