How many rollback segments

I work with a system that has upwards of 50-100 users all logged in with client applications. In the normal process of what they do the application adds records, updates records and occasionally deletes records. The chances of everyone having an active transaction at the same time is pretty minimal, but in theory some day it just might work out that I have 50 workstations all trying to insert/update/delete at the same time (different records however, since each operator would only see records that belong to them).

Right now I have 4 rollback segments. To date I have not seen any problems that have occurred because of this. But what I'm wondering is whether I shouldn't have more.

Let me pose this. Suppose that it occurs that I have ten operators who are doing things at will insert/update/delete simulaneously. Will the first four operators get the rollback segments and the other six will see the application hang while the rdbms waits for a rollback segment that it can assign to them? If so, would I see lag time (that is, the time between the moment they hit the enter key and the time that they can continue with the next operation) decrease if there were more rollback segments available? Typically, the transactions performed by the client application are small (a couple rows at the most), so once processing starts it tends to complete a transaction pretty quickly, but I'm wondering that if things really get busy will there be a queue waiting for rollback segments if there are more outstanding transactions waiting to occur then there are rollback segments?

Thoughts?

Ken Received on Fri Jun 18 1999 - 08:08:27 CDT