Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.misc -> Re: undo retention
Yes (or at least it tries), but it is only keeping change vectors, so
it is not as bad as it sounds. The vectors are needed for read
consistency. For example, if you start a report that takes six hours,
Oracle needs to be able to reconstruct any blocks it accesses as they
existed at the beginning of the six hours. By default, each
transaction needs to be able to see what the db looked like at the
beginning of the transaction. Oracle the database isn't keeping the
results of queries (although some applications may).
Oracle is also somewhat optimistic - it assumes you are going to commit any transaction you start, so it writes things to its own buffers, then writes those to disk at its leisure. If you roll it back rather than committing, Oracle may have some work to do.
These concepts are clearly explained in the manuals, which are available at http://tahiti.oracle.com, free with registration, and worth a lot. Delve into that concepts manual, so you can rest easy and talk reasonably with your dba, understand the difference between redo and undo. If you don't have enough disk space to deal with 48 hours of transactions, that's your dba's problem anyways, right?
Here is an example quote from the concepts manual: "To manage the multiversion consistency model, Oracle must create a read-consistent set of data when a table is queried (read) and simultaneously updated (written). When an update occurs, the original data values changed by the update are recorded in the database undo records. As long as this update remains part of an uncommitted transaction, any user that later queries the modified data views the original data values. Oracle uses current information in the system global area and information in the undo records to construct a read-consistent view of a table's data for a query."
jg
-- @home.com is bogus. http://viswiz.imk.fraunhofer.de/~steffi/madcow/madcow.htmReceived on Tue Feb 07 2006 - 17:32:45 CST