Re: UNDO: 10g-style behaviour in 184.108.40.206?
Date: Sat, 18 Apr 2009 07:14:43 +0100
"Randolf Geist" <mahrah_at_web.de> wrote in message news:d54433e6-5858-4d6d-86a0-c009c2a60fae_at_3g2000yqk.googlegroups.com... On Apr 13, 10:16 am, "Jonathan Lewis" <jonat..._at_jlcomp.demon.co.uk> wrote:
> i.e. the case when AutoExtend is ON - and my point was that I had seen
> the tuned_undoretention value in v$undostat drop BELOW the setting
> for parameter undo_retention with autoextend ON.
apologies, I got that wrong and thought it was about the "autoextend OFF" case. Your case seems to be odd, yes, and I would tend more to the "implementation bug" or "implementation limitation" explanation (given the "all available space tied to one large undo segment" information).
Confession time - I've just checked the notes I made at that client, and the comment I made above was wrong. I had two clients with undo problems in one week and mixed their configurations up when describing the anomaly.
I have NOT seen the tuned_undoretention drop below the parameter setting. The client with autoextensible files had (hence auto undo tuning) had simply let his undo_retention default to 900 seconds.
Querying his v$undostat, his tuned_undoretention had regularly climbed to 50,000 seconds then plunged to 1,500 seconds. (The other client had set his undo_retention to 14,400 seconds, and that's where I had muddled things up in my memory).
Client 1 has a problem because of side effects of the enormous automatic redistribution of undo extents that took place from time to time.
-- Regards Jonathan Lewis http://jonathanlewis.wordpress.com Author: Cost Based Oracle: Fundamentals http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.htmlReceived on Sat Apr 18 2009 - 01:14:43 CDT