IMO that is a backwards way of tackling the problem. You should look at
everything you can about the waiting when it actually happened - not try to
replicate similar symptoms and fix those. If diagnostics pack licence has
been purchased you will have a goldmine if information you can look at in
gv$active_session_history (or the dba_hist version). Have a look at what
was blocked and when, what were they trying to execute? What were all the
parameters of the wait? What was the blocker doing? Remember you will have
to look over all instances.
This wait event is mainly about syncing object invalidations between
instances. So look at what DDL occurred around the time of the event (look
at dba_objects.last_ddl_time for clues, otherwise you might get lucky with
ASH - but you’ll only be able to see the command type rather than the SQL
for most DDL). If DDL is logged, then check there.
Hope this helps,
On Sat, 11 May 2019 at 15:04, kunwar singh <krishsingh.111@xxxxxxxxx> wrote:
I have a strange issue in one of accounts that my company supports.
This wait coming daily at sporadically different times. It lasts only for
few seconds, but it creates havoc for application job at that moment.
How do we troubleshoot this apart from going to MOS.
I would like to go deep into it , so is there a way/testcase i can
reproduce the this wait event and then scan though all data dictionary
/10046/other dumps in order to find the root cause and fix for it.
Once i am able to reproduce this wait, IMO , it will get easier to