| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Please help with ORA-01555 Snapshot too old
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C35074.69AD2850
Content-Type: text/plain;
charset="iso-8859-1"
You can try committing less frequently in the batch load e.g. if you are
committing every 10000 rows then try every 30000 (assuming of course that
the you have space left in the RBS to allow for this) or you can try adding
rollback segments.
Metalink docs give some good ideas as to the real causes of this error. The
error message text itself is sometimes misleading.
Cheers
Lindsay
-----Original Message-----
From: Smith, Ron L. [mailto:rlsmith_at_kmg.com]
Sent: Tuesday, July 22, 2003 5:04 PM
To: Multiple recipients of list ORACLE-L
Subject: Please help with ORA-01555 Snapshot too old
Help!
I have a production and a test database, both with 3000mg RBS tablespaces with two datafiles. Both have db_block_buffers set at 1000. The only difference is the production db has 7 rollback segments and the test db has 8. The rollback segments are sized at 50mg each on both databases.
The problem is, at night when the batch load is running (by itself), the load fails with a ORA-01555. The data is the same on both loads. Nothing else is going on in the database during the load.
Any ideas?
Ron
For information about the Standard Bank group visit our web site <www.standardbank.co.za>
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relating to the official business of Standard Bank Group Limited is proprietary to the group.
It is confidential, legally privileged and protected by law.
Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.
The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read,
disclose or use the content in any way.
Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference.
------_=_NextPart_001_01C35074.69AD2850
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885=
9-1">
<TITLE>Message</TITLE>
<META content=3DWord.Document name=3DProgId> <META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR> <META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20href=3D"cid:filelist.xml_at_01C35074.4A7F7000" rel=3DFile-List><!--[if gte m= so 9]><xml>
</STYLE> </HEAD> <BODY lang=3DEN-US style=3D"tab-interval: .5in" vLink=3Dblue link=3Dblue>=
<DIV><SPAN class=3D830361317-22072003><FONT face=3DArial color=3D#0000ff =
size=3D2>You=20
can try committing less frequently in the batch load e.g. if you are comm=
itting=20
every 10000 rows then try every 30000 (assuming of course that the you ha=
ve=20
space left in the RBS to allow for this) or you can try adding rollback=20
segments.</FONT></SPAN></DIV>
<DIV><SPAN class=3D830361317-22072003><FONT face=3DArial color=3D#0000ff =
size=3D2>Metalink docs give some good ideas as to the real causes of=
=20this=20
error. The error message text itself is sometimes=20
misleading.</FONT></SPAN></DIV>
<DIV><SPAN class=3D830361317-22072003><FONT face=3DArial color=3D#0000ff =
size=3D2>Cheers</FONT></SPAN></DIV>
<DIV><SPAN class=3D830361317-22072003><FONT face=3DArial color=3D#0000ff =
size=3D2>Lindsay</FONT> </SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
=20 <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT face=3D=
Tahoma=20
=20 size=3D2>-----Original Message-----<BR><B>From:</B> Smith, Ron L.=20
=20 [mailto:rlsmith_at_kmg.com]<BR><B>Sent:</B> Tuesday, July 22, 2003 5:04 =
=20 PM<BR><B>To:</B> Multiple recipients of list ORACLE-L<BR><B>Subject:<=
/B>=20
=20 Please help with ORA-01555 Snapshot too old<BR><BR></FONT></DIV>
=20 <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
=20 class=3D164575713-22072003>Help!</SPAN></FONT></DIV>
=20 <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
=20 class=3D164575713-22072003></SPAN></FONT> </DIV>
=20 <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN class=3D164575=
713-22072003>I=20
=20 have a production and a test database, both with 3000mg RBS tablespac=
es with=20
=20 two datafiles. Both have db_block_buffers set at 1000. Th=
e only=20
=20 difference is the production db has 7 rollback segments and the&=
nbsp;test=20
=20 db has 8. The rollback segments are sized at 50mg each on both =
=20 databases.</SPAN></FONT></DIV>
=20 <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
=20 class=3D164575713-22072003></SPAN></FONT> </DIV>
=20 <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN class=3D164575=
713-22072003>The=20
=20 problem is, at night when the batch load is running (by itself), the =
load=20
=20 fails with a ORA-01555. The data is the same on both loads.&nbs=
p;=20
=20 Nothing else is going on in the database during the load.</SPAN></FON=
T></DIV>
=20 <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
=20 class=3D164575713-22072003></SPAN></FONT> </DIV>
=20 <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN class=3D164575=
713-22072003>Any=20
=20 ideas?</SPAN></FONT></DIV>
=20 <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
=20 class=3D164575713-22072003></SPAN></FONT> </DIV>
=20 <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
=20 class=3D164575713-22072003>Ron</SPAN></FONT></DIV>
=20 <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
=20 <DIV></DIV>
=20 <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dle=
ft><![if !supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif= ]><![if !supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]= ><![if !supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]>= <![if !supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]><= ![if !supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]><!= [if !supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]><![=if !supportEmptyParas]><![endif]><FONT=20
color=3D#0000ff>_________________________________________________________= _________________________________________________________________________=</FONT></DIV>
color=3D#0000ff>_________________________________________________________= _________________________________________________________________________=<BR> <BR></FONT>Disclaimer=20
protected by law. <BR>Standard Bank does not own and endorse any other co=
ntent.=20
Views and opinions are those of the sender unless clearly stated as being=
=20that=20
of the group. <BR>The person addressed in the e-mail is the sole authoris=
ed=20
recipient. Please notify the sender immediately if it has unintentionally=
=20
reached you and do not read, <BR>disclose or use the content in any=20
way.<BR>Standard Bank can not assure that the integrity of this communica=
tion=20
has been maintained nor that it is free of errors, virus, interception or=
=20
interference.<BR><FONT=20
Received on Tue Jul 22 2003 - 12:12:21 CDT
 |
 |