From oracle-l-bounce@freelists.org Sat Nov 20 03:11:39 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id iAK9BGA21799 for ; Sat, 20 Nov 2004 03:11:26 -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 iAK9B4i21770 for ; Sat, 20 Nov 2004 03:11:15 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 38C5472C205; Sat, 20 Nov 2004 04:17:13 -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 25928-09; Sat, 20 Nov 2004 04:17:12 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id C49F072C200; Sat, 20 Nov 2004 04:14:55 -0500 (EST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=L50dyqVQ39Q1ec6GNjHVKKt9JryrYx209iujBMqo9ru5anTnHMfZO7d6TCeUcmwguhwODl/Cg/Wj5mxiN4N4wC8zuPok8Y4uDLpwJWujxEocWwmkIrvIYkI4PGSr7NDzqMPPHAl3izT+nIpw2WMm9xen8KSkXdX9beGsu5Lmi1w= Message-ID: Date: Sat, 20 Nov 2004 10:11:19 +0100 From: Alexander Gorbachev To: Cary Millsap , oracle-l@freelists.org Subject: Re: checkpoint incomplete issue In-Reply-To: <008401c4ce89$d1e34370$6400a8c0@CVMLAP02> Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit References: <008401c4ce89$d1e34370$6400a8c0@CVMLAP02> X-archive-position: 12503 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: gorbyx@gmail.com Precedence: normal Reply-To: gorbyx@gmail.com X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org Right. So there is a tradeof between concept of reusing open cursors to avoid even soft parsing and amount of redo logs generated. Unfortunately, some time ago there was a recomendation to avoid soft parses which were _too_high_ in a statspack report. On the other hand, I coundn't see that soft parses were really bad for the system - CPU consuption was relatively low and no visible latches contention. So this suggestion was something like "you have too many extents - it's bad". -- Best regards, Alex Gorbachev On Fri, 19 Nov 2004 16:47:59 -0600, Cary Millsap wrote: > Yes, of course. And it would be practically impossible to write shareable > SQL that would allow for the update of: > > Just column 1 > Just column 2 > ... > Just column n > Just columns 1 and 2 > Just columns 1 and 3 > ... > Just columns 1 and n > Just columns 1, 2, and 3 > Just columns 1, 2, and 4 > ... > Columns 1, 2, 3, ..., and n > > Unimaginable, really. But doing nothing about the problem results in exactly > what you've observed. A developer ought to at least be able to branch around > the update if /none/ of the columns' values have changed. > > > > > Cary Millsap > Hotsos Enterprises, Ltd. > http://www.hotsos.com > * Nullius in verba * > > Upcoming events: > - Performance Diagnosis 101: 1/4 Calgary > - SQL Optimization 101: 11/8 Dallas, 12/13 Atlanta > - Hotsos Symposium 2005: March 6-10 Dallas > - Visit www.hotsos.com for schedule details... > > -----Original Message----- > From: Alexander Gorbachev [mailto:gorbyx@gmail.com] > Sent: Friday, November 19, 2004 4:42 PM > To: cary.millsap@hotsos.com > Subject: Re: checkpoint incomplete issue > > We have recently figured that out on one of our applications. > Developers were "smart" enough updating the whole record (tens of > fields) when even one was changed. Sometimes there are cases when > nothing changed, but update to the whole row is made. Of course, this > would be difficult to address for packaged applications or similar > situation. > -- http://www.freelists.org/webpage/oracle-l