Some non-RAC version of the script to find lock waiter and its blocker may not work in RAC. For 
instance, if you depend on v$lock.block to be 1 as a blocker, you'll be surprised to see that all 
sessions almost always have a value of 2 under the block column. In RAC, this value 2 means not more 
than that the session is not waiting to get a lock; it could be blocking others or not blocking, 
but it's not requesting. If it's requesting or waiting for a lock, the block column will be 0. Value 
1 still means blocking, but its blocked session, or one of them if multiple, is on the local 
instance.

So in RAC, the correct way to identify blocking and waiting session is to follow the script in 
Note:398519.1, which is

select * from gv$lock where (id1,id2,type) in (select id1,id2,type from gv$lock where request>0);

The output is like:

INST_ID ADDR             KADDR             SID TY     ID1    ID2 LMODE REQUEST CTIME BLOCK
------- ---------------- ---------------- ---- -- ------- ------ ----- ------- ----- -----
      7 00000001987B70C0 00000001987B70E0 2085 TX 3538958 401411     0       6   784     0
      7 00000001987B6F90 00000001987B6FB0 2175 TX 3538958 401411     0       6  1324     0
      6 000000019B001F60 000000019B001F98 2151 TX 3538958 401411     6       0 44728     2
      8 00000001987B70C0 00000001987B70E0 2069 TX 3538958 401411     0       6  1277     0
      8 00000001987B6F90 00000001987B6FB0 2131 TX 3538958 401411     0       6  4240     0

In 10g, gv$session has blocking_instance and blocking_session. So the following query can also 
be used.

select inst_id, sid, blocking_instance, blocking_session from gv$session
where blocking_instance is not null and blocking_session is not null order by 1, 2;

The output is like:

INST_ID  SID BLOCKING_INSTANCE BLOCKING_SESSION
------- ---- ----------------- ----------------
      7 2085                 6             2151
      7 2175                 6             2151
      8 2069                 6             2151
      8 2131                 6             2151

The difference between the above two queries is that the second query clearly shows the 4 sessions 
blocked by session 2151 on instance 6. But in the first query, it's not that obvious; since all 
5 sessions are holding or requesting the same type (TX) and same ID1 and ID2 lock, and we know 
block=0 means waiting, the one in the middle on instance 6 with a non-zero lmode must be blocking 
the other 4 sessions.

Note that querying the blocking_instance and blocking_session columns of gv$session may take a 
while to run, at least up to Oracle 10.2.0.3 (I can't find the bug#). It's not using CPU though. 
But a potential problem of incorrect values in earlier 10g versions may stop you from using 
this method. See Bugs 5677058 and 5481650. These problems seem to have been fixed in 10.2.0.4.