| 
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 biblothè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, les seules options supportées sont les suivantes : ------------------------------------------------ APPLY_REMOTE PARALLEL_DEGREE ASYNC_JOB_USAGE PARAMETER_MARKER_CONVERSION COMMITMENT_CONTROL_LOCK_LIMIT QUERY_TIME_LIMIT FORCE_JOIN_ORDER REOPTIMIZE_ACCESS_PLAN IGNORE_LIKE_REDUNDANT_SHIFTS SQLSTANDARDS_MIXED_CONSTANT MESSAGES_DEBUG SQL_TRANSLATE_ASCII_TO_JOB OPEN_CURSOR_CLOSE_COUNT STAR_JOIN,QL_WARNINGS OPEN_CURSOR_THRESHOLD SUPPRESS_SQL_WARNINGS OPTIMIZATION_GOAL UDF_TIME_OUT,N_DIAGRAM OPTIMIZE_STATISTIC_LIMITATION VISUAL_EXPLAIN_DIAGRAM Si vous avez créé un fichier QAQQINI dans une de vos bibliothèques et qu'il contient des options non supportées (elles étaient non documentées et destinées au support IBM uniquement), 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. |
|
D'autre part, le moteur SQL (query engine) a été revu, 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. - CLI, 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 profiterons pas immédiatement 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, (au fur et à mesure des versions et des PTF, voyez l'APAR II13486) plus le dispatcher dirigera vers SQE. En début de V5R20 (début 2003), le dispatcher route la requête vers CQE si: - le resultat de la requête est modifiable (FOR UPDATE OF...) - la requête reférence : -> plus d'une table (jointure ou UNION) -> une table avec des BLOB ou des CLOB -> un fichier logique ou une vue SQL -> des tables distribuées (DB2 Multisystem) - la requête contient : -> un autre ordre SELECT( sous sélection, table dérivée, ...) -> une clause OR, LIKE , IN -> des comparaisons de colonnes ayant un CCSID différent |
|
- vous utilisez DB2 SMP,dispo facturable pour utilisation multi-processeurs Toutes les autres requêtes doivent être dirigées vers SQE. (suite à STRDBMON, QQC16 d'une ligne QQRID à 3014, l'indique) Au 14 Mai 2003, avec le dernier GROUPE de PTF database, (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 Ainsi que les INSERT avec un SELECT imbriqué (voyez l'APAR II13486 et le site http://www-1.ibm.com/servers/eserver/iseries/db2/sqe.html ) l'utilisation de DB2 SMP devrait être aussi intégrée rapidement. |
|
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ésulat de traitement: CONCAT, TRANSLATE) - utilisant le paramètre SRTSEQ et/ou le mot-clé ALTSEQ 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 traitement 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. |
|
Nouveautés . Plan Cache les plans d'accès SQE sont désormais conservés (dans un cache) - jusqu'à IPL ou jusqu'à une certaine taille (non indiquée) les plus anciens et les moins utilisés sont alors détruit. 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(*ALWAYS ou *OPTIMZE), etc..) - on peut espérer, lors d'une requête,(sauf suite à IPL) rencontrer un plan d'accès déja validé et ainsi gagner du temps. - il n'existe pas de possibilité de visualisation de ce cache. |
|
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 founir 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) |
|
Cancel Requested Statistics Collections (QDBSTCRS, QdbstCancelRequestedStatistics) Delete Statistics Collections (QDBSTDS, QdbstDeleteStatistics) List Statistics Collection Details (QDBSTLDS, QdbstListStatisticsCollection) List Statistics Collections (QDBSTLS, QdbstListStatistics) Request Statistics Collections (QDBSTRS, QdbstRequestStatistics) Update Statistics Collection (QDBSTUS, QdbstUpdateStatistics) 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é). |
