why?

you would have the same exact consistent read issue on db1
but a larger RBS issue on db2

No, not at all.

I am saying "the probability of ora-1555 is related to the size of the smallest rbs you have"

if you have 15 2gig RBS's and 1 512k rbs -- your probability of an ora-1555 is based mostly on the 512k rbs. It will be used as often as the 2gig rbs's but it will "wrap around" and reuse itself much faster. If someone needs the undo that was in that small one -- and it no longer exists -- ora-1555 is the result.

When using manual undo:

You want to have equi-sized RBS's

Each of which is large enough to not wrap around under normal conditions -- for the amount of time it takes to execute your long running queries.

Say you generate "about 5meg of undo per minute" during peak (5meg is just a number, pretend it is "N")

Now, you have queries that need to run for 10minutes.

You need at least 75meg of undo (room for comformt, 10*5 = 50meg, 75 just makes us feel better).

So, if you decide you want 15 rollback segments (you have about 10-20 concurrent transactions for example) each RBS should be about 5meg in size nominally.


In that fashion, you should find your RBS is not wrapping around and reusing itself inside of the 10 minute window. You should not be recieving the ora-1555



If you are using automatic undo:

set undo retention to 900 (about 15 minutes).

make sure you have sufficient disk space allocated to the undo tablespace to allow it to hold 15 minutes of undo.