Re: The Slippery Slope, Smaller Transactions = Uglier Code?

It seems to me that if you decrease the size of the transactions, the number of transactions will increase. In other words, the amount of data written to the rollback will be the same over the same period of time. For a given rollback segment size, the time between wrap-around is inversly proportional to the total amount of data being written to the rollback segments. It is the rollback wrap-around events that lead to the snapshot to old errors -- if a query spans a wrap, you'll get the error.

 So you minimize the error by slowing the rollback write rate (slowing the transactions!), speeding up the queries, enlarging the rollback segment storage (size and/or number) or scheduling long queries for periods of light updating. I vote not to slow down the transactions. If you can segregate the queries and updates, this is good. If not, try speeding up the queries (but you may also need to enlarge the rollback storage).

S Green wrote:

> Everywhere I turn, I am reducing my transaction size and shortening my query
> duration. I am doing this to minimize the roll back segment size and to
> avoid the data too old error. But each step, makes my code uglier. Simple
> high level relational commands start looking like procedure code.
>
> Am I missing something? Or is this a classic design process, where
> optimizing one ideal compromises another.
>
> TIA
>
> scott
Received on Sun Jun 21 1998 - 19:30:46 CDT