Définition de PDQ dans une portée SPL locale?

Question

Afin de bien l'allocation tune des ressources PDQ en fonction du moment de la journée qui exécutent des travaux par lots, nous avons un utilitaire qui fixe PDQPRIORITY basé sur un jour de la semaine/heure de règles de jour, par exemple:

PDQPRIORITY=$(throttle); export PDQPRIORITY 

Cependant, ceci est corrigé au démarrage du script, de sorte que les jobs longs ne sont jamais ralentis au fur et à mesure de leur progression. Pour remédier à cela, nous avons essayé les points suivants:

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; 

à divers intervalles dans le SQL, nous avons ajouté:

EXECUTE PROCEDURE set_pdq(); 

Cependant, bien qu'il ne manque pas, la portée de la SET PDQ semble être local au SPL. onstat -g mgm ne signale aucune modification aux ressources d'origine allouées. Donc, l'ajout de ces appels set_pdq() ne semble pas avoir eu d'effet - les ressources allouées au démarrage du programme restent fixes.

Le code est fondé SQL décortiqués, à savoir:

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

So ou interpolation $ accents graves() se produit au début du script, lorsque le document est transmis ici à DBAccess. (Qui a éliminé l'évidence: SET PDQPRIORITY $(throttle);)

Wow, qui est devenu rapidement parlant. Quelqu'un peut-il suggérer un moyen de réaliser cela qui n'implique pas de réécrire complètement ces travaux par lots? Briser le SQL en plus petits morceaux n'est pas une option en raison de la forte dépendance sur les tables temporaires.

Answer 1

Comme vous l'aurez déduit du délai démesuré entre le moment où vous avez posé la question et la première tentative de réponse, ce n'est pas trivial.

Une partie du problème est, je pense, que PDQPRIORITY est capturé lorsqu'une procédure stockée est créée ou que ses statistiques sont mises à jour. En effet, cela peut être tout le problème. Maintenant, les tables temporaires provoquent un autre ensemble de problèmes avec les procédures stockées - les procédures stockées doivent souvent être réoptimisées lorsque des tables temporaires sont impliquées (sauf si le SP crée lui-même la table temporaire).