RE: checkpoint incomplete issue

  • From: "Cary Millsap" <cary.millsap@xxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Sat, 20 Nov 2004 11:17:17 -0600

I've said it many times, many ways... You /cannot/ predict whether a
candidate performance improvement investment will produce a relevant
improvement by looking at a Statspack report. It is mathematically
impossible.


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: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Alexander Gorbachev
Sent: Saturday, November 20, 2004 3:11 AM
To: Cary Millsap; oracle-l@xxxxxxxxxxxxx
Subject: Re: checkpoint incomplete issue

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
<cary.millsap@xxxxxxxxxx> 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@xxxxxxxxx]
> Sent: Friday, November 19, 2004 4:42 PM
> To: cary.millsap@xxxxxxxxxx
> 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.
>
--
//www.freelists.org/webpage/oracle-l

--
//www.freelists.org/webpage/oracle-l

Other related posts: