UNDO Retention on 10.2.0.2

Question

We are noticing some of these snapshot too old errors 01555 errors and we are not making use of any of the flashback functionality so I believe we are only interested in the undo table keeping the undo data while the transaction itself is active to ensure read consistency.
Previously we had undo_retention set to 10800 (3 hours) and I am thinking I should shrink this so that we only keep data as long as the transaction is active. If I set the undo retention length to a value like 300 (5 minutes) and a transaction takes 20 minutes am I going to get snapshot too old errors?
I am hoping the behavior is to keep the transaction data in the undo segment as long as the transaction is active for a minimum of undo_retention time and it would keep making use of space until it runs out of space that is not being used by some other transaction and not being held because of the 5 minutes retention. Is this how it will behave or after the 5 minutes will other transactions be able to overwrite this undo data causing an error even if there is other free space?
Some of the documentation seemed to say the undo_retention is a minimum recommendation to oracle. So if I don't care about flashback at all would a setting like 1 be reasonable assuming it would keep stuff as long as the transaction lasts +1 second(suggesting 1 since 0 means use the default of 900 aka 15 minutes)? I saw some other documentation suggesting setting it to the value of your longest transaction but I surely don't want to keep data from shorter transactions as long as my longest transaction as that would require a much larger undo tablespace so I am trying to figure out the most efficient setting to ensure consistency while being as space efficient as possible.
Thanks,
Jared

Answer 1

Thank you for all the replys on this thread those plus some stuff I have read in metalink have been very helpful. Have some follow up related questions.
From what I have read when a block is modified it goes into the undo in one of the segments and has an associated SCN number for each change.
1. If one DB connection does a series of updates to a given block and then disconnects (assume each update autocommits) and then the process is restarted and does more updates to the same block would it re-use the existing undo segment? (assuming that no select statements reference this block and cause it to be flushed) Does a new transaction on a given block imply a segment switch is a new select intersecting with a datablock the only thing that would cause it to change segments?
2. In the same scenario as above with a select happening between the two passes I am assuming that the select would cause it to flush the block (update the actual data) and that the second pass of updates on the same block would do the updates in a different undo segment? Does having a higher retention setting make it more likely to keep rotating segments as opposed to overwriting a previous one? In other words if I have my retention set to some very high amount of time like 10 days would it rotate all of the segments for that block before overwriting the first change?
My application currently has one process that does large queries that could last 5 hours or so at worst(all read only). And another process that does only new inserts.
Trying to figure out the exact behavior of how the undo retention manages switching undo segments to determine what is causing our problems. I have noticed on 10g2 that the number of undo segments is 10 and on 9.2.0.5 it was more like 108 or so and it seems like 10 is more likely to get 1555 errors and I am wondering if this is because it is more likely to cycle all segments and start overwriting blocks that are needed for a long running queries consistency.
Thanks,
Jared