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

ket 发布于 2018-05-11 informix 最后更新 2018-05-11 12:53 97 浏览

为了根据批处理作业运行的时间微调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
所以当脚本文件被传递给dbaccess时,在脚本开始时出现反向或$()插值。 (这消除了显而易见的:SET PDQPRIORITY $(throttle);) 哇,这太快了。任何人都可以提出任何方式来实现这一点,不涉及完全重写这些批处理作业?由于严重依赖临时表,将SQL分解为更小的部分不是一种选择。
已邀请:

gnihil

赞同来自:

正如你从你提出问题的时间和第一次尝试答案之间的过分延迟中推导出来的,这不是微不足道的。 部分问题是,我认为,PDQPRIORITY是在创建存储过程或更新统计信息时捕获的。的确,这可能是所有问题。现在,临时表导致存储过程出现另一系列问题 - 存储过程通常需要在涉及临时表时重新优化(除非SP可能会创建临时表)。