Re: What does an app need to do to work with RAC
- From: Mladen Gogala <mgogala@xxxxxxxxxxx>
- To: anjo.kolk@xxxxxxxxxxx
- Date: Mon, 29 Jan 2007 08:59:55 -0500
On 01/29/2007 05:05:01 AM, Anjo Kolk wrote:
> John,
>
> The simple answer to this is: CONTENTION in the application in any form.
> What I mean with that is data block contention (the obvious one) but also
> ROW CACHE and LIBRARY cache contention. The problem is that synchronizing
> between instances will become more expensive if you need to do more of
> it.E.g having two nodes going after the same block will cost less than
> having 10 nodes going after the same block. The problem is not the number of
> nodes, but the contention for the block. So how can one predict what will
> happen you go to RAC from a single instance? There are a couple of simple
> things one can do to find out (v$latch, v$sysstat, x$kcbsw, etc.), but that
> is too much work for this email.
>
Anjo, I understand why would you want to look into v$latch and v$sysstat, but
why in the world would a layman like me want to look into a table that defines
wait per software module? The only query that used this table in my collection
is the following:
SELECT WH.KCBWHDES "MODULE",SW.WHY0 "CALLS",SW.WHY2 "WAITS", SW."OTHER_WAIT"
"CAUSED WAITS"
FROM x$kcbwh WH, x$kcbsw SW
WHERE WH.indx = SW.indx
AND SW."OTHER_WAIT" > 0 ORDER BY SW."OTHER_WAIT"
The author is, I believe, K. Gopalakrishnan and results look something like
this:
MODULE CALLS WAITS CAUSED WAITS
-------------------- ---------- ---------- ------------
kdswh01: kdstgr 5295 0 1
kdswh02: kdsgrp 5076 0 1
kdswh06: kdscgr 5600 0 1
kdiwh06: kdifbk 7283 0 1
kdiwh07: kdifbk 11247 0 1
kdiwh08: kdiixs 6973 0 1
kdiwh09: kdiixs 8057 0 4
7 rows selected.
Now, what can I do about these modules and why would I want to look into this
table
before "racifying" my database?
--
Mladen Gogala
http://www.mladen-gogala.com
--
//www.freelists.org/webpage/oracle-l
Other related posts:
