Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from smtp-aa.freelists.org (smtp-aa.freelists.org [23.23.80.81]) by malta2546.startdedicated.com (Postfix) with ESMTPS id 4E0191003165E3 for ; Thu, 9 Sep 2021 14:56:28 +0200 (CEST) Received: from turing.freelists.org (ip-10-0-0-164.ec2.internal [10.0.0.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp-aa.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 4944A4299A; Thu, 9 Sep 2021 12:56:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Postfix) with ESMTP id 29AD5400CF; Thu, 9 Sep 2021 12:56:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org; s=turing; t=1631192187; bh=v0JoHMSTyqkwHvjUgWY11s0RIg4WZBgbXyNvsyiMgxA=; h=From:Sender:Sender:From; b=W9qkXKiegcuD0qT9u8/sTfpc9gbPAsGk0Kg5DDq+VMclE2Sgg1l+PomL7Y/TiNjU+ BtZV1YNCQetU0GpR35pUl/uppjFW+4WLS6pHuVw+7odtSUCDQmUZ9LBhM5b3Y4T1M2 no1PUbYTZdvO7dJUveMvKZZ4bv/LmnfFvp8RIN2M= X-Virus-Scanned: by FreeLists at turing.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBUkpwb940dX; Thu, 9 Sep 2021 12:56:27 +0000 (UTC) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Postfix) with ESMTP id 195AF3FEA7; Thu, 9 Sep 2021 12:56:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org; s=turing; t=1631192182; bh=v0JoHMSTyqkwHvjUgWY11s0RIg4WZBgbXyNvsyiMgxA=; h=From:Sender:Sender:From; b=K1XsCi8aurEyfxZryGcs2K7w17Tq9wbjZ2whQjY8P49tyCu1UEmriocTakX6QrV19 PHqTwIMBa81aA/MkcakkBb/LF0MN3RIvoBbtfRLdKDiLmE4PRMpvCjrDHh8qELrkEe 4WelYKO5uL+FPWVsBzyezkwFbzajfhA1M97LLGqQ= Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 09 Sep 2021 12:56:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Postfix) with ESMTP id 907C63FDF0 for ; Thu, 9 Sep 2021 12:56:19 +0000 (UTC) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oP2FJAeTQOP for ; Thu, 9 Sep 2021 12:56:19 +0000 (UTC) Received: from gw2.tidalhosting.net (gateway.tidalhosting.net [155.130.128.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Postfix) with ESMTPS id 6279A3FDE8 for ; Thu, 9 Sep 2021 12:56:19 +0000 (UTC) Received: from mrtr.tidalhosting.net (UnknownHost [10.0.150.3]) by gw2.tidalhosting.net with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Thu, 9 Sep 2021 08:56:10 -0400 Received: from mx1.tidalhosting.net (unknown [10.0.100.9]) by mrtr.tidalhosting.net (Postfix) with ESMTPS id 7B260305C23F; Thu, 9 Sep 2021 08:56:05 -0400 (EDT) Received: from mwf4500 (c-73-238-99-41.hsd1.ma.comcast.net [73.238.99.41]) by mx1.tidalhosting.net with SMTP (version=Tls cipher=Aes256 bits=256); Thu, 9 Sep 2021 08:55:47 -0400 From: "Mark W. Farnham" To: "'Lok P'" Cc: "'Hemant K Chitale'" , "'John Piwowar'" , "'Oracle L'" References: <151101d7a4bb$02dd82f0$089888d0$@rsiz.com> <156d01d7a4d8$cd223020$67669060$@rsiz.com> In-Reply-To: Subject: RE: Undo Tablespace Error Date: Thu, 9 Sep 2021 08:55:38 -0400 Message-ID: <162101d7a579$fdc040e0$f940c2a0$@rsiz.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1622_01D7A558.76B1D530" Content-Language: en-us X-Exim-Id: 162101d7a579$fdc040e0$f940c2a0$ X-archive-position: 80894 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: mwf@rsiz.com Precedence: normal Reply-To: mwf@rsiz.com List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-Subscribe: List-Owner: List-post: List-Archive: X-list: oracle-l ------=_NextPart_000_1622_01D7A558.76B1D530 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t know whether there is a different error fall back order. = I thought the error was failing to extend, so I can conceive that it = might not try to extend with autoextend off and tell you it ran out of = space in undo instead of trying to extend and failing. =20 It would give me the willies to have maxbytes smaller than the actual = size, but that is just because it doesn=E2=80=99t make sense to me. = Without the source code the only way to determine the behavior of the = running code is to do an enumerative case test seeing what happens. =20 My experiments with UNDO were long ago and I never bothered with the = cases that didn=E2=80=99t make sense to me to allow, so I cannot = definitively answer your question. =20 In your situation, and assuming space is available, I would create a new = UNDO that was for sure internally consistent with the values you want = and then alter that online and wait for the current one to be completely = inactive and eventually drop it. After that, with all the values making = sense and being internally consistent, I would expect behavior to be = easily predictable. =20 IF your shop is somehow attached to the nomenclature of the current = UNDO, you can replace UNDO twice to get back to the original name, but = be patient with the complete clearing of the one you=E2=80=99re going to = drop and recreate (it won=E2=80=99t drop until all transactions are = complete, but it might let you kill read only queries to drop it, the = same as running out of retention time.) I=E2=80=99m a bit rusty on this. =20 Other than running away from file corruption errors, the only other = reason to rotate UNDO was back when a variety of storage performance = classes made sense with very large history that didn=E2=80=99t need = super speed and intermittent large transaction batches that benefitted = from very fast (like SSD versus spinning rust) speeds. Then you briefly = switched to the fast stuff, started the batch transaction, and = immediately switched back. That would put your performance requiring = transaction on the fast stuff (possibly along with a few other things = that happened to start before the switch back) and then do the mundane = stuff on the routine UNDO. The operations control to mesh that was = rarely worth the trouble and some folks from Oracle mentioned they had = deeply tested switching but had not deeply tested switching back. It = never failed that I saw in some cases that were bigger than a bread box. = In the days when SSD was extremely expensive compared to spinning rust, = it was sometimes worth it to do more complex operations to buy less of = it and get the same benefit. =20 I doubt any of that applies to you. I suppose with the enormous RAM = sizes we have now and private designations, if you have an operating = system with duplex RAM for error control putting some UNDO on RAM might = be useful. If Oracle wants me to do that experiment for them, = I=E2=80=99m all ears. =20 Good luck. =20 From: Lok P [mailto:loknath.73@gmail.com]=20 Sent: Wednesday, September 08, 2021 11:39 PM To: Mark W. Farnham Cc: Hemant K Chitale; John Piwowar; Oracle L Subject: Re: Undo Tablespace Error =20 Thank you. I will try to see the alert log for more details.=20 =20 But if my understanding is correct , in current scenario with maxsize = being set there is no difference in undo behaviour if we keep the data = file as either Autoextend ON or OFF. Correct me if wrong? =20 On Wed, 8 Sep 2021, 11:12 pm Mark W. Farnham, wrote: We cannot tell from the apparent information presented HOW it got to = 200. But it should not be able to extend beyond the set MAXBYTES. The = behavior I would have built is to complain if you try to set maxbytes = lower than an already existing size for a file. If you keep logs of the = manual intervention sections (at least) or complete alert logs for at = least the system, then you might discover how it got to 200. =20 Yes, you ARE within the limits of bigfile, presuming that more space is = available on the storage volume. NO, it should not autoextend if it is = at or beyond the MAXBYTES defined for the file, and tossing the error = you are seeing seems correct behavior to me. =20 Sigh. =20 From: Lok P [mailto:loknath.73@gmail.com]=20 Sent: Wednesday, September 08, 2021 12:13 PM To: Mark W. Farnham Cc: Hemant K Chitale; John Piwowar; Oracle L Subject: Re: Undo Tablespace Error =20 I see it's a bigfile tablespace. And if i am correct it will go beyond = normal ~31Gb individual data file size limit. Correct me if I'm wrong. =20 And then in this case , can it go beyond defined max_bytes? Or is it = that at the point when it reaches ~160GB size it throws an ora-30036 = error and then someone has increased the size to ~200GB but it's not = updated in dba_data_files? But in any scenario, is behaviour of UNDO = different if we have AUTO EXTEND ON with defined max_size(i.e. our = current setup) VS Autoextend OFF with the same max_size? =20 On Wed, Sep 8, 2021 at 7:39 PM Mark W. Farnham wrote: If you have a single file limited to 160 and it is already 200, it seems = to me that file cannot extend. If you have reached 200, then I would = expect it to go splat failing to extend with autoextend on, because it = fails the maxbytes limit. =20 Since the file is already bigger than what someone probably set it down = to later, the maxbytes seems like a red herring and autoextend could = only come into play if you added a file. =20 mwf =20 From: oracle-l-bounce@freelists.org = [mailto:oracle-l-bounce@freelists.org] On Behalf Of Lok P Sent: Wednesday, September 08, 2021 9:00 AM To: Hemant K Chitale Cc: John Piwowar; Oracle L Subject: Re: Undo Tablespace Error =20 Thank you Hemant. =20 to your point "Besides dba_hist_tbsp_space_usage you should also look at = v$undostat" =20 This error occurred to us 4-5days ago. So from min(begin_time) , I am = seeing it doesn't have those time data in v$undostat anymore. So is = there another way to dig into history? =20 If i see current values in v$parameter, We have UNDO_MANGEMENT set as = AUTO undo_retention set as 3600. If I see current values in = dba_data_files we have only one data file for the UNDo tablespace. and = it has BYTES as 200GB, MAXBYTES- 160GB, USER_BYTES- 200GB, = Autoextensible- YES. So in this case do you suggest just by turning OFF = the AUTOEXTEND , we should be good to avoid this issue in future?=20 =20 But I had one question, even if we have AUTOEXTEND ON, as we have = defined the MAXBYTES as ~160GB for that data file, so that is as good as = AUTOEXTEND OFF having same maxBytes as ~160GB as because in both of the = cases it can't go beyond 160GB. Is my understanding wrong here? =20 On Wed, Sep 8, 2021 at 8:14 AM Hemant K Chitale = wrote: =20 If you have AUTOEXTEND ON it is likely that the datafile had already = hit the MAXSIZE. So this would result in failure 6 in Oracle Support document " = Troubleshooting ORA-30036 - Unable To Extend Undo Tablespace (Doc ID = 460481.1) =20 Besides dba_hist_tbsp_space_usage you should also look at v$undostat (also in earlier versions dba_hist_tbsp_space_usage had bugs in = reporting Tablespace Usage for Undo tablespaces) =20 As John says, if you have AUTOEXTEND ON, Oracle will try to keep = extending Undo retention. Setting a max size for the datafiles and then = setting AUTOEXTEND OFF is better. Hemant K Chitale =20 =20 On Mon, Sep 6, 2021 at 2:59 AM Lok P wrote: Thank You John. I understand your point that with AUTOEXTENSIBLE YES = oracle may tend to keep the expired UNDO longer to satisfy retention = thereby increasing the UNDO tablespace to higher size. But , If we will = talk specifically about the exact error here , isn't it true that with = AUTOEXTENSIBLE YES, it should not have made it errored out with = Ora-30036 rather it would have thrashed/increased UNDO tablespace size = by its own? =20 Also as I see from dba_hist_tbspc_space_usage , the UNDO = usage(tablespace_usedsize) was ~160GB which was equal to tablespace_size = when it failed with ora-30036 , but then it increased to ~200GB after = 4-5hrs, yet to see if somebody has increased it manually or it increased = by itself. =20 On Sun, Sep 5, 2021 at 2:53 AM John Piwowar wrote: The =E2=80=9Cautoextensible=E2=80=9D setting on your undo data files is = possibly the culprit here. Undo segments are a bit of a special case, = and Oracle=E2=80=99s decision-making about when to reclaim expired undo = can be thrown off when it thinks it has the option to extend a data file = instead. It=E2=80=99s possible that you might still need to resize your = undo to accommodate recent changes in your workload, but you=E2=80=99re = better off with fixed-size undo datafiles, followed by an examination of = your automatic undo configuration (undo_retention, etc).=20 =20 Sorry about the vagueness of the response; I=E2=80=99m on my phone and = can=E2=80=99t get decent references with my thumbs. :) =20 On Sat, Sep 4, 2021 at 1:05 PM Lok P wrote: Hello Listers, In one of our 12.1 version databases, a few days back we = encountered an error- "Ora-30036 Unable to extend segment by 128 in = tablespace 'UNDOTBS1'" for a delete query. This failure has never = happened before. And we were trying to see if we really have to increase = the size of UNDO tablespace(current size is ~200GB) as it has other = impacts like making long running queries run even longer before hitting = ora-01555/snapshot too old etc. Or anyway we can track and fix the long = transactions which might have consumed large UNDO during that time and = then we can try to break that into small transactions? =20 Another thing I notice in the dba_data_files is now showing = autoextensible as YES, so how come this query errored out with = Ora-30036/space issues? =20 The USED space in dba_hist_tbspc_space_usage for this UNDO tablespace is = sometimes showing completely full and sometimes it's a lot empty and i = believe it's because of a circular buffer. =20 =20 --=20 Regards, John P. (Typed with thumbs on a mobile device. Lowered = expectations appreciated) ------=_NextPart_000_1622_01D7A558.76B1D530 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I don=E2=80=99t know whether there is a different error fall back = order. I thought the error was failing to extend, so I can conceive that = it might not try to extend with autoextend off and tell you it ran out = of space in undo instead of trying to extend and = failing.

 

It would give me the willies to have maxbytes smaller than the actual = size, but that is just because it doesn=E2=80=99t make sense to me. = Without the source code the only way to determine the behavior of the = running code is to do an enumerative case test seeing what = happens.

 

My experiments with UNDO were long ago and I never bothered with the = cases that didn=E2=80=99t make sense to me to allow, so I cannot = definitively answer your question.

 

In your situation, and assuming space is available, I would create a = new UNDO that was for sure internally consistent with the values you = want and then alter that online and wait for the current one to be = completely inactive and eventually drop it. After that, with all the = values making sense and being internally consistent, I would expect = behavior to be easily predictable.

 

IF your shop is somehow attached to the nomenclature of the current = UNDO, you can replace UNDO twice to get back to the original name, but = be patient with the complete clearing of the one you=E2=80=99re going to = drop and recreate (it won=E2=80=99t drop until all transactions are = complete, but it might let you kill read only queries to drop it, the = same as running out of retention time.) I=E2=80=99m a bit rusty on = this.

 

Other than running away from file corruption errors, the only other = reason to rotate UNDO was back when a variety of storage performance = classes made sense with very large history that didn=E2=80=99t need = super speed and intermittent large transaction batches that benefitted = from very fast (like SSD versus spinning rust) speeds. Then you briefly = switched to the fast stuff, started the batch transaction, and = immediately switched back. That would put your performance requiring = transaction on the fast stuff (possibly along with a few other things = that happened to start before the switch back) and then do the mundane = stuff on the routine UNDO. The operations control to mesh that was = rarely worth the trouble and some folks from Oracle mentioned they had = deeply tested switching but had not deeply tested switching back. It = never failed that I saw in some cases that were bigger than a bread box. = In the days when SSD was extremely expensive compared to spinning rust, = it was sometimes worth it to do more complex operations to buy less of = it and get the same benefit.

 

I doubt any of that applies to you. I suppose with the enormous RAM = sizes we have now and private designations, if you have an operating = system with duplex RAM for error control putting some UNDO on RAM might = be useful. If Oracle wants me to do that experiment for them, = I=E2=80=99m all ears.

 

Good luck.

 

From:= = Lok P [mailto:loknath.73@gmail.com]
Sent: Wednesday, = September 08, 2021 11:39 PM
To: Mark W. Farnham
Cc: = Hemant K Chitale; John Piwowar; Oracle L
Subject: Re: Undo = Tablespace Error

 

Thank = you. I will try to see the alert log for more = details. 

 

But if my understanding is correct , in current = scenario with maxsize being set there is no difference in undo behaviour = if we keep the data file as either Autoextend ON or OFF. Correct me if = wrong?

 

On = Wed, 8 Sep 2021, 11:12 pm Mark W. Farnham, <mwf@rsiz.com> = wrote:

We cannot tell from the apparent information presented HOW it got to = 200. But it should not be able to extend beyond the set MAXBYTES. The = behavior I would have built is to complain if you try to set maxbytes = lower than an already existing size for a file. If you keep logs of the = manual intervention sections (at least) or complete alert logs for at = least the system, then you might discover how it got to = 200.

 

Yes, you ARE within the limits of bigfile, presuming that more space = is available on the storage volume. NO, it should not autoextend if it = is at or beyond the MAXBYTES defined for the file, and tossing the error = you are seeing seems correct behavior to me.

 

Sigh.

 

From:= = Lok P [mailto:loknath.73@gmail.com]
Sent: Wednesday, = September 08, 2021 12:13 PM
To: Mark W. Farnham
Cc: = Hemant K Chitale; John Piwowar; Oracle L
Subject: Re: Undo = Tablespace Error

 <= /o:p>

I see it's = a bigfile tablespace. And if i am correct it will go beyond normal ~31Gb = individual data file size limit. Correct me if I'm = wrong.

 <= /o:p>

And then in = this case , can it go beyond defined max_bytes? Or is it that at the = point when it reaches ~160GB size it throws an ora-30036 error and = then someone has increased the size to ~200GB but it's not updated in = dba_data_files? But in any scenario, is behaviour of UNDO different if = we have AUTO EXTEND ON with defined max_size(i.e. our current setup) VS = Autoextend OFF with the same max_size?

 <= /o:p>

On Wed, Sep = 8, 2021 at 7:39 PM Mark W. Farnham <mwf@rsiz.com> = wrote:

If you have a single file limited to 160 and it is already 200, it = seems to me that file cannot extend. If you have reached 200, then I = would expect it to go splat failing to extend with autoextend on, = because it fails the maxbytes limit.

 

Since the file is already bigger than what  someone probably set = it down to later, the maxbytes seems like a red herring and autoextend = could only come into play if you added a file.

 

mwf

 

From:= = oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of = Lok P
Sent: Wednesday, September 08, 2021 9:00 = AM
To: Hemant K Chitale
Cc: John Piwowar; Oracle = L
Subject: Re: Undo Tablespace Error

 <= /o:p>

Thank you = Hemant.

 <= /o:p>

to your = point "Besides dba_hist_tbsp_space_usage you should also look at = v$undostat"

 <= /o:p>

This error = occurred to us 4-5days ago. So from min(begin_time) , I am seeing = it doesn't have those time data in v$undostat anymore. So is there = another way to dig into history?

 <= /o:p>

If i see = current values in v$parameter, We have UNDO_MANGEMENT set as AUTO  = undo_retention set as 3600. If I see current values in dba_data_files we = have only one data file for the UNDo tablespace. and it has BYTES as = 200GB, MAXBYTES- 160GB, USER_BYTES- 200GB, Autoextensible- YES. So in = this case do you suggest just by turning OFF the AUTOEXTEND , we should = be good to avoid this issue in future? 

 <= /o:p>

But I had = one question, even if we have AUTOEXTEND ON, as we have defined the = MAXBYTES as ~160GB for that data file, so that is as good as AUTOEXTEND = OFF having same maxBytes as ~160GB as because in both of the cases it = can't go beyond 160GB. Is my understanding wrong = here?

 <= /o:p>

On Wed, Sep = 8, 2021 at 8:14 AM Hemant K Chitale <hemantkchitale@gmail.com> = wrote:

 <= /o:p>

If you have = AUTOEXTEND ON  it is likely that the datafile had already hit the = MAXSIZE.

So this = would result in failure 6 in Oracle Support document " = = Troubleshooting ORA-30036 - Unable To Extend Undo Tablespace (Doc ID = 460481.1)

 <= /o:p>

Besides = dba_hist_tbsp_space_usage you should also look at = v$undostat

(also in = earlier versions dba_hist_tbsp_space_usage had bugs in reporting = Tablespace Usage for Undo tablespaces)

 <= /o:p>

As John = says, if you have AUTOEXTEND ON,  Oracle will try to keep extending = Undo retention.  Setting a max size for the datafiles and then = setting AUTOEXTEND OFF is better.


Hemant K = Chitale

 <= /o:p>

 <= /o:p>

On Mon, Sep = 6, 2021 at 2:59 AM Lok P <loknath.73@gmail.com> = wrote:

Thank You = John. I understand your point that with AUTOEXTENSIBLE YES oracle may = tend to keep the expired UNDO longer to satisfy retention thereby = increasing the UNDO tablespace to higher size. But , If we will talk = specifically about the exact error here , isn't it true that = with AUTOEXTENSIBLE YES, it should not have made it errored out = with Ora-30036 rather it would have thrashed/increased UNDO tablespace = size by its own?

 <= /o:p>

Also as I = see from dba_hist_tbspc_space_usage , the UNDO = usage(tablespace_usedsize) was ~160GB which was equal to tablespace_size = when it failed with ora-30036 , but then it increased to ~200GB after = 4-5hrs, yet to see if somebody has increased it manually or it = increased by itself.

 <= /o:p>

On Sun, Sep = 5, 2021 at 2:53 AM John Piwowar <jpiwowar@gmail.com> = wrote:

The = =E2=80=9Cautoextensible=E2=80=9D setting on your undo data files is = possibly  the culprit here. Undo segments are a bit of a special = case, and Oracle=E2=80=99s decision-making about when to reclaim expired = undo can be thrown off when it thinks it has the option to extend a data = file instead. It=E2=80=99s possible that you might still need to resize = your undo to accommodate recent changes in your workload, but = you=E2=80=99re better off with fixed-size undo datafiles, followed by an = examination of  your automatic undo configuration (undo_retention, = etc). 

 <= /o:p>

Sorry about = the vagueness of the response; I=E2=80=99m on my phone and can=E2=80=99t = get decent references with my thumbs. :)

 <= /o:p>

On Sat, Sep = 4, 2021 at 1:05 PM Lok P <loknath.73@gmail.com> = wrote:

Hello = Listers, In one of our 12.1 version databases, a few days back we = encountered an error- "Ora-30036 Unable to extend segment by 128 in = tablespace 'UNDOTBS1'" for a delete query. This failure has never = happened before. And we were trying to see if we really have to increase = the size of UNDO tablespace(current size is ~200GB) as it has other = impacts like making long running queries run even longer before = hitting ora-01555/snapshot too old etc. Or anyway we can track and fix = the long transactions which might have consumed large UNDO during that = time and then we can try to break that into small = transactions?

 <= /o:p>

Another = thing I notice in the dba_data_files is now showing autoextensible as = YES, so how come this query errored out with Ora-30036/space = issues?

 <= /o:p>

The USED = space in dba_hist_tbspc_space_usage for this UNDO tablespace is = sometimes showing completely full and sometimes it's a lot empty = and i believe it's because of a circular = buffer.

 <= /o:p>

 <= /o:p>

-- =

Regards, = John P. (Typed with thumbs on a mobile device. Lowered expectations = appreciated)

=
------=_NextPart_000_1622_01D7A558.76B1D530-- -- http://www.freelists.org/webpage/oracle-l