Unusable cause very slow automatic query

Question

SQLdeveloper frequently freeze up for minutes in our development instances (EE 11.2.0.3), which have an huge amount of schema, objects and synonyms.
Freezing is due to following query, I suppose automatically issued in order to discover accessible objects:
/*+ NO_SQL_TRANSLATION */
SELECT 'SCHEMA' type, username owner, username object_name, null column_name, null column_id, null data_type
FROM all_users
WHERE rownum <=50 and username like :1 union all /*+ NO_SQL_TRANSLATION */
SELECT object_type type, owner, object_name, null column_name, null column_id, null data_type
FROM all_objects
WHERE object_type ='TABLE' and object_name not like 'BIN$%' and rownum <=50 and object_name like :2 union all /*+ NO_SQL_TRANSLATION */
SELECT object_type type, owner, object_name, null column_name, null column_id, null data_type
FROM all_objects
WHERE object_type ='VIEW' and object_name not like 'BIN$%' and rownum <=50 and object_name like :3 union all /*+ NO_SQL_TRANSLATION */
select 'TABLE' type, SYS_CONTEXT('USERENV','CURRENT_SCHEMA') owner, synonym_name object_name, null column_name, null column_id, null data_type
from all_synonyms
where synonym_name like :4 and rownum <=50 and owner in (SYS_CONTEXT('USERENV','CURRENT_SCHEMA') ,'PUBLIC')
The query is from a SQLDeveloper v. 3.2.09, but we had similar problems with older versions.
I tried ad-hoc profile with EM's sql tuning advisor, but the gain in minimal. Looking at execution plain seems like the major problem is the union with the all_synonyms views, actually slow by itself (a known issue with our architecture since Oracle DB 10.2.0.4, as far as I remember).
Are there any workarounds to avoid the query or any parameter to force it using instead "user_synonyms"? Synonyms of other users are rarely intresting in object tree panel, we gladly gladly renounce to them...

Answer 1

This forum is actually for SQL*Developer questions. Your qustion is about SQL and performance and should probably be posted in the SQL and PL/SQL forum.
You can verify if it is SQL*Developer issue (possible but unlikely) by running it in another evironment like SQL*PLUS.
However, since we are here anyway ...
I performed searches in Google, My Oracle Support, and the 11gR2 documentation for NO_SQL_TRANSLATION and found nothing of any use. Did you mean NO_QUERY_TRANSFORMATION? If the hint you are using does not exist it will be ignored and by itself cause no problems. If it does exist (unlikely because there are lists of undocumented hints to be found on the internet) it shoud probably not be used since nothing is known about it. Does anything happen if you remove it and run the query?
Post an execution plan of your SQL.
A visual scan of your query (hard because it was unformatted)0
1. lever SQL joined by unions. hard to read since the UNION operators were randomly placed in the SQL
2. Multiple queries against data dictionary. If not queried by keys reading data dictionary tables can be slow