Re: UNDO tablespace question

Punter:

The thing about undo is, it is likely to be the most used tablespace, but if you divide it up into many data files, some of them will not accessed much of the time. Depending on the cumulative length of your transactions. If you have many small fast transactions and a few long long-lasting transactions, the segments with the long transactions probably won't get used much. And since you can't predict which, it becomes a matter of luck, and probably a waste of time to try to predict - especially since the odd times of mass updates will be when you've shot yourself in the foot. This is the sort of thing where if you used SAME with all your disks in a RAID, you might do better than futzing around, since the active segments will be spread more evenly over the disk spindles. Unless you have enough control over the app and patience to use manual undo, specifying evey transaction to a known segment. If your performance is that picky, you'd be better off just throwing more hardware at it anyways.

Sybrand's point about recovery is good too - lots of small files helps RMAN parallelize equally, and can help speed a recovery.

Here's something interesting:
http://www.evdbt.com/AutomaticUndoInternals.pdf

And you might read up on the 10g ASM feature, which not only stripes your data but automatically rebalances it. http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14220/mgmt_db.htm#i34800

jg

--
@home.com is bogus.
http://translate.google.com/translate?hl=en&sl=ja&u=http://www007.upp.so-net.ne.jp/relax_oneself/&prev=/search%3Fq%3Doneself%26hl%3Den%26lr%3D