Question

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

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

我的问题： 采用简单方法并增加超时有什么风险？如果可能，请提供支持您观点的文章的链接，以便我可以参考。

如果您认为这不是问题，也可以随意加入。

Answer 1

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

要做的两件事：

获取存储过程的SQL跟踪。

exec dbms_monitor.session_trace_enable(binds => false, waits => true);
exec poor_performing_procedure();
exec dbms_monitor.session_trace_disable();

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

在存储过程的代码中将钩子添加到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;

在程序中，有代码如：

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;
/

Oracle提供的脚本（一个名为profiler.sql）可用于获取漂亮的报告，以显示运行期间每个PL / SQL语句/操作执行的次数。这是针对10g的DBMS_PROFILER文档的link。

Answer 2

如果您确实希望完成该过程，则应将其作为后台任务（不在脚本上下文中）运行，并在可通过AJAX或普通页面访问的资源中报告其状态。

如果过程在脚本上下文中运行，那么每当脚本死亡时，Oracle会话也会死亡，如果尚未完成，则会回滚该过程。

这可能是由于超时以外的原因造成的（连接死机，用户关闭了页面等）。

Answer 3

全球越来越多的超时问题是你可能会遇到几个问题：

拒绝服务攻击。
服务器上的资源耗尽。
吞吐量降低。

当你增加超时时，你告诉服务器它需要保留它用来服务该请求运行的线程。服务器将具有有限数量的线程，因此它长时间运行的线程是一个不可用于服务其他请求的线程。如果你有很多请求需要很长时间才能运行，那么最终你的线程用完了，服务器就会没有响应。

这对您来说是否重要取决于对该特定存储过程的请求数量。如果每隔一段时间只发出一次请求，那么这不是什么大问题。但是，全局设置超时的问题是它现在适用于所有请求，因此如果有其他请求可能需要很长时间才能运行，那么您也将延长其持续时间。

Answer 4

我不认为将超时增加到180秒是一个好主意。我在一家快速发展的公司工作了两年。在那段时间里，我们有许多存储过程，这些过程具有移动执行时间。他们开始在不到1秒的时间内运行，然后他们花了30秒，最后2到3分钟。一旦他们达到2分钟，他们会导致网站超时，我们会抓住它，并重写proc以提高效率。如果你把时间延长到180秒就意味着你可能会在一个月内将超时窗口增加到360秒，然后在2个月内增加720秒。你可以看到它的发展方向。如果其他人不同意，那么你需要了解它们的来源，因为任何类型的数据增长都会降低你的性能。

Answer 5

你说你看不到这个程序。您是否可以访问数据库，是否可以对其进行更改？如果您无法访问数据库和/或无法对其进行更改，我认为您的选项仅限于：

延长超时时间，
鼓励外部供应商解决问题。

正如其他人所说的那样，由于种种原因，增加超时并不是一个好的解决方案。鼓励外部供应商提供帮助（例如，威胁要用竞争对手替换他们的申请，或拒绝支付许可费，直到您的问题得到解决）可能是您最好的选择。通常，您想与之交谈的人是SALES GUY，而不是技术人员。一般来说，技术人员不会因为不直接影响他们而失去收入。销售人员 DOES 关心，因为如果您保释或拒绝支付，可能会对他的薪水产生直接影响，因此他有一种既得保持高兴的既得利益，又可能对他有一定程度的影响力。科技的。与销售人员打交道的关键标语是“......在我们的环境中表现令人无法接受......”，“......无法使用您的应用程序支持业务......”，“...不会多花一分钱对于这个应用程序，直到它满足我们的需求......“，并且总是受欢迎的......”我们将评估替代解决方案......“。请记住，销售人员是他们与他的公司的接口 - 所以得到他的面子 - 或者更好的是，让销售人员稍微咀嚼一段经理。（这就是经理们的目的......）。吱吱作响的轮子得到油脂......

另一方面，如果您可以修改数据库，它可能会像@Adam Munsch建议的那样为您提供服务，并找出正在运行的SQL语句，因此很慢。您可以通过添加一两个索引来显着改善这种情况。

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

5 个答案: