Question

为了根据批处理作业运行的时间微调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()调用似乎没有任何影响 - 在程序开始时分配的资源仍然是固定的。

代码是嵌入式SQL shell，即：

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

因此，当here文档传递给dbaccess时，脚本开头会出现反引号或$（）插值。（这消除了显而易见的：SET PDQPRIORITY $(throttle);）

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

Answer 1

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

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

在SPL中设置PDQ - 本地范围？

1 个答案: