views:

73

answers:

1

I am new to DBMS_PROFILER. All the examples I have seen use a simple top-level procedure to demonstrate the use of the profiler, and from there get all the line numbers etc. I deploy all code in packages, and I am having great difficulty getting my profile session to populate the plsql_profiler_units with useful data. Most of my runs look like this:

RUNID RUN_COMMENT UNIT_OWNER  UNIT_NAME         SECS PERCEN
----- ----------- ----------- -------------- ------- ------
5     Test        <anonymous> <anonymous>        .00    2.1
      Profiler

5     Test        <anonymous> <anonymous>        .00    2.1
      Profiler

5     Test        <anonymous> <anonymous>        .00    2.1
      Profiler

I have just embedded the calls to the dbms_profiler.start_profiler, flush_data and stop_profiler as per all the examples. The main difference is that my code is in a package, and calls in to other package. Do you have to profile every single stored procedure in your call stack? If so that makes this tool a little useless!

I have checked http://www.dba-oracle.com/t_plsql_dbms_profiler.htm for hints, among other similar sites.

+3  A: 

Are you sure that this is not a problem with your query to retrieve data from plsql_profiler_units?


I tried this:

Create Procedure sub_procedure As
Begin
  dbms_output.put_line('test');
End;

Create Package test_package As
  Procedure test;
End;

Create Package Body test_package As
  Procedure test As Begin
    For i In 1 .. 10 Loop
      If(i<=5) Then
        sub_procedure;
      End If;
    End Loop;
  End;
End;

Begin
  DBMS_PROFILER.start_profiler(SYSDATE);
  test_package.test;
  DBMS_PROFILER.stop_profiler;
End;

and this simple query

Select uni.unit_name, dat.line#, dat.total_occur
  From plsql_profiler_data dat
  Join plsql_profiler_units uni On (     uni.runid = dat.runid
                                     And uni.unit_number = dat.unit_number )

gives me the expected result showing also packages and procedures:

<anonymous>    1  0
<anonymous>    2  0
<anonymous>    3  2
<anonymous>    4  1
<anonymous>    5  0
TEST_PACKAGE   2  0
TEST_PACKAGE   3 11
TEST_PACKAGE   4  5
TEST_PACKAGE   5  6
TEST_PACKAGE   8  1
SUB_PROCEDURE  1  0
SUB_PROCEDURE  3  5
SUB_PROCEDURE  4  5
Peter Lang
Thanks for that - I ran your example and that worked ok. Then, I reran the package that was causing me trouble from SQL*Developer, and it seemed to profile OK. One thing I thought of is that my comment was not unique in my first test - does it have to be? Adding the timestamp looks like a good way to ensure that.
Greg Reynolds
Ok, I still have the same problem when the stored procedure is called by my application, but it profiles OK when called from SQL*Developer. The application connects as a different user to the one I typically use from SQL*Developer - are there any permissions that need to be set in order for it to work properly?
Greg Reynolds
@Greg Reynolds: It does not have to be unique. The `run_comment` parameter is stored in `plsql_profiler_runs.run_comment` and helps to distinguish different calls. Connect to *SQL*Developer* using the same user as your application to find out if grants are missing.
Peter Lang
Yes - that was it - I changed the application to log in as the schema owner and everything was fine. Doh!
Greg Reynolds