oracle - 收集另一个用户拥有的 PL/SQL 包的探查器信息

Question

假设我们在 Oracle 数据库中有 2 个用户(方案):TARGET_USER 和 TESTER_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_1 和 SomePackage.do_some_operation_2 程序运行时间的详细统计信息？

如 DBMS_PROFILER documentation 中所述有 4 件事会影响分析器:

1. 探查器仅收集用户拥有创建权限的单元的数据
2. 一般来说，如果一个用户可以调试一个单元，那么这个用户就可以对它进行概要分析。
3. 编译单元中的调试信息。
4. 程序单元必须编译为解释(非 native )代码。

在尝试满足所有要求的同时，接下来要完成的操作:

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

并查看了SomePackage的编译模式，是否有debug信息。

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

Answer 1

最近我遇到了向我介绍这种情况的同事，我们意识到在 Oracle 方面一切正常，但确保满足所有条件的步骤是错误的。
因此，我向所有花时间回答错误定位问题的人道歉。

但我们的成立可能会帮助到其他人，所以我会尝试解释情况并回答我自己的问题。
简而言之有两点:

1. 始终使用 native Oracle 工具来验证奇怪的情况；

2. 在每次测试尝试中从头开始重现完整情况。

问题的根源是在“PL/SQL Developer”工具中实现 native 代码和解释代码之间切换的方式。应用程序范围内的“PL/SQL 代码类型”首选项会影响在用户界面帮助下完成的每个包编译。 在验证所有条件时，collegaue 使用 alter session set PLSQL_CODE_TYPE=INTERPRETED 或 alter session set PLSQL_CODE_TYPE=NATIVE 在编译模式之间切换，但之后偶尔使用接口(interface)功能重新编译包, 所以工具应用它自己的设置并在 native 模式下完成编译。

在逐步安排所有操作后，我们得到了解决问题的线索，现在可以成功地分析这个包。