Re: Which RBS is my Update using ?

Hello Daniel,

I think wasting diskspace isn't a good practice either.

The case:
24x7 Mixed environment (OLTP, reporting) Lots of users
Lots of small transactions
Occasional large updates and deletes :( transactions which cannot be delayed Reporting -> long running queries

I usually don't need huge RBS'es in my OLTP system, but still occasionally do have a big transaction which has to complete as soon as possible. For that I set big transaction to use large RBS and go! And I don't care if any small transactions get to it as well, or even if a small-transaction-owner leaves his data uncommitted and goes to a pizza or smth, because he's kicked out of the db (not application) in less than a hour. (we don't allow any regular user to make arbitrary dml anyway - and our application doesn't just leave user transactions hanging for long times)

I actually think that the concept of how our application uses database is a bit bad from database point of view, but since databases don't run businesses (it works the other way), I won't try to start changing it just because that my RBSes don't match general theoretical recommendations (where real life outside the database isn't considered).

So, having all same sized rollback segmnents is a good, best practice in general conditions, but still, I don't see what use would I get by resizing all of my rbs'es to a huge size. So far I'm following the golden rule of all engineers - If it works, don't touch it ;)

Or am I missing something here?

Tanel Poder
a DBA.

> One might want to do what you suggest. But then again one might also wish to
> listen to Tom Kyte, Howard Rogers, and numerous other experts here at c.d.o.
> who will gladly tell you this is a bad practice and to not do it.
>
> I'll repeat myself again ... if you need to ask the question you have your
> rollback segments improperly sized: They should all be identical and sized to
> handle the largest transaction on the system.
>
> Check the google.com archives for the numerous postings by Tom and others on
> this subject.
>
> Daniel Morgan
>
Received on Tue Sep 17 2002 - 16:09:31 CDT