QAQQINI, essayer d'influencer l'optimiseur de requêtes.                   
 -------------------------------------------------------                   
                                                                           
  vous pouvez apporter des options à votre environnement DB2/400, pouvant  
   éventuellement influencer l'optimiseur de requêtes (Query Governor)     
                                                                           
  il s'agit d'un fichier "INI" ou fichier paramètre, composé de deux zones:
                                                                           
  QQPARM VARCHAR(256)    : entrée, paramètre à modifier                    
  QQVAL  VARCHAR(256)    : valeur à attribuer                              
                                                                           
  vous avez aussi QQTEXT VARCHAR(1000) pour commentaire                    
                                                                           
  le plus simple est de dupliquer celui fourni dans QSYS vers QUSRSYS      
                                                                           
 le système cherche un fichier portant ce nom dans la bibliothèque indiqué  
  par la commande :                                                        
                    CHGQRYA   QRYOPTLIB( )                                 
                                                                           
  la valeur par défaut est QUSRSYS, et s'il n'existe pas un tel fichier    
   vous verrez un message d'information dans l'historique.                 

V5R20,

 Attention, certaines options du fichier QAQQINI ne sont plus supportées,
   

 Si vous avez créé un fichier QAQQINI dans une de vos bibliothèques et
  qu'il contient des options non supportées , vous recevrez le message
  CPI433A ou CPF433B. Cela n'empêche pas la requête de s'exécuter.


 Il est conseillé de recréer le fichier à partir de celui de QSYS.

V5R30,


 Quelques nouvelles options du fichier QAQQINI
 ---------------------------------------------
  CACHE_RESULT  le résultat d'une requête est placé en cache pour pouvoir
                  être réutilisé. En V5R30 cela peut être conservé même
                  après la fin du job, et donc augmenter les besoins mémoire


                *SYSTEM (dft) utiliser le cache
                *NONE   ne pas faire de cache


  DATABASE_MONITOR_THRESHOLD  permet de limiter les moniteurs database
   (STRDBMON) aux requêtes dépassant un certain temps de traitement.


                *DEFAULT toutes les requêtes sont gérées
                nn       temps de traitement estimé , en secondes.

  Cette option a été remplacée par les paramètres de la commande STRDBMON

        RUNTHLD    : seuil en secondes, de temps d'exécution
        STGTHLD    : seuil en Mo de mémoire utilisée
        FTRFILE    : filtrage du moniteur sur un nom de fichier
        FTRUSER    : filtrage du moniteur sur un profil utilisateur
        FTRINTNETA : filtrage du moniteur sur une adresse IP cliente
        FTRQRYGOVR : filtrage du moniteur sur l'annulation de la demande 
                        pour dépassement de critère donné par CHGQRYA

  IGNORE_DERIVED_INDEX   indique à SQE de traiter une requête, même si elle
                          utilise des index dérivés, c.a.d des logiques :


                             - avec des sélections/omissions
                             - pointant sur plusieurs membres
                             - avec des clefs dérivées (CONCAT, TRANSLATE)
                             - utilisant le paramètre SRTSEQ et/ou ALTSEQ


                *NO (dft en V5)   la requête est traitée par CQE (voir ci-dessous)

                *YES (dft en V6)  SQE ignore les index et traite la requête

  VARIABLE_LENGTH_OPTIMIZATION


                *YES (dft)  utilisation avancée des variables VARCHAR
                             (les blancs des constantes sont ignorés)

                *NO         pas d'optimisation des variables VARCHAR

V5R40

  ALLOW_TEMPORARY_INDEX  SQE doit-il tenir compte des MTI pour construire son plan

                *YES (dft)    SQE tiens compte des index temporaires MTI

                *NO   SQE ne tiens compte que des index permanents

V6R10

  SQL_PSEUDO_CLOSE    SQE laisse les curseurs et les fichiers ouverts dès la DEUXIEME utilisation
                         dans le même job

                *DEFAULT  utilisation en fonction de la présence d'une DataArea QSQPSCLS1
                             si elle existe le fichier est gardé ouvert dès la première utilisation
                             sinon, fonctionnement normal (dès la 2eme utilisation) 

                nn         chiffre entre 1 et 65535 représentant le nombre d'utilisations avant de laisser ouvert


   

Une alternative à la création d’un fichier QAQQINI se trouve proposée par la procédure override_qaqqini ; nouvelle en V6R10.

Attention, l’utilisation de cette procédure implique les droit *JOBCTL pour l’utilisateur

    -- créé un fichier QAQQINI dans QTEMP
    Call  override_qaqqini(‘1’ , ‘ ‘ , ‘ ‘)

    --  modifie la valeur pour le job
    Call  override_qaqqini(‘2’ , ‘SQL_PSEUDO_CLOSE ‘ , ‘05‘)

    -- détruit le fichier de QTEMP,  retour à la normale
    Call  override_qaqqini(‘3’ , ‘ ‘ , ‘ ‘)                        

D'autre part, le moteur SQL (query engine) a été revu, dès la V5R20,
 mais cohabite avec l'ancien.


 le nouvel optimiseur de requête se nomme SQE (SQL query Engine)
				 l'ancien CQE (Core query Engine)


 De nombreuses fonctions SQL ont été descendues en dessous du microcode,
  DONT SQE, qui est écrit en programmation Objet (C++) au niveau SLIC.


ATTENTION, seul SQL peut utiliser SQE :


  - SQL interactif ,dans les programmes ou des scripts (RUNSQLSTM), QM.
  - PHP, NetDATA et autre produits utilisant CLI
  - JDBC/ ODBC


 n'en profitent pas :


  - les E/S natives
  - OPNQRYF
  - QUERY/400

 Ceci dit, pour des problèmes de transition et de temps, toutes les
  requêtes ne profiteront pas immédiatement à la V5R20 de SQE.


 il donc été mis en place un dispatcher qui va diriger (router) chaque
  requête soit vers SQE, soit vers CQE.


 Plus SQE saura traiter de cas différents, plus le dispatcher dirigera vers SQE.


 En début de V5R20, le dispatcher route la plupart des requête vers CQE :

   Seules les requêtes simples sont dirigées vers SQE.
   (suite à STRDBMON, QQC16 d'une ligne QQRID à 3014, l'indique)


      

 Avec le  GROUPE de PTF database V5R2, (SF99502)
  ainsi que les PTF :   - SI07650  et -SI08876


 SQE traite les requêtes avec :


   JOIN ainsi que les jointures en règle générale.
   les prédicats IN et OR
 L'utilisation de DB2 SMP (dispositif facturable) 
 

   Ainsi que les INSERT avec un SELECT imbriqué


 (voyez le site http://www-1.ibm.com/servers/eserver/iseries/db2/sqe.html )
 
      
 toutefois, il peut arriver que SQE soit invoqué à tort, auquel cas il
  redirige lui-même le requête vers CQE (légère perte de temps),
  particulièrement lors de l'utilisation d'index particuliers: 

      
          - avec des sélections/omissions
          - pointant sur plusieurs membres
          - avec des clé dérivées (zones résultat de traitement: CONCAT, TRANSLATE)
         - utilisant le paramètre SRTSEQ et/ou le mot-clé ALTSEQ 

           

 EN V5R30, les types de requête traités maintenant par SQE, sont:


    - toutes les sous-requêtes
    - l'utilisation des vues
    - les jointures en étoile (sauf FORCE_JOIN_ORDER)
    - les requêtes avec UNION, Intersect et Except
    - INSERT, UPDATE, DELETE




 Utilisent toujours CQE :


    - les requêtes avec la clause LIKE
    - les requêtes manipulant des LOB (BLOB ou CLOB)
    - tout ce qui est changement de CCSID
    - les tables partitionnées
    - l'utilisation de tables avec des TRIGGERs à la lecture
    - les requêtes utilisant des fonctions tables (UDTF)
    - les requêtes utilisant les logiques (CRTLF) ou des index dérivés
        (sauf à utiliser IGNORE_DERIVED_INDEX dans QAQQINI)
    - les requêtes avec le paramètre ALWCPYDTA(*NO) ou curseur sensitif(ODBC/JDBC)                                         


En V5R40, SQE traite la clause LIKE

et enfin en V6R1, la plupart des limitations disparaissent et SQE traite toutes les requêtes SQL

     - les requêtes utilisant une séquence de tri particulière SRTSEQ() et LANGID()
     - les requêtes portant sur des tables ayant des index dérivés 
              (heureusement pour les nouveaux index SQL)
     - les requêtes utilisant des UDTF
     - etc...

A l'exception :
 
      - des requêtes lancées par d'autre interfaces que SQL (QUERY/400, OPNQRYF)
      - des requêtes utilisant un LF (créé par SDD et CRTLF) dans la clause FROM

enfin en V6R10, le moteur possède un module d"auto-apprentissage", qui agit aujourd'hui dans 2 cas :

     Cold I-O/Warm I-O
           quand un plan d'accès prévoit un accès par index et que le moteur se rend compte que la table est 
             actuellement en mémoire il réécrit le plan en conséquence        

First I-O/ALL I-O
           quand un plan d'accès est prévu pour une optimisation First I-O 
               (fournir un premier résultat le plus rapidement possible)
             et que l'application change (par exemple un chargement complet des lignes),
              il ré-écrit le plan probablement en utilisant un "table scan"
             
   Ce paramètre sera noté dans Visual Explain 
             
 et dans le fichier de sortie de STRDBMON avec le code QQRID=3006
    - QQRCOD contient B2 et QQC21 =2 pour un Cold I/O to Warm I/O
    - QQRCOD contient B2 et QQC21 =3 pour un First I/O to ALL I/O

 Autres Nouveautés V5R20.


 Data Access Primitives 


 SQE, contrairement à CQE ne fait pas de statistiques, de sondages sur les
  différentes valeurs et leur nombre, ces fonctions sont réalisées par l'OS.


 SQE ne créé pas d'index temporaires, mais il réalise mieux les balayages
  de table et les traitements de la clause DISTINCT.


 Il ne créé plus de tables temporaires pour les requêtes complexes, mais
  un objet interne (niveau microcode), plus léger.


 V5R30

 - réduction de la taille des objets temporaires


 - meilleure utilisation de la mémoire, tenant compte de la taille attribuée
    à chaque job dans le pool système. Si votre requête en utilise beaucoup,
    utilisez un pool système dédié, et toujours avec PAGING(*CALC)


 - Si une table possède des contraintes de domaine :
     CHECK (appel_code between 50 AND 100) , SQE en tient compte.

 
  - Les jointures peuvent utiliser une nouvelle technique d'optimisation

 LookAhead Predicate Generation ou LPG

     la requête suivante :


   SELECT * FROM vins, appellations
             WHERE vins.appel_code = appellations.appel_code
              AND   appellation like 'Bordeau%'

qui oblige, à priori, SQL à faire la jointure de appellations(le plus petit) vers vins (le plus gros)

  est réécrite par SQE :


   WITH HASHTABLE (Select * from appellation
                             where appellation like 'Bordeau%)
    SELECT * from HAST-TABLE, VINS
              WHERE  HASHTABLE.appel_code = VINS.pr_code
              and appel_code IN (SELECT DISTINCT appel_code from HASHTABLE)

 

Le but est d'aller chercher pour le fichier le plus petit et ayant une sélection 
(ici appellation commence par 'Bordeau') la liste des valeurs de jointure
 (la liste des codes appellation de Bordeaux) afin partir du fichier vins  (le plus gros)
 en commençant par une sélection (si possible basée sur index) sur les appellations concernées

 Tables matérialisées (ou MQT)

  Cela permet de définir une table en lui associant une requête initiale


   -la table peut être réactualisée avec le résultat de la requête
     à tout moment.


   - En cours de version V5R30 (DataBase group niveau 4) et avec les PTF
     suivantes : SI17164, SI17609, SI17610, SI17611, SI17637
                et MF34848, I5/OS est capable d'utiliser une MQT
                (Materialized Query Table) dans un but d'optimisation




 syntaxe :


  CREATE SUMMARY TABLE -(nom)---AS (Select SQL complet [ORDER BY admis])->


      !--DATA INITIALLY IMMEDIATE---!
  >---!                             !--REFRESH DEFERRED-->
      !--DATA INITIALLY DEFERRED ---!


                           !---ENABLED QUERY OPTIMIZATION--!
  >--- MAINTAINED BY USER--!                               !---.
                           !---DISABLE QUERY OPTIMIZATION--!



 Attention, seul SQE sait utiliser les tables matérialisées, il ne faut donc
  pas que votre requête utilise des options traitées uniquement par CQE
  (comme LIKE en V5R30 , l'utilisation d'index dérivés, etc ...)


 il faut une requête - portant sur un seule table ou avec INNER JOIN
                     - sans UNION
                     - sans User Defined Function (UDF) ni UDT
                     - sans sous sélection
                     - sans certaines fonctions du langage comme
                       SOUNDEX, DIFFERENCE, DECRYPT_xx, INSERT, REPEAT,
                       REPLACE, DAYNAME, MONTHNAME.


 L'utilisation des tables matérialisée est une option, ce n'est pas le
  standard, il faut le demander en plaçant dans QAQQINI :


   MATERIALIZED_QUERY_TABLE_USAGE = *ALL
   MATERIALIZED_QUERY_TABLE_REFRESH_AGE = *ANY
   (ou une durée sous la forme d'un timestamp AAAAMMJJHHMMSS)


il faut d'autre part que la TABLE a été crée avec ENABLED QUERY OPTIMIZATION
 et que le paramètre ALWCPYDTA soit à *OPTIMIZE (par défaut sous ODBC/JDBC)


Le rafraîchissement de la table matérialisée est à votre charge (ordre REFRESH)


Quelques restrictions


      

•  Si vous demandez dans votre requête, une colonne ne se trouvant pas dans la
    MQT, cette dernière ne peut pas être utilisée. 
•  une seule table MQT par requête !
•  C'est a vous de faire le rapport en entre les avantages
• gain de temps lors de la requête, optimisation transparente.
•  et les inconvénients
• temps de rafraîchissement des données (la MQT n'est PAS maintenue par le système)
• affichage de données obsolètes, suivant le dernier REFRESH.
       (sauf à utiliser MATERIALIZED_QUERY_TABLE_REFRESH_AGE)
  

 Plan Cache 


   les plans d'accès SQE sont désormais conservés (dans un cache)


     - jusqu'à IPL ou jusqu'à une certaine taille (512 Mo)
         les plus anciens et les moins utilisés sont alors détruit.

     - la taille peut être ajustée par CALL QQQOOOCACH PARM('R:1024')
         [tapez CALL QQQOOOCACH pour avoir une liste des paramètres.]
          ou par iSeries Navigator V6 (Mémoire cache de plan SQL/propriétés)


     les SQL Package existent toujours (ainsi que le cache niveau JOB),
      ils stockent toujours les paramètres systèmes et les requêtes, mais
      ils utilisent les plans d'accès du cache système.


     - on mémorise jusqu'à 5 plans par requêtes
        (avec ou sans index, avec ALWCPYDTA(*YES ou *OPTIMIZE), etc..)


     - on peut espérer, lors d'une requête,(sauf suite à IPL) rencontrer
        un plan d'accès déjà validé et ainsi gagner du temps.


     - il n'existe pas de possibilité de visualisation de ce cache en V5R2/R3.


 - la V5R30 implémente de nouveaux types de plans d'accès (compression) 

 - la V5R40 propose la visualisation de ce cache, par iSeries Navigator 
      

 Statistic Manager 


  nouvelle fonction (au niveau SLIC) chargée de collecter des informations
   liées aux performances.


  Avant, le seul moyen de prendre de bonnes décisions, était pour
  l'optimiseur d'utiliser les index (estimations), maintenant
  la collecte de statistiques permet au statistic manager de fournir des
  informations plus pertinentes.


  c'est lui qui indique l'index à utiliser (et non plus l'optimiseur)


  Si aucune statistique n'existe pour une table, l'information est mémorisée
   et les statistiques sont collectées lors des temps morts.




  Vous pouvez aussi demander explicitement la collecte de certaines
    statistiques via iSeries Navigator ou API :


    (les noms longs correspondent au *SRVPGM QDBSTMGR)

 Les statistiques contiennent les informations suivantes :


   - Cardinalité :  nombre de valeur différentes
   - Fréquence   :  liste des valeurs les plus fréquentes + nbr de lignes
   - Histogramme :  divise les différentes valeurs en tranches égales
                     et indique pour chaque tranche 1er, dernier et nombre.


 Elle sont collectées pour une colonne à la fois, et éventuellement à partir
  d'un index existant

 La collecte de statistiques est effectuée par le JOB QDBFSTCCOL
   .................................................................
   : QALERT        QSYS        SYS    0,0                  DEQW    :
   : QCMNARB01     QSYS        SYS    0,0                  EVTW    :
   : QCMNARB02     QSYS        SYS    0,0                  EVTW    :
   : QCMNARB03     QSYS        SYS    0,0                  EVTW    :
   : QDBFSTCCOL    QSYS        SYS    0,0                  EVTW    :
   : QDBSRVXR      QSYS        SYS    0,0                  DEQW    :
   :...............................................................:
  Ce job est multi-thread, faire DSPJOB et option 20 pour les voir.
   .......................................................................
   :     Unité                       Total                    Priorité   :
   :   exécution       Etat            UC            E-S     exécution   :
   :   00000001        EVTW          0,132           458          50     :
   :   00000007        DEQW          0,000             1          99     :
   :   00000006        DEQW          0,000             0          99     :
   :   00000005        DEQW          0,016            65          96     :
   :   00000004        DEQW          0,013           104          96     :
   :   00000003        DEQW          0,000             0          93     :
   :   00000002        DEQW          0,000             1          90     :
   :.....................................................................:

 les requêtes utilisateur courtes sont traitées à une priorité de 90
 les requêtes utilisateur longues sont traitées à une priorité de 93


 les requêtes système courtes sont traitées à une priorité de 96
 les requêtes système longues sont traitées à une priorité de 99


 la valeur système QDBFSTCCOL permet de gérer les collectes


  -  *ALL   : autorise la collecte de toute statistique (val. par défaut)

  -  *NONE  : interdit toute collecte automatique (les collectes immédiates
               demandées par l'utilisateur sont toujours effectuées)

  -  *USER  : autorise les collectes utilisateur en tâche de fond.

  -  *SYSTEM:  autorise les collectes système en tâche de fond.


 les collectes étant réalisées par défaut en tâche de fond, cela devrait avoir peu d'impact 
    sur les temps de réponse, mais peut en avoir sur l'utilisation globale de la CPU (moins de périodes d'inactivité).

La V5R30 offre une meilleure utilisation des statistiques et une nouvelle gestion des collectes.