Consider two complex queries - see attach.
Script "prepare_too_long_and_hangs_monitoring.sql" contains a lot of calls to windowed functions and script "also_complex_but_NOT_trouble_in_preparing.sql" has no such calls but contains lot of scalar subqueries (in places where windowed functions were in first one).
The following scenario illustrates what there will be if we try to get execution plan of both queries.
C:\1Install\fb30>isql localhost/3330:empty30 -n
SQL> in prepare_too_long_and_hangs_monitoring.sql;
-- hangs (preparing takes about five minutes on my Linux server)
SQL> set list on;
SQL> commit; select * from mon$attachments where mon$attachment_id<>current_connection
CON> and mon$remote_protocol > is not null;
-- ALSO HANGS untill execution plan will appear in session #2!
So, we can not querying MON$ATTACHMENTS during five minutes. And any other MON$-tables too.
PS. Script "also_complex_but_NOT_trouble_in_preparing.sql" does not leads to such trouble though it also too comples and also have lot of "calls" inside itself.
summary: MON$-tables are unavaliable when optimizer prepares to execute query with lot of windowed functions => Server ignores asynchronous (monitoring or cancellation) requests while preparing a query with lot of windowed functions