We see load of db is increased , and during spike of latch ges resource
hash list cpu shoots up ,
Can their is possibility that due to high cpu latch ges resource is
occuring or might vice versa.
Regards,
Krishna
On Mon, 4 Oct 2021, 19:48 Mark W. Farnham, <mwf@xxxxxxxx> wrote:
Untested completely theoretical notion: It may actually take longer with
the other instances down. Is it possible that the application will tolerate
the second instance being up but in restricted mode so that only “DBA”
authority can connect?
Since I don’t have the code I can only guess, but it’s possible that only
a ping memory to memory is needed for instances that are up whilst probing
the down instance’s undo and/or redo is required. That might take long
enough for hash waits to pile up.
But first up with a bullet is JL’s suggestion of badly configured
sequences, which dovetails nicely with a vendor lacking sufficient
understanding of Oracle to support multiple instances being up.
And a question: What is the purpose of being RAC in this case? If you are
thinking rapid fail-over, I’d suggest you consider changing your
configuration to standby-recovery either roll your own or Dataguard. With
the second instance normally down, I’d like your odds that a complete
recovery failover to the standby is either faster than or negligibly slower
than RAC, and it eliminates all the RAC overheads for multi-instance
coordination. As JL pointed out, some of the RACTAX™ applies even when only
one instance is up. RAC is wonderful if you really need it, but YPDNR.
mwf
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Krishnaprasad Yadav
*Sent:* Monday, October 04, 2021 6:50 AM
*To:* Jonathan Lewis
*Cc:* Oracle L
*Subject:* Re: Event : latch: ges resource hash list
Hi Jonathan ,
Thanks for your mail, I understand the above points , and will try to
drive in a similar direction as you have mentioned .
Regards,
Krishna
On Mon, 4 Oct 2021 at 16:13, Krishnaprasad Yadav <chrishna0007@xxxxxxxxx>
wrote:
Hi Jonathan,
Its 2 node rac system , and only one instance is running and the other
one is down .
Regards,
Krishna
On Mon, 4 Oct 2021 at 15:18, Jonathan Lewis <jlewisoracle@xxxxxxxxx>
wrote:
GES is the global enqueue service (which isn't about buffer cache), so it
looks as if you are doing something that requires coordination of some
locking event. (And the code path is followed regardless of how many
instances are up.)
I would take a couple of snapshots of v$enqueue_stat over a short period
of time to see if any specific enqueue is being acquired very frequently;
but some global enqueue gets don't get recorded in that view - so it may
show nothing interesting. And I would do the same (snapshots) of v$rowcache
to see if any if the dictionary cache objects were subject to a high rate
of access. EIther of these might give you some clue about what's going on.
Historic issues:
sequences being accessed very frequently and declared with NOCACHE (or
very small CACHE) or with ORDER.
Some bugs relating to tablespace handling, undo handling, VPD, the result
in massive overload on dc_tablespaces, dc_users, dc_objects,
dc_rollback_segments (though I can't remember if any of them were still
around in 12.2).
Regards
Jonathan Lewis
On Mon, 4 Oct 2021 at 10:23, Krishnaprasad Yadav <chrishna0007@xxxxxxxxx>
wrote:
Hi Experts ,
There is a situation around which is causing an event : latch: ges
resource hash list in database . CRS /RDBMS is 12c2 version on solaris
DB is 2 node RAC , but due to application compatibility node 2 always
remains down. however on node 1 we lot of query waiting for latch : ges
resource hash list ,(no specific query is ,but all )
on node 2 ,the complete CRS stack is down , not sure why this event is
popping up on node1 .
Parallely CPU for node 1 also remains higher more than 80% most of the
time .
Any light about this event will be helpful .
Regards,
Krishna
