为了根据批处理作业的一天中的时间微调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，即：

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

因此，当here文档传递到dbaccess时，反引号或者$()插值发生在脚本的开头。 (这消除了显而易见的内容：SET PDQPRIORITY $(throttle);)

哇，很快就罗word了。任何人都可以提出不涉及完全重写这些批处理作业的任何方法来实现这一目标吗？由于严重依赖临时表，因此无法将SQL细分为较小的部分。

解决方案

正如我们从提出问题到首次尝试回答之间的时间过长所推导出的那样，这并非微不足道。

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