Now.. At one point today the alert using "select * from dba_blockers" fired where as the out of the box metric from gird control did not fire.... alert duration was around 5 - 10 mins

At first i simply assumed that this could have been a brief lock and due to both 5 min intervals being out of sync, the lock had shown and cleared before the grid control interval run.

now im a little more curious.

Is there any significan difference in what these 2 different SQL's will alert on, I was under the impression that DBA_BLOCKERS was simply querying a number of joined views, and Oracle had decided to use V$lock for their out of the box metric as it was more efficient.

dba_blockers shows only local blockers, inside one instance
for global locks you should use gv$lock, but your query is not correct
or you can upgrade to 10g or 11g and use v$session.blocking_instance, blocking_sid

what do you mean the query is not correct? This is the sql that runs from the out of the box grid control metric "blocking sessions count"

if the query not shows blockers, how it can be correct ? Just try the following : on node 1 lock row, on node 2 lock the same row, run the query. You should get that session on node 2 is waiting for session on node 1.

So back to the origional question,
I am using both these queries from different monitors on my prod syystem, both running on 5 minute intervals, " select * from dba_blockers" fired where as the above query - querying gv$lock did not fire.

Origionaly i assumed that the blocking lock may have simply lasted 3t0 seconds, and due the 5 minute monitor intervals of each metric not being in sync, ... "select * from dba_blockers" may have picked up the lock, then the query selecting from gv$lock ran 2 mins later by which time the lock had disapeared.

-Can anyone suggest any other reasons other than this why one monitor (select * from dba_blockers) picked up the lock and the other (gv$lock) didnt?

lets say this was a single instance database......Im trying to understanding if there are any situaions / different types of blocking sessions / locks that one query may pic up whilst the other one wont?

So, for global locks "v$lock.block=2" and no other info.
The query that you mentioned here finds blocking_sid based on v$lock.block.
This means that for single-instance "block=1" and it is ok. For global locks "block=2",
and there is no guarantee that waiting sid will not have this value.