>"The answer for this from our vendor is to increase the size > of the UNDO based on their DBAs statement that UNDO is consumed rapidly > because every query makes a physical copy of all tables and holds on to > them for the retention period.
Sherrie, In my considered opinion: Woohoohoohoo. That's a ridiculous thing for a DBA to say. I hope he was misinterpreted somewhere down the line because otherwise he's got a very flimsy grasp of the read-consistency model. In very simple terms Undo is used to hold a copy of any changed data (not the whole table!) which has not been committed and flushed to the datafiles. While it's there the data for an update transaction is available a) to the 'owning' transaction in case it has to ROLLBACK the updates it's made. b) to any other transactions which need to reconstruct the data as it was before the update began. On a more positive note I agree that we need the text of the error message in order to give some help. Cheers, Mike ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Tuesday, August 12, 2003 4:39 PM > I have a 2gb UNDO tablespace. A third-party application continually runs > out of UNDO when it joins two tables to produce a result table. Our > retention time is set to 15 minutes, the NoSpaceErrCnt in V$UNDOSTAT is > always zero. The answer for this from our vendor is to increase the size > of the UNDO based on their DBAs statement that UNDO is consumed rapidly > because every query makes a physical copy of all tables and holds on to > them for the retention period. I can find nothing that discusses exactly > how UNDO physically works, and am not sure that this can be true. That > would mean that every user querying our database would have copies of the > tables in the UNDO, and I'd need about a gazillion gb to handle that. Does > anyone have any insights on how the UNDO physically works? > > > > --------------- > Sherrie Kubis > Southwest Florida Water Management District > 2379 Broad Street > Brooksville FL 34604-6899 ******************************************************************************************** E mail Disclaimer You agree that you have read and understood this disclaimer and you agree to be bound by its terms. The information contained in this e-mail and any files transmitted with it (if any) are confidential and intended for the addressee only. If you have received this e-mail in error please notify the originator. This e-mail and any attachments have been scanned for certain viruses prior to sending but CE Electric UK Funding Company nor any of its associated companies from whom this e-mail originates shall be liable for any losses as a result of any viruses being passed on. No warranty of any kind is given in respect of any information contained in this e-mail and you should be aware that that it might be incomplete, out of date or incorrect. It is therefore essential that you verify all such information with us before placing any reliance upon it. CE Electric UK Funding Company Lloyds Court 78 Grey Street Newcastle upon Tyne NE1 6AF Registered in England and Wales: Number 3476201 ******************************************************************************************** -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Hately, Mike (LogicaCMG) INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).