We have an internal application based on .Net which calls certain procedures in Oracle (10g). One of these queries is run to get in/out parameters of these procedures. It’s a pretty simple select query. But even under the best of circumstances, it is taking 3 seconds. At lease few times a day it starts taking more than 40 seconds and causes our .Net application to time out.
Select query is:
SELECT a.argument_name,
a.data_type,
a.in_out,
NVL (a.data_length, 0) AS data_length,
NVL (a.data_precision, 0) AS data_precision,
NVL (a.data_scale, 0) AS data_scale
FROM ALL_ARGUMENTS a, all_objects o
WHERE o.object_id =
(SELECT object_id
FROM all_objects
WHERE UPPER (object_name) = UPPER ('resourcemanager_pkg')
AND object_type = 'PACKAGE'
AND owner = 'OFFICEDBA')
AND UPPER (a.object_name) = UPPER ('p_search_roles')
AND a.OBJECT_ID = o.OBJECT_ID
ORDER BY a.position ASC
This query returns the in/out parameters of particular procedure.
resourcemanager_pkg is package name, p_search_roles is procedure name.
We call this query for every database call for procedures.
Is there anything which is wrong with this query?
Do you have the ability to modify the query that is being generated? It appears that it is doing an extraneous join to the
ALL_OBJECTStable. It appears that your query is equivalent to thisI would also expect that using
ALL_PROCEDURESrather thanALL_OBJECTSto get theOBJECT_IDwould be more efficient.Have you gathered dictionary statistics? Queries against the data dictionary views are generally rather hard to tune since you can’t add indexes or other structures to speed things up. But at least gathering dictionary statistics may give the optimizer better information to be able to pick a better plan.
Finally, is it possible that you could materialize the data from the data dictionary in a materialized view that refreshes periodically that you could index? That would mean that the results wouldn’t immediately reflect changes to the definition of procedures. On the other hand, you don’t generally want to be making changes to procedure definitions live and you can always refresh the materialized views after making schema changes.