Hmm, I just started wondering.
Well, today we had an issue with specific application query. There were sql statement, where there were close to a 20k rows (application code uses this dynamic sql, and the XML request favoured of generating this huge sql statement).
And actually there may have been a problem with sql parsing.
So this huge sql statement had hard parse time little over a minute. Execution itself (when sql statement was present in shared_pool) actually took only few seconds.
This sql had 500+ union operators, so lot of subqueries there. And I agree, not very fortunate sql. We need to do some changes there.
This may have very well been that, the toad SB "Current Statement" hanged during the sql parse operation. And after the parsing finished, and the execution started, then the toad was responsive again.
(later selecting it from gv$sql probably is not the same thing)
Can you confirm, which query is executed to get this "Session Browser" Current statement..?