Re: UNDO: 10g-style behaviour in 9.2.0.8?

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Sat, 18 Apr 2009 07:14:43 +0100
Message-ID: <nLOdnQeWNo9O8nTUnZ2dnUVZ8tmdnZ2d_at_bt.com>



"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:
> Randolf,
>
>
> 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.

Jonathan,

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).

Regards,
Randolf


Randolf,

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.html
Received on Sat Apr 18 2009 - 01:14:43 CDT

Original text of this message