Re: strange wait events

Whatever the root cause is, the effect is it's likely to be made worse by RAC, especially with more than just 2 nodes. I'd check the library cache invalidations and reloads, and the dictionary cache activity for hot spots as this might help.

Mladen has mentioned Job Scheduler and materialized views -

    can you confirm whether the time is lost on a statement executed by a trigger, or a statement that causes a trigger to fire.

    if it's a statement executed by a trigger might it be one that is updating an "on commit refresh" materialized view ?

It might help if you know what the reliable messages are for, here's a query that expands gv$channel_waits a bit and reports stats on all the reliable message channels that have been used since startup, adding in the channel address.
select

        des.inst_id,
        des.name_ksrcdes        channel_name,
        ctx.addr                channel_address,
        ctx.totpub_ksrcctx      messages_published,
        ctx.waitcount_ksrcctx   wait_count,
        ctx.waittime_ksrcctx    wait_time_usec
from
        x$ksrcdes       des,
        x$ksrcctx       ctx
where
        ctx.name_ksrcctx   = des.indx
and     ctx.totpub_ksrcctx > 0
order by
        des.name_ksrcdes,
        des.inst_id

You might be able to guess something about what you're waiting for by looking for the biggest numbers published. Otherwise if you can do some tracing of the critical statement so get the p1/p2/p3 for the reliable message waits

p1raw is the channel address (as in the SQL above) p2raw is the channel handle (possibly x$ksrchdl.addr - but not very useful) p3raw is the broadcast message (possibly x$ksrmsgdes.addr - check column name_ksrmsgdes)

Regards
Jonathan Lewis

On Thu, 2 Feb 2023 at 16:03, Laurentiu Oprea <laurentiu.oprea06_at_gmail.com> wrote:

> Dear oracle community,
>
> I`m running some tests on 19.17 DB (rac and non-rac - data and data
> structures are absolutely identical).
>
> In the RAC DB I see that an updated generated by a triggered
> significantly slower compared with single instance and top wait events are:
> 65% JS kgl get object wait
> 11% reliable messages
> 8% library cache pin
> 5% CPU
>
> Anyone have any idea what JS kgl get object wait event is and how can I
> diagnose the cause for it?
>
> THank you in advance.
>

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