Re: reads by KTSJ

This seg fix state is what made me think it might be related to the fix-ups that take place on space allocation from parallel CTAS where every slave creates its own segment and the QC then has to clean-out the blocks that were initially segment header and space management blocks as it combines the separate segments into a single one.

Regards
Jonathan Lewis

On Wed, May 13, 2020 at 7:17 PM Tanel Poder <tanel_at_tanelpoder.com> wrote:

> You mentioned that there were some *buffer busy waits* showing up too?
>
> Instead of relying on the block address & DBA_EXTENTS query (maybe this
> block has been reused by something else by now?), you can use ashtop to see
> which *block class* the buffer busy waits were against. A random example
> from my lab:
>
> SQL> _at_ash/dashtop event*2 *"event='buffer busy waits'" sysdate-90 sysdate
>
> Total
> Seconds AAS %This EVENT2
> --------- ------- ------- ---------------------------------------------
> 38360 .0 88% buffer busy waits [*data block*]
> 4680 .0 11% buffer busy waits [*undo data*]
> 540 .0 1% buffer busy waits [*undo header*]
> 130 .0 0% buffer busy waits [*file header block*]
>
>
>
> Also the *[ktspsc_segmon] submitted segfix task* messages in your
> tracefiles are interesting.
>
> SQL> SELECT description FROM x$ktsjtaskclass ORDER BY 1;
>
> DESCRIPTION
> ----------------------------------------------------------------
> AIM scheduler
> Affinitize segment for IM Hash Index
> CLISLAVE
> DROPTEMP
> ...
> SEG DICT UPDATE
> SYSAUX FILE OFFLINE CHECK
> SYSAUX FILE ONLINE CHECK
> *Segment Fixstate*
> Segment Monitor
> ...
>
> Indeed there's a KTSJ task class called "Segment Fixstate", so maybe
> Oracle's autonomously fixing something under the hood :)
>
> --
> Tanel
> https://tanelpoder.com
>
>

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