From oracle-l-bounce@freelists.org Fri Nov 26 20:42:22 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id iAR2gMg09080 for ; Fri, 26 Nov 2004 20:42:22 -0600 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id iAR2gLx09075 for ; Fri, 26 Nov 2004 20:42:21 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id CF95172C49A; Fri, 26 Nov 2004 21:48:42 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24220-100; Fri, 26 Nov 2004 21:48:42 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 57AD572C4B7; Fri, 26 Nov 2004 21:48:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Subject: RE: fetch across commit Date: Fri, 26 Nov 2004 21:47:03 -0500 Message-ID: <4001DEAF7DF9BD498B58B45051FBEA6501DFA409@25exch1.vicorpower.vicr.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: fetch across commit Thread-Index: AcTTUF5B74O4AszgTIKPzXSQXJeyCgA2dp/g From: "Goulet, Dick" To: "Oracle List" X-OriginalArrivalTime: 27 Nov 2004 02:47:03.0971 (UTC) FILETIME=[606DD730:01C4D42B] X-archive-position: 12827 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: DGoulet@vicr.com Precedence: normal Reply-To: DGoulet@vicr.com X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org Seems you've asked this question twice now, which means you did not understand the answer the first time. OK; the short answer is yes it can cause an ORA-1555 error. The reason is that when you opened the cursor Oracle captured the current SCN, say 100. You've done several updates/inserts/deletes based on the logic of your program and done a commit, which changed the SCN to say 105. In doing so you've told Oracle that you are no longer interested in any rollback segments before SCN 105, when in fact you are. Immediately that is not a problem, but sooner or later part of your cursor will need to recreate a data row to SCN 100 with rollback data. Problem is that you've let it go & consequently Oracle cannot create a read consistent view as of SCN 100 & you get ORA-01555. One trick I've used rather successfully in the past is to put an "order by" clause on the cursor statement. Order By causes a sort, which means Oracle has to find all of the data that your cursor will need and sort it before handing you the first row. Now all of your return rows are stored in a temp table in the Temp tablespace & no more rollback or read consistent view activity is needed. It's a hack I'll admit, but one that appears to work 90% of the time.=20 Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -----Original Message----- From: ryan_gaffuri@comcast.net [mailto:ryan_gaffuri@comcast.net]=20 Sent: Wednesday, November 24, 2004 1:53 PM To: zimsbait@gmail.com; Oracle List Cc: z b Subject: Re: fetch across commit yes, because a commit releases the lock on the rollback segments and orac=3D le can overwrite them with another process.=3D20 -------------- Original message --------------=3D20 > Listers,=3D20 >=3D20 > I have a question where I need a little clarification about fetching ac=3D ross=3D20 > commits. Can this happen if the table being committed to is not the sam=3D e=3D20 > as the tables(s) in the cursors?=3D20 >=3D20 > For example, if I had :=3D20 > cursor c1 is select empname form emp where=3D20 > dept =3D3D 100;=3D20 -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l