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件事可能影响探查器：

探查器仅收集用户具有CREATE权限的单元的数据
通常，如果用户可以调试单元，则同一用户可以对其进行分析。
以编译单位调试信息。
必须将程序单元编译为解释（非本机）代码。

在尝试满足下一步所做的所有要求时：

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仍然无法访问内部程序的分析器统计信息所以，问题是：如果可能的话，必须采取什么措施来纠正这种情况呢？

Answer 1

最近我遇到了向我介绍这种情况的同事，我们发现甲骨文一切都运作良好，但确保所有条件都得到满足的步骤是错误的。
因此，我向所有花时间回答错误定位问题的人道歉。

但我们的创始可能会帮助别人，所以我会尝试解释情况并回答我自己的问题简而言之，有两点：

始终使用本机Oracle工具来验证奇怪的情况;
在每次测试尝试时从头开始重现完整情况。

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

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

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

1 个答案: