存储过程执行非常严重 - 增加超时或修复问题

May*_*ayo 3 sql oracle performance

我继承了第三方编写的前端.该前端通过不同第三方编写的程序与Oracle交互.有问题的存储过程需要2分36秒才能在手动执行时返回搜索结果.我看不到该过程,该团队建议我增加Web应用程序中的超时(托管在共享服务器上).

在我的世界中,超过30秒的任何事情都需要在部署到生产之前进行性能修复,只有少数例外(遗留代码,疯狂报告等).建议给我的选项是将超时从30秒(由前端开发人员明确添加)增加到180秒.

我向您提出的问题: 采用简单方法和增加超时有什么风险?如果可能,请提供支持您观点的文章的链接,以便我可以参考.

如果你认为这是一个非问题,也可以随意加入.

Ada*_*sch 5

您不应该增加超时以隐藏问题.你已经肯定地发现了一个性能问题 - 它应该被修复,而不是在地毯下扫过.

要做的两件事:

获取存储过程的SQL跟踪.

exec dbms_monitor.session_trace_enable(binds => false, waits => true);
exec poor_performing_procedure();
exec dbms_monitor.session_trace_disable();
Run Code Online (Sandbox Code Playgroud)

查看正在运行的语句的频率,以及运行它们所花费的时间.

在存储过程的代码中将钩子添加到DBMS_PROFILER中.

我的所有包中都有这样的代码,以便我可以通过设置包变量来确定是否对它们进行分析:

PROCEDURE profiler_control(p_start_stop IN VARCHAR2, p_run_comm IN VARCHAR2, p_ret OUT BOOLEAN) AS
  l_ret_code INTEGER;
BEGIN
  l_ret_code:=dbms_profiler.internal_version_check;
  IF l_ret_code !=0 THEN
    p_ret:=FALSE;
  ELSIF p_start_stop NOT IN ('START','STOP') THEN
    p_ret:=FALSE;
  ELSIF p_start_stop = 'START' THEN
    l_ret_code:=DBMS_PROFILER.START_PROFILER(run_comment1 => p_run_comm);
    IF l_ret_code=0 THEN
      p_ret:=TRUE;
    ELSE
      p_ret:=FALSE;
    END IF;
  ELSIF p_start_stop = 'STOP' THEN
    l_ret_code:=DBMS_PROFILER.FLUSH_DATA;
    l_ret_code:=DBMS_PROFILER.STOP_PROFILER;
    IF l_ret_code=0 THEN
      p_ret:=TRUE;
    ELSE
      p_ret:=FALSE;
    END IF;
  END IF;
END profiler_control;
Run Code Online (Sandbox Code Playgroud)

在程序里面,那里的代码如下:

create or replace procedure poorly_performing_procedure() 
begin
  if run_profiler then
    profiler_control('START', 'poorly_performing_procedure', g_retval);
  end if;
...
  if run_profiler then
    profiler_control('STOP', 'poorly_performing_procedure', g_retval);
  end if;
end poorly_performing_procedure;
/
Run Code Online (Sandbox Code Playgroud)

Oracle提供了一些脚本(一个名为profiler.sql),您可以使用这些脚本获取漂亮的报告,以显示运行期间每个PL/SQL语句/操作执行的次数.这是10g的DBMS_PROFILER文档的链接.