> I'm having an ora-1555 under Oracle9 database and not
> sure what I can do to get rid of it. I had some
> recollecions from Oracle8 days , but the things like
> adding a new rollback segment or shrinking the
> segments I don't think are applicable under the auto
&
Hi all:
I'm having an ora-1555 under Oracle9 database and not
sure what I can do to get rid of it. I had some
recollecions from Oracle8 days , but the things like
adding a new rollback segment or shrinking the
segments I don't think are applicable under the auto
undo managemen
I'm not using AUM on my production databases because they're still 8.1.7.
To tell the truth, I haven't seen any major patches for AUM in the 9iR2.
Well, when Oxford goes to 9.2, I guess AUM is an option. I'm still
paranoid about the new features. I believe that progress does bad things
to the lamb
I am using AUM in our Test/Acceptance databases with no problems at all. This month it
will be
rolled out to a couple of production databases.
FBQ is another matter altogether :)
MUM (manual undo mgmt) was a depreacted option when 9i R1 came out. I won't be
surprised if only
AUM would be avail
Oh no, we agree. I wouldn't do automatic undo management, either. V$ROLLSTAT is
perfectly good for me. I'll wait for the version 10 to intorduce AUM to my databases.
On 2003.06.06 21:54 Daniel W. Fink wrote:
> Mladen,
> I could not agree more! I seriously pondered not posting this
> inform
we are using AUM pretty successfully for our production systems.
Interestingly enough the one problem we did have was on a test box, and
we couldn't repeat it
--- "Daniel W. Fink" <[EMAIL PROTECTED]> wrote:
> Mladen,
> I could not agree more! I seriously pondered not posting this
> informati
Mladen,
I could not agree more! I seriously pondered not posting this information
at all. FBQ is a nice feature, but I would not depend upon it. I'm a conservative
and somewhat paranoid DBA and I would not recommend AUM for production systems,
though certain very knowledgable and respected
"Daniel W. Fink" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
06/06/2003 03:20 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject:Re: A new form of ORA-1555
Mladen,
That is a comm
Well,
I've read a lot of that on this list (this is not the first time FBQ is being
discussed) but as a
conservative and somewhat paranoid DBA, I don't want to
try anything that isn't supported with a
very
new feature like FBQ. The experience taught me a lesson about ora-600 and alike.
I re
Mladen,
That is a common misconception, one that Oracle wholeheartedly supports.
Flashback Query (FBQ) depends upon the smon_scn_time table, which is popluated
in 9i, regardless of the undo_management setting. This table is populated
regardless of the UNDO_RETENTION parameter. This paramete
> Ruth Gramolini wrote:
>
> > It might have something to do with setting the table to do a Flashback
> > query. Maybe Dan will know.
> >
> > Ruth
> >
> > - Original Message -
> > From: Jamadagni, Rajendra <mailto:[EMAIL PROTECTED
- Original Message -
> > From: Jamadagni, Rajendra <mailto:[EMAIL PROTECTED]>
> > To: Multiple recipients of list ORACLE-L
> > <mailto:[EMAIL PROTECTED]>
> > Sent: Friday, June 06, 2003 10:00 AM
> > Subject: A new form of ORA-15
To:
Multiple
recipients of list ORACLE-L
Sent:
Friday, June 06, 2003 10:00 AM
Subject:
A new form of ORA-1555
A sighting in alert log ...
SMON offlining US=102 SMON offlining US=104 Fri Jun 6 08:42:06 2003 ORA-01555 caused by SQL statement be
Fink
http://www.optimaldba.com
Ruth Gramolini wrote:
A new form of ORA-1555
It might have something to do with setting
the table to do a Flashback query. Maybe Dan will know.
Ruth
-
Original Message -
From:
Jamadagni, Rajendra
Title: A new form of ORA-1555
It might have something to do with setting the
table to do a Flashback query. Maybe Dan will know.
Ruth
- Original Message -
From:
Jamadagni, Rajendra
To: Multiple recipients of list ORACLE-L
Sent: Friday, June 06, 2003 10:00
AM
we ended up with an ORA-600 after lots of 'SMON offlining undo segment"
messages in the alert log. Happened only once, Support asked us to set
an event and trap it when/if it happens again
I'm beginning to think maybe I should have stuck with rollback segments
--- Kirtikumar Deshpande <[EMAIL PR
A classic case when AUM does not help prevent 1555 errors !
Query duration is MAXQUERYLEN reported in v$undostat view. SCN could be the 'as of SCN' when the query started (not sure, as I could never get my small tests to fail with 1555 when using AUM).
What is also interesting is the SMON act
Title: A new form of ORA-1555
A sighting in alert log ...
SMON offlining US=102
SMON offlining US=104
Fri Jun 6 08:42:06 2003
ORA-01555 caused by SQL statement below (Query Duration=41895 sec, SCN: 0x0010.c2bd0c24):
Fri Jun 6 08:42:06 2003
SELECT ROUND(G_1/:"SYS_B_00") G_1,
alter rollback segment XXX storage (optimal null);
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person
who can answer the questions, but the
person who can question the answers -- T. Schick Jr
One-day tutorials:
http://www.jlcomp.demon.co.uk/tutori
rollback segments? If so, I'd suggest you
> > remove the OPTIMAL clause and try again. In my
> > experience, I have had my share of hassles with
> > OPTIMAL. Even when it was sized 'reasonably large'
> > (way above INITIAL * MINEXTENTS) for the
> > ap
block clean
out" gotchas. In the specific case, the customer had
nobody on the system, after a shutdown, single user,
single session and was pulling his hair out with a
ORA-1555. Turns out the previous night, the objects in
the original READ-ONLY tablespace, was loaded with new
data, and the status
I have had my share of hassles with
> OPTIMAL. Even when it was sized 'reasonably large'
> (way above INITIAL * MINEXTENTS) for the
> application.
>
> OPTIMAL does increase the probability of ORA-1555,
> as
> extents of your rollback segments that have the
> "befor
MAL clause and try again. In my
experience, I have had my share of hassles with
OPTIMAL. Even when it was sized 'reasonably large'
(way above INITIAL * MINEXTENTS) for the application.
OPTIMAL does increase the probability of ORA-1555, as
extents of your rollback segments that have th
In general, you don't need to do this in
recent versions of Oracle. Oracle knows
that all the data in the tablespace MUST
have been committed before the tablespace
was switched to read-only (you can only
switch a tablspace to readonly when there
are no active transactions that started before
th
sized 'reasonably large'
(way above INITIAL * MINEXTENTS) for the application.
OPTIMAL does increase the probability of ORA-1555, as
extents of your rollback segments that have the
"before images" of your transactions, can get dropped,
while your queries are left "high and dry&qu
7;d like to approach
this from the application side, where I think the majority of the problem is
occurring. I've been tracking TPM based on "user commits" in V$SYSSTAT and
we spiked at 20K TPM just before the B.O. query in question ORA-1555'd.
>From STATSPACK reports, I think
t; extents in LMT), but until I can get time to do that, I'd like to approach
> this from the application side, where I think the majority of the problem is
> occurring. I've been tracking TPM based on "user commits" in V$SYSSTAT and
> we spiked at 20K TPM just bef
ke to approach
this from the application side, where I think the majority of the problem is
occurring. I've been tracking TPM based on "user commits" in V$SYSSTAT and
we spiked at 20K TPM just before the B.O. query in question ORA-1555'd.
>From STATSPACK reports, I think th
Sunny,
During
the hot backup, Oracle uses Log files and Rollback segments extensively if
writes are being performed against the objects in the tablespace currently in
HOT BACKUP.
That
explains ORA-1555 because the data in the rollback segments gets overwritten
pretty soon(causing
Hello,
We're trying to understand the reason behind this !!!
When we run a specific job against the database when it is in noarchivelog mode, it completes without a problem.
When we run the same job after we switch the database to Archivelog mode (and during a hot backup), we're seein
(408) 934 9310
-Original Message-
Sent: Monday, December 17, 2001 2:40 AM
To: Multiple recipients of list ORACLE-L
Hi list,
Could anybody tell me on which site shall I find Tim Gorman's paper "Cats,
Dogs and ORA-1555" ??
Thanks,
Samir
Samir Sarkar
Oracle DBA - Lennon Team
S
Gorman's paper "Cats,
Dogs and ORA-1555" ??
Thanks,
Samir
Samir Sarkar
Oracle DBA - Lennon Team
SchlumbergerSema
Email : [EMAIL PROTECTED]
[EMAIL PROTECTED]
Phone : +44 (0) 115 - 95 76217
EPABX : +44 (0) 115 - 957 6418 Ext. 76217
Fax : +44 (0)
www.evdbt.com
Best Regards,
K Gopalakrishnan
(408) 934 9310
-Original Message-
Sent: Monday, December 17, 2001 2:40 AM
To: Multiple recipients of list ORACLE-L
Hi list,
Could anybody tell me on which site shall I find Tim Gorman's paper "Cats,
Dogs and ORA-1555" ??
Hi list,
Could anybody tell me on which site shall I find Tim Gorman's paper "Cats,
Dogs and ORA-1555" ??
Thanks,
Samir
Samir Sarkar
Oracle DBA - Lennon Team
SchlumbergerSema
Email : [EMAIL PROTECTED]
[EMAIL PROTECTED]
Phone : +44 (0) 115 - 95 76217
EPABX : +44 (0)
Gene,
It was a few weeks ago that I was made aware of this paper. I must have
simply downloaded it from the site that was mentioned in the original E-mail
and printed it for future (i.e. now) reference. All I can tell you is that
there is an "About the Author" section on the last page which rel
mended by someone on this list, but I forget the
particulars of who actually recommended it and where I downloaded it.
However, the moral of the story of "Ora-1555" errors (as I see it) has to do
with the possibility of these occurring when (unpredictably) a query
transaction (T2) starts up
oesn't look real good to meam I correct???
> I will try processing
> without the optimal being set to see what happens,
> while I await other
> response.
>
> thanks!
> Christine
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[
Sent: Tuesday, December 04, 2001
2:50 PM
To: Multiple recipients of list
ORACLE-L
Subject: Rollbacks - ORA-1555
Greetings All
I am some what new to the
list, so forgive me if I don't have the proper etiquette in addressing my
issue. I have a database, 8.1.6, running on Windows NT,
Hello All,
I changed the rollback segments, and here are the results. I'm now at 20
segments, 1 meg each, minextents 20, optimal 20. Here are the results after
running the process within the application with auto-commits turned off...
data requests
-
2969079
CLASS
Christine,
Howdy neighbor. I've almost eliminated 1555's. It
took some trial and error, but what we ended up with in one of our bigger db's
is:
30 rollback segments
OPTIMAL (NULL)
minextents 20
initial = next = 4MB
6GB total space
We have between 400 and 500 interactive users, several
Hi Christine,
Your rollback segments look large to me based on the
description you have given for your application. One
way of eliminating header waits is to increase the
number of rbs .. try this and post if this helps your
stats..
1. Create total of 20 rollback segments
2. Specification for e
Title: RE: BMC Patrol DBXray / CA Unicenter
Greetings All
I am
some what new to the list, so forgive me if I don't have the proper etiquette in
addressing my issue. I have a database, 8.1.6, running on Windows NT, that
currently has 5 rollback segments. The specs are as follows for each
42 matches
Mail list logo
