1

为了根据批处理作业运行的时间微调 PDQ 资源的分配，我们有一个实用程序可以根据一周中的某天/一天中的某小时规则设置 PDQPRIORITY，例如：

PDQPRIORITY=$(throttle); export PDQPRIORITY

但是，这在脚本启动时是固定的，因此长时间运行的作业不会随着它们的进展而受到限制。为了解决这个问题，我们尝试了以下方法：

CREATE PROCEDURE informix.set_pdq() RETURNING VARCHAR(50);
  DEFINE pdq, dow SMALLINT;
  DEFINE hr SMALLINT;

  LET dow = WEEKDAY(CURRENT);
  LET hr = TO_CHAR(CURRENT, '%H');

  IF (dow == 0 OR dow == 6 OR hr < 8 OR hr > 14) THEN
      LET pdq = 100;
      SET PDQPRIORITY 100; -- SET PDQ does not accept a variable name arg.
  ELIF (hr >= 8 AND hr <= 10) THEN
      LET pdq = 40;
      SET PDQPRIORITY 40;
  ELIF (hr >= 11 AND hr <= 12) THEN
      LET pdq = 60;
      SET PDQPRIORITY 60;
  ELIF (hr >= 13 AND hr <= 14) THEN
      LET pdq = 80;
      SET PDQPRIORITY 80;
  END IF;
  RETURN "PDQPriority set to " || pdq;
END PROCEDURE;

在整个 SQL 的不同时间间隔，我们添加了：

EXECUTE PROCEDURE set_pdq();

然而，虽然它没有失败，但 SET PDQ 的范围似乎是 SPL 的本地。onstat -g mgm不报告对分配的原始资源的任何更改。所以添加这些set_pdq()调用似乎没有任何效果——在程序启动时分配的资源保持不变。

该代码是嵌入在shell中的SQL，即：

 dbaccess -e $DBNAME << EOSQL
   SELECT .. INTO TEMP ..;
   EXECUTE PROCEDURE set_pdq();
   SELECT .. INTO TEMP ..;
   --etc
 EOSQL

所以反引号或 $( ) 插值发生在脚本的开头，当 here 文档被传递给 dbaccess 时。（这消除了明显的SET PDQPRIORITY $(throttle);：）

哇，这很快就变得罗嗦了。任何人都可以提出任何不涉及完全重写这些批处理作业的实现方式吗？由于严重依赖临时表，因此无法将 SQL 分解成更小的部分。

4

1 回答 1

1

正如您从提出问题和第一次尝试回答之间的过度延迟中推断出的那样，这并非微不足道。

我认为，部分问题是在创建存储过程或更新其统计信息时捕获了 PDQPRIORITY。事实上，这可能就是问题的全部。现在，临时表会导致存储过程出现另一组问题——当涉及到临时表时，存储过程通常需要重新优化（除非可能是 SP 本身创建了临时表）。

于 2008-10-12T02:09:49.423 回答