1. Most V$ views work by selecting information from the corresponding GV$
view with a predicate "where instance_id = <that instance>".

So V$SESSION in Instance 1 is actually "SELECT * FROM GV$INSTANCE
WHERE INST_ID = 1". On a three node RAC database, if you select from
v$session,you get sessions from that instance only. Selecting from GV$SESSION
creates parallel query slaves on the other instances and gets the information
back to your session.

2. This works fine in almost all cases. There are few exceptions: in case
of redo logs, the RAC instance must see all the redo logs of other instances as
they become important for its recovery.Therefore, V$LOG actually shows all the redo logs, of all the
instances, not just of its own. Contrast this with V$SESSION, which shows only
sessions of that instance, not all.

So, if there are 3 log file groups per instance (actually, per
"thread") and there are 3 instances, V$LOG on any instance will show
all 9 logfile groups, not 3.

3.When you select form GV$LOG, remember, the session gets the information
from other instances as well. Unfortunately, other servers on those instances
also get 9 records each,since they also see the same information seen by the first instance. On
a three instance RAC, you will get 3X9 = 27 records in GV$LOG!

4. The same explanation applies to GV$LOGFILE as well as GV$THREAD.

To avoid this:

(1) Always select from V$LOG, V$LOGFILE and V$THREAD in a RAC instance.
GV$ views are misleading.

OR

(2) add a predicate to match THREAD# with INST_ID. (Beware: thread
numbers are by default the same as the instance_id; but you may have defined a
different thread number while creating the database):