3

假设我们在 Oracle 数据库中有 2 个用户(方案):TARGET_USERTESTER_USER.

TARGET_USER拥有一些包裹:

create or replace package TARGET_USER.SomePackage 
is

  procedure some_interface_proc(p1 number, p2 varchar2, p3 xmltype);

end;

这个包的主体包含很多函数,从 调用some_interface_proc,例如:

create or replace package body TARGET_USER.SomePackage
is

  procedure do_some_operation_1 
  is 
  begin
    null; -- Really do some actions here 
  end;

  procedure do_some_operation_2 
  is 
  begin
    null; -- Really do some actions here 
  end;

  procedure some_interface_proc(p1 number, p2 varchar2, p3 xmltype)
  is
  begin
    do_some_operation_1;
    do_some_operation_2;
  end;

end;

授予执行此包的权限TESTER_USER

grant execute on TARGET_USER.SomePackage to TESTER_USER

TESTER_USER授予运行DBMS_PROFILER包所需的所有权限并拥有所有必需的表。有了这样的设置TESTER_USER,就可以成功地针对测试脚本运行分析器,可以简化如下:

begin

  for cData in (
   select a, b, с from table_with_test_data
  ) loop

    TARGET_USER.SomePackage.some_interface_proc(a,b,c);

  end loop;

end;

所以,所有的统计数据都收集起来了,一切似乎都很好,但是......

问题

为什么TESTER_USER看不到有关运行时间SomePackage.do_some_operation_1SomePackage.do_some_operation_2程序的详细统计信息?

正如DBMS_PROFILER 文档中所指定的,有 4 件事会影响探查器:

  1. 探查器仅收集用户具有 CREATE 权限的单元的数据
  2. 一般来说,如果一个用户可以调试一个单元,同一个用户就可以对其进行分析。
  3. 编译单元中的调试信息。
  4. 程序单元必须编译为解释(非本机)代码。

在尝试满足所有要求的同时,完成以下操作:

grant create any procedure  to TESTER_USER;
grant alter any procedure  to TESTER_USER;
grant debug on TARGET_USER.SomePackage to TESTER_USER; 

并检查 SomePackage 的编译模式以及是否存在调试信息。

但是在完成所有这些操作后,TESTER_USER仍然无法访问内部过程的探查器统计信息。
所以,问题是:如果可能的话,必须做些什么来纠正这种情况?

4

1 回答 1

2

Recently I meet colleague who introduced this situation to me and we realize that all works well on Oracle side, but steps to insure that all conditions are met was wrong.
So I apologize to all those who spent their time to answer the incorrectly positioned question.

But our founding may help someone else, so I'll try to explain situation and answer my own question.
In short there are two points:

  1. Always use native Oracle tools to verify strange situation;

  2. Reproduce full situation from scratch on each test attempt.

Source of the problem is the way that switching between Native and Interpreted code was implemented in "PL/SQL Developer" tool. There are application-wide "PL/SQL Code type" preference which affects every package compilation done with help of user interface. While verifying all conditions collegaue used alter session set PLSQL_CODE_TYPE=INTERPRETED or alter session set PLSQL_CODE_TYPE=NATIVE to switch between compilation modes, but after that occasionally used interface features to recompile a package, so tool applies it's own settings and done compilation in native mode.

After arranging all actions step-by-step we got a clue to solve a problem and now can profile this package successfully.

于 2013-09-10T08:51:28.680 回答