Sometimes a pure SQL query to search in source code is easier to use than using a pl/sql solution, like the one shown on my
Source Code Search (PL/SQL) page.
The query below searches for 1 or more search terms, in both source (packages etc.), views, materialized view, job, synonyms and table/view column names (the column names are not really source code, but do come in very handy).
Thanks to Arnoud for his contributions.
Things to note:
- To get some performance I used a materialize hint for user_source. It speeds it up a lot when using multiple search terms, but I'm still not quite sure why...
- The query uses both "instr" and "like", so you have some form of wildcards to play with but not everywhere. Regular expressions would make this even more flexible, but I think that would slow things down too much in most cases..
- The line "lower( dbms_xmlgen.convert(xmltype(dbms_metadata.get_xml('VIEW', v.view_name)).extract('//ROWSET/ROW/VIEW_T/TEXT/text()').getclobval(), 1) )" looks quite weird, but it was the fastest way I could find to get the source of (large) views. Life would be a lot easier if user_views would just return a clob instead of a long...
- The "alternative" query is quite nice I think. For example, if you only need to find calls to a function were two specific parameters are used (and not just one of them), this can come in handy.
- If apex_string.split results in a line with more than 4000 characters, you will get an ORA-00910 "specified length too long for its datatype" exception.
And if you use apex_string.split_clobs, which is a relatively new Apex function (introduced in 22.1), you need to truncate the SQL column to 4000 characters, meaning you might miss results.
So in the iv_v_4000 inlive view I search for (materialized) views with lines > 4000 characters, so they can be dealt with separately in the iv_views_s inline view.
If you want to change this query for all users instead of just the current user, you will need to make some changes:
- Make sure the schema that will run the query has access to all objects. SYS or SYSTEM should be fine of course, but otherwise you may need to grant the SELECT_CATALOG_ROLE role to the user.
This is the reason why I kept this query limited to the user itself; usually you will not have access to all objects, and then you will get errors like this: ORA-31603: object "USER_TAB_COLS_V$" of type VIEW not found in schema "SYS".
- Change all references to user_* views to all_* views.
- Include the owner column in all (sub)queries.
- And make sure to pass the owner into the schema parameter of the dbms_metadata.get_xml calls.