Re: What is lock type 'KO' in v$lock table?

From: Mladen Gogala <mgogala.spam-me-not_at_verizon.net>
Date: Sun, 24 Sep 2006 16:00:30 GMT
Message-Id: <pan.2006.09.24.16.00.13.82677@verizon.net>

On Sun, 24 Sep 2006 08:04:11 +0100, Jonathan Lewis wrote:

> "Mladen Gogala" <mgogala.spam-me-not_at_verizon.net> wrote in message
> news:pan.2006.09.24.05.38.42.467739_at_verizon.net...

>>
>> Why would that be? Other then that, I lived without object
>> checkpoints from the version 4 to version 10.1 and things were
>> fine.


> 

>     No you didn't, you just didn't know they were happening.


That's probably because I wasn't waiting for them long enough to get

alarmed. I was alarmed by the long waits for the 'KO' enqueue.

>

>> Why would a direct read trigger a checkpoint?


> 

>     Because there may be blocks in the buffer with commited

>     changes that have not been written to disc. Since a direct

>     path read goes to disc, bypassing the buffer, it won't see

>     those changes.  So you have to issue a "localised" checkpoint

>     for the object just before the query starts to run.

> 

>     This feature existed back in (at least) 7.2 where I first met it

>     as the "extent checkpoint" - where I think Oracle issued a

>     checkpoint once per extent.  At some point this turned into

>     a tablespace checkpoint because "extent checkpoints" were

>     a disaster (no checkpoint queue until 8.1). The it became the

>     segment checkpoint - then in 10.2 Oracle put a linked list

>     into the buffer header to deal with all the problems if handling

>     a single segment in large buffers.


Thanks! This is a logical explanation. That probably means that putting  
a /*+ PARALLEL(tab,n) */ hint in my query will inevitably cause a "local
checkpoint"? 
I moved to New York City, so if you ever decide to teach a tuning class
there, let me know. The one I attended in CT was fantastic. 

-- 
http://www.mladen-gogala.com

Received on Sun Sep 24 2006 - 11:00:30 CDT