Is your query like this?
select inst_id,process,status,client_process,thread#,sequence#,block#,blocks,delay_mins from gv$managed_standby;
Yes, kind of. I only took the process and status, and ordered by inst_id.
My understanding is in a multiple RAC Physical Standby only one node applies the archivelogs to the standby database.
MRP will run on only one of the instances when you have a RAC standby. If you have access to MOSC, see if this response I posted on 4/23/2014 helps understand how different threads work for a RAC primary. Taking the concept futher to how redo is applied no a RAC standby, it can be difficult trying to weave multiple threads from a primary to multiple threads on the standby. Its easy of the primary and standby have the same number of threads. Each instance in the standby would get one thread from an instance in the primary. But I have one production system that has 3 threads in the primary and the standby is a 2-node RAC cluster. So to make things easy, the standby only does the apply one one instance. This way, that one instance can weave all the threads together to derive the fabric of our transactional load.
Forgot to add this as well...
If you use the DG Broker, it is easy to see which instance is doing the apply:
DGMGRL> show database ress
Database - ress
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 0 seconds (computed 1 second ago)
Apply Rate: 68.00 KByte/s
Real Time Query: OFF
ress1 (apply instance)
Instance RESS1 is my apply instance. If I shut it down, RESS2 will be the apply instance. I can also set a Preferred Apply Instance as a DG Broker property.