RE: UNDO poll - was undo segments vs. rbs
- From: "Patamalla, Chaya" <chaya.patamalla@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 20 May 2004 13:30:36 -0500
I use UNDO, however I still got the famous ORA-01555. The funny thing is =
it happened during an analyze and it was consistent. I was using =
dbms_stats procedure. Every day, when the analyze job ran, I had an =
ORA-01555. Metal link explained it as delayed block cleant out. Check =
the metal link paper:40689.1. This is a good article and I cannot =
explain better than this paper. Kirtikumar has a good paper which he =
presented at IOUG - 2004 about Undos.
Bottom line, I increased the undo_retention and that fixed the problem.
My two cents experience
Chaya Patamalla=20
I/T Sr.Database Administrator=20
Tel=A0 913-1336=20
email=A0 chaya.patamalla@xxxxxxxx=A0=A0=A0=A0=A0=A0=20
--"The opinions expressed herein are solely the author's and are not =
necessarily the opinion of USAA."=A0--=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx =
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mladen Gogala
Sent: Thursday, May 20, 2004 1:15 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: UNDO poll - was undo segments vs. rbs
The only compelling reason is to forget about RBS is
to stop managing. As things "AUTO" usually take more space
then manually managed things, so I decided that the adjustment=20
factor is 100% (disks are cheap, as long as I don't have
to actually pay for them). It worked. I don't manage
RBS any more and I don't have any waits on undo segment space.
On 05/20/2004 12:56:22 PM, Jared.Still@xxxxxxxxxxx wrote:
> oracle-l-bounce@xxxxxxxxxxxxx wrote on 05/20/2004 05:52:29 AM:
> Mladen, you're just showing off.
>=20
> Personally I can't partake in the poll. I have yet to see
> a compelling reason to change upgraded 9.2 databases from
> RBS to UNDO.
One of the reasons is to stop managing and start living?=20
--=20
Mladen Gogala
Oracle DBA
Note:
This message is for the named person's use only. It may contain =
confidential, proprietary or legally privileged information. No =
confidentiality or privilege is waived or lost by any mistransmission. =
If you receive this message in error, please immediately delete it and =
all copies of it from your system, destroy any hard copies of it and =
notify the sender. You must not, directly or indirectly, use, disclose, =
distribute, print, or copy any part of this message if you are not the =
intended recipient. Wang Trading LLC and any of its subsidiaries each =
reserve the right to monitor all e-mail communications through its =
networks.
Any views expressed in this message are those of the individual sender, =
except where the message states otherwise and the sender is authorized =
to state them to be the views of any such entity.
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
