Question

I’ve got a bad code duplication problem where we cannot tell which versions of packages/procedures are being used. i.e. I have different packages with procedures of the same name and I need to be sure which packages are not actually being called.

I’m trying to eliminate procedures/packages of the same name which are no longer being called. I’d like to run the trace for a few weeks, combine the data and query the metadata against it and find candidates for further investigation and deactivation.

I’m looking for the equivalent of SQL Server’s sp_trace_create with sp_trace_setevent 42 to track the SP:Starting event – this would allow me to see all the stored procedures being called and then compare that to the entire inventory of stored procedures to see which ones should be investigated first for obsolescence. I have used DBMS_MONITOR.DATABASE_TRACE_ENABLE to generate trace files, but I haven’t found anything which explains how to use TKPROF to parse those files for anything but performance – nor do I even care about the statements themselves, just which routines are being used.

Answer 1

Dont think ILO will help (does it do more than just set the module and action and log the time somewhere ?) as Cade Roux would have to modify every package and function in the database.

One option is to switch on tracing at the database,

 ALTER SYSTEM SET sql_trace = true SCOPE=MEMORY;

and use a script command to get a unique list of all the package names executed although WARNING – this will generate a lot of output and fill up disk space very rapidly – you may want to create a file of the procedures run each day and then remove the trc files and then combine the results all together to identify which ones are used.

Also you need to ensure there is no limit on the trace file size which could prevent it logging everything and also ensure you have plenty of disk space and as you are not interested in the runtimes, you can also turn timed_statistics off to reduce the amount of logging.

 alter system set max_dump_file_size=unlimited;
 alter system set timed_statistics=false;

If i look at the raw trace files created from Oracle tracing, each application specific package call procedure call appears like this

=====================
PARSING IN CURSOR #2 len=69 dep=0 uid=102 oct=47 lid=102 tim=1316845390611021 hv=273704950   
 ad='b0d4c728' sqlid='01qnrr4850tzq'
BEGIN REIM_MATCH_SQL.INIT_SUMMARY_MATCH(:1, :2, :3, :4, :5, :6); END;
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,plh=0,tim=1316845390611021

so you can grep for the list of package calls like this in the directory (you might have to tweak the output a little depending on the OS you are using in case the tkprof output is different)

find . -name "*.trc" -exec grep "BEGIN " {} \; | cut -d" " -f4 | cut -d"(" -f1 | sort -u > ~/called_procedures.txt

This doesnt work with functions as they can be called in the middle of SQL statements but i think for procedures, it should be ok. This will produce a file in your home directory containing the unique list of procedure calls that have run since you turned on tracing.

I did a run of this on a directory containing 9818 trace files totalling 19GB of diskspace and it took 10 minutes on a test box running Oracle enterprise Linux 5 with 2 cores and 12GB memory – these trace files are just from repeated test runs of one program so you can imagine how quickly these will be created if you are generating for everything in a production machine.

Then you can get a list of all pacakges/procedures in the database from sqlplus for the particular schema you are interested in

set heading off
set trimspool on
set pagesize 0
set feedback off
spool all_procedures.txt 
SELECT DISTINCT p.object_name||'.'||p.procedure_name
  FROM all_procedures p
  JOIN all_objects o ON (o.owner = p.owner AND o.object_name = p.object_name AND o.object_type =
 where p.owner='&owner'
 order by 1
spool off

and finally do a diff of the two to get a list of candidates

diff all_procedures.txt called_procedures.txt

Dont forget to switch off tracing when you are done

ALTER SYSTEM SET sql_trace = false SCOPE=MEMORY;

Also, you need to be careful about procedures which may only be run at certain periods like month end or year end – they may appear not to be being used but you cant be sure unless every business process is completed during the time you are monitoring.

Hope that helps.