Установка PDQ внутри SPL - локальная область? - PullRequest
Новая
       12

Установка PDQ внутри SPL - локальная область?

1 голос
/ 03 октября 2008

Для точной настройки распределения ресурсов 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

Таким образом, обратная интерполяция или интерполяция $ () происходит в начале скрипта, когда документ здесь передается в dbaccess. (Это устранило очевидное: SET PDQPRIORITY $(throttle);)

Ух ты, это быстро стало многословным. Кто-нибудь может предложить какой-либо способ достижения этого, который не включает переписывание этих пакетных заданий полностью? Разбить SQL на более мелкие части не представляется возможным из-за большой зависимости от временных таблиц.

1 Ответ

1 голос
/ 12 октября 2008

Как вы поняли из непомерной задержки между моментом, когда вы задали вопрос, и первой попыткой ответа, это не тривиально.

Я думаю, что отчасти проблема в том, что PDQPRIORITY перехватывается при создании хранимой процедуры или обновлении ее статистики. Действительно, это может быть все проблемы. Теперь временные таблицы вызывают другой набор проблем с хранимыми процедурами - хранимые процедуры часто нуждаются в повторной оптимизации, когда задействованы временные таблицы (если, возможно, сам SP не создает временную таблицу).

...