| 
V5R30,
Nouvelles options du fichier QAQQINI
------------------------------------------------
CACHE_RESULT le résultat d'une requête est placé en cache pour pouvoir
etre réutilisé. En V5R30 cela peut etre conservé même
après la fin du job, et donc augmenter les besoins mémoire
*SYSTEM (dft) utilser le cache
*NONE ne pas faire de cache
DATABASE_MONITOR_THRESHOLD permet de limiter les moniteurs database
(STRDBMON) aux requetes dépassant un certain temps de traitement.
*DEFAULT toutes les requetes sont gérées
nn temps de traitement estimé , en secondes.
vous pouvez aussi limiter le moniteur à certains fichier en indiquant
le(s) nom(s) système dans le commentaire de la commande STRDBMON
COMMENT('TABLEFILTER(bib/fichier1,bib/fichier2)')
|
|
IGNORE_DERIVED_INDEX indique à SQE de traiter une requete, meme si elle utilise des index dérivés, c.a.d des logiques : - avec des sélections/omissions SDD - pointant sur plusieurs membres - avec des clé 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 *YES (dft en V6) SQE ignore les index et traite la requete 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 |
|
l'optimiseur SQE (SQL query Engine), l'ancien se nomme CQE, évolue. Rappel : ATTENTION, seul SQL peut utiliser SQE : - SQL interactif ,dans les programmes ou des scripts (RUNSQLSTM), QM. - CLI, NetDATA et autre produits utilisant CLI - JDBC/ ODBC il a été mis en place un dispatcher qui va diriger (router) chaque requête soit vers SQE, soit vers CQE. en Mai 2003, avec des PTF, SQE traite maintenant les requêtes suivantes : toutes les jointures. les prédicats IN et OR INSERT avec un SELECT imbriqué l'utilisaiton de DB2 SMP (dispo facturable) Toutes les requêtes encore traitées par CQE sont notées par STRDBMON (QQC16 d'une ligne QQRID à 3014) |
|
EN V5R30, les types de requête traités maintenant par SQE, sont: - toutes les sous-requetes - l'utilisation des vues - les jointures en étoile (sauf FORCE_JOIN_ORDER) - les requetes avec UNION, Intersect et Except - INSERT, UPDATE, DELETE Utilisent toujours CQE : - les requetes avec la clause LIKE, cette restriction disparait en V5R40 - les requetes avec UPPER, LOWER et TRANSLATE - les requetes manipulant des LOB (BLOB ou CLOB) - tout ce qui est changement de CCSID, particulièrement STRSEQ() - 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 ou des TABLES avec index dérivés (sauf à utiliser IGNORE_DERIVED_INDEX à *YES dans QAQQINI) - les requêtes avec le paramètre ALWCPYDTA(*NO) ou curseur sensitif (là aussi la V5R40 fera disparaitre cette limite) |
|
Les jointures peuvent utiliser une nouvelle technique d'optimisation LookAhead Predicate Generation la requete suivante SELECT * FROM vins, producteurs WHERE vins.pr_code = producteurs.pr_code AND appel_code = 179 est ré-écrite par SQE : WITH HASHTABLE (Select * from producteurs where appel_code = 179) SELECT * from HAST-TABLE, VINS WHERE HASHTABLE.pr_code = VINS.pr_code and appel_code IN (SELECT DISTINCT appel_code from HASHTABLE) le résultat de la sous requete est placé dans une table de Haschage (objet temporaire), en s'appuyant sur différentes techniques, dont les index EVI, afin de faire la jointure sur le plus petit nombre de lignes |
|
Cette technique est itérative. En cas de jointure sur trois fichiers, on créé un table de haschage sur le résultat de la première jointure, afin de faciliter la jointure avec le 3 ème fichier, etc... Cette technique s'applique très bien sur des bases décisionnelles (on a souvent une table centrale, liée à des tables paramètres) et sera utilisée systématiquement dans ce cas. les paramètres STAR_JOIN et FORCE_JOIN_ORDER de QAAQQINI ne sont plus utilisé QUE par CQE. Visual Explain indique si cette technique a été utilisée. Autres nouveautés - Si une table possède des contraintes de domaine : CHECK (appel_code between 50 AND 100) , SQE en tient compte. |
|
- Nouveaux types de plans d'accès (compression) - 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 requete en utilise beaucoup, utilisez un pool système dédié, et toujours avec PAGING(*CALC) - meilleure utilisation des statistiques collectées et meilleure gestion des collectes. Et enfin, en règle générale, meilleure intégration de Visual Explain à SQE qui doit montrer maintenant : - l'utilisaiton de la technique LPG (vue plus haut) - certaines autres nouveautés de SQE - des informations et surtout, des icones plus détaillées - enfin, les pages d'aides du produit ont été revues. |
|
Tables matérialisées: Cela permet de définir une table en lui associant une requête initiale -la table peut etre réactualisée avec le résultat de la requête à tout moment. - avec SF99503/niveau 4, cette table peut être utilisée par l'optimiseur 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--! |
|
DATA INITIALLY IMMEDIATE indique que la requête est réalisée une première fois à la création de la table DATA INITIALLY DEFERRED indique une table matérialisée uniquement avec REFRESH TABLE REFRESH DEFERRED admet l'utilisaiton le l'ordre REFRESH TABLE MAINTAINED BY USER est obligatoire ENABLED QUERY OPTIMIZATION permettera, dans l'avenir une utilisation de cette table par l'optimiseur de requete (val. par défaut) Une table matérialisée doit etre journalisée, donc placée dans une bibliothèque avec un journal QSQJRN. |
|
l'ordre ALTER TABLE permet de revenir sur une table matérialisée ALTER TABLE xxx DROP MATERIALIZED QUERY, rend la table ordinnaire ALTER TABLE xxx ALTER MATERIALIZED QUERY, modifie les caractèristiques ALTER TABLE xxx ADD MATERIALIZED QUERY, fait d'une table simple, une table matérialisée. Exemple : --------- CREATE SUMMARY TABLE BDVIN9/VINS_PAR_PRODUCTEUR AS ( SELECT VINS.VIN_NOM , VINS.VIN_CEPAGE1 , PRODUCTEURS.PR_NOM , PRODUCTEURS.PR_COMMUNE , PRODUCTEURS.PR_PROPRIO FROM BDVIN9/VINS VINS RIGHT OUTER JOIN BDVIN9/PRODUCTEURS ON PRODUCTEURS.PR_CODE = VINS.PR_CODE ) DATA INITIALLY IMMEDIATE REFRESH DEFERRED MAINTAINED BY USER ENABLE QUERY OPTIMIZATION |
|
Quand vous passez l'ordre : ............................................................................ : Entrée d'instructions SQL : : : : Saisissez l'instruction SQL, puis appuyez sur ENTREE. : : > refresh table bdvin9/vins_par_producteur : : Instruction REFRESH TABLE terminée. : :..........................................................................: la table est réactualisée. il existe de nouvelles colonnes dans SYSTABLES pour les tables matérialisées Attention, seul SQE sait utiliser les tables matérialisées, il ne faut donc pas que votre requete utilise des options traitées uniquement par CQE il faut une requete - 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 standart, il faut le demander en placant 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 rafraichissement de la table matérialisée est à votre charge Si vous demandez dans votre requete, une colonne ne se trouvant pas dans MQT, elle ne peut pas etre utilisée. une seule table MQT par requete |
|
Les gains sont réels, mais attention aux points suivants : - temps de rafraichisement 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) Si la table materialisée est utilisée, c'est elle qui sera montrée par Visual Explain et vous verrez son nom dans la log au message CPI4329 (si vous etes en debug) |
