From oracle-l-bounce@freelists.org Mon Jun 6 01:45:58 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j566jwqe016301 for ; Mon, 6 Jun 2005 01:45:58 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j566jvNi016296 for ; Mon, 6 Jun 2005 01:45:57 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id F1DA31BB152; Mon, 6 Jun 2005 00:42:48 -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 20868-08; Mon, 6 Jun 2005 00:42:48 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7A6E21BAF63; Mon, 6 Jun 2005 00:42:48 -0500 (EST) Message-ID: <42A3E1C5.4060009@itasoftware.com> Date: Mon, 06 Jun 2005 01:40:21 -0400 From: Henry Poras User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "oracle-l@freelists.org" Subject: redo stream Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-PMX-Version: 4.6.1.107272 X-archive-position: 20678 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: henry@itasoftware.com Precedence: normal Reply-To: henry@itasoftware.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,TO_ADDRESS_EQ_REAL autolearn=ham version=2.63 We got a Unique Constraint error in our application. I wanted to find the sql which caused this. Since I found out about the error a bit after the fact, my thoughts turned to using logminer. When thinking about this I wondered wether the SQL which caused the error would make it to the redo stream. If it did, the error would then need to be rolled back. But this would need to be a special kind of rollback, one which wouldn't terminate the transaction. So maybe the kernal would notice the error on checking and cancel the statement before it got to the redo stream. However, even if that happened in this case, what about ROLLBACK TO SAVEPOINT. These statements defiinitely make the redo stream. I'm putting together a test case, so I'll post what I find as soon as I can. (probably with other questions) Henry -- http://www.freelists.org/webpage/oracle-l