Re: Huge DBF sequential reads by KTSJ while updating securefile LOBS.

Thanks Jonathan for the details.

I will check ASH for further details. Additionally , I did try to add more space to the respective LOB table space and we do have enough free space now. But one thing I am not getting like why SMCO still need to watch out for extending the space ?

On Thu, 31 Mar 2022 at 10:31 PM, Jonathan Lewis <jlewisoracle_at_gmail.com> wrote:

>
> It's not your version, of course, but I was looking at a similar issue on
> 19c a little while ago:
> https://jonathanlewis.wordpress.com/2022/01/10/control-file-waits/
>
> Some work of this type has to be done by some process - it's just a
> question of how visible it becomes to end-user run-time
>
> Regards
> Jonathan Lewis
>
>
> On Thu, 31 Mar 2022 at 12:35, Goti <aryan.goti_at_gmail.com> wrote:
>
>> Hi All,
>>
>> Envt :11.2.0.4 on RHEL 6.5
>>
>> We are observing slowness in OGG replication on the target side. The
>> replication itself is updating a table which has a secure file LOB. There
>> are a lot of updates performed during this time (Close to 25K in an hour).
>> The FG session waits for "direct path write" as it was created with the
>> NOCACHE attribute. However, the ASH shows that this is internally
>> triggering some space management slaves to do many single block reads.
>> There are no trace files also associated with the W00* processes.
>>
>> Please find the TKPROF report for the OGG replicat OS process.
>> https://gist.github.com/aryangoti/f49660a4bbb23c58a9f403ac9270eb7a
>>
>> Snapper for W0003 process.
>> https://gist.github.com/aryangoti/f2cf46ebcec3920d79f4fb719c01f309
>>
>> ASH details (5 minutes) when the replication was slow.
>> https://gist.github.com/aryangoti/6674691d7770b6eb667718589633aec5
>>
>> Please let me know how to troubleshoot this further.,
>>
>> Thanks,
>>
>> Goti
>>
> --

Thanks,

Goti

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