Hi, Dick Your theory is right and I am aware of it. But it does not help. Unfortunately, in our case, mostly it is database very active, and one SQL execute too long. SQL is sometimes iin-efficient and it timed out with 1555. I need to find out the original SQL and contact PD for a solution.
On 10/5/05, Goulet, Dick <DGoulet@(protected)> wrote: > > You've found the statement that errored out in the alert log. The reason > is one of two things that you now need to figure out. The first is the > infamous commit across a cursor problem which can be found from a review of > the application code. The other is a resource issue that you may or may not > be able to solve. The query in question start out life with a particular > SCN. Over the time of it's execution data under it was changed and those > changes committed. Now normally your UNDO or ROLLBACK segments will retain > the changes so that Oracle can reconstruct what those rows looked like for > this query. The problem is that those undo or rollback segments are no > longer available. Now commits across a cursor do this because you yourself > have released the data and according to the ANSI Sql standard you should > close & reopen the cursor. The other half of it is either a lack of undo or > rollback space on your database or a query that just takes way too long to > run. >
<div>Hi, Dick <br> Your theory is right and I am aware of it. But it does not help.</div> <div> Unfortunately, in our case, mostly it is database very active, and one SQL execute too long. SQL is sometimes iin-efficient and it timed out with 1555. I need to find out the original SQL and contact PD for a solution. </div> <div> <br> </div> <div><span class="gmail_quote">On 10/5/05, <b class="gmail_sendername">Goulet, Dick</b> <<a href="mailto:DGoulet@(protected)">DGoulet@(protected)</a>> wrote:< /span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0 .8ex; BORDER-LEFT: #ccc 1px solid"> <div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2" >You've found the statement that errored out in the alert log. The reason is one of two things that you now need to figure out. The first is the infamous commit across a cursor problem which can be found from a review of the application code. The other is a resource issue that you may or may not be able to solve. The query in question start out life with a particular SCN. Over the time of it's execution data under it was changed and those changes committed. Now normally your UNDO or ROLLBACK segments will retain the changes so that Oracle can reconstruct what those rows looked like for this query. The problem is that those undo or rollback segments are no longer available. Now commits across a cursor do this because you yourself have released the data and according to the ANSI Sql standard you should close & reopen the cursor. The other half of it is either a lack of undo or rollback space on your database or a query that just takes way too long to run. </font></span></div></blockquote></div><br><br clear="all"><br>-- <br>Regards <br>Zhu Chao<br><a href="http://www.cnoug.org">www.cnoug.org</a><br>
