UNDO poll - was undo segments vs. rbs 2004-05-20 - By Patamalla, Chaya
I use UNDO, however I still got the famous ORA-01555 (See ORA-01555.ora-code.com). 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 (See ORA-01555.ora-code.com). 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@(protected)=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@(protected) =
[mailto:oracle-l-bounce@(protected)] On Behalf Of Mladen Gogala
Sent: Thursday, May 20, 2004 1:15 PM
To: oracle-l@(protected)
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@(protected) wrote:
> oracle-l-bounce@(protected) 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@(protected)
put 'unsubscribe ' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://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@(protected)
put 'unsubscribe ' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
|
|
