Re: latch: cache buffers chains

First guess -
Is there any reason why the primary would know that the parent session had written a very large amount of data to the GTT while the standby thinks the GTT is very small. In the latter case you may find that PX sessions are using buffered reads when you normally expect parallel tablescans to use direct path.

Second guess -
Is is possible that the execution plan has changed so that the primary is doing a tablescan of the GTT but the standby is doing a parallel tablescan of something else and using that to drive an indexed access path into the GTT Regards
Jonathan Lewis

On Fri, 1 Oct 2021 at 10:06, Laurentiu Oprea <laurentiu.oprea06_at_gmail.com> wrote:

> Hello everyone.
>
> Version 12.1
>
> Looks like for a sql statement executed in standby database, with
> parallel, that selects data from a GTT (with on commit delete rows) the PX
> slaves spends a significant amount of time into latch: cache buffers chains
> and read by other session . Same query executed in primary database has no
> issues. THis issue is observed just for GTTs.
>
> Anyone have any ideas on how to mitigate this issue?
>
> THank you.
>
>

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