>>-UPDATE QP_SYSTEM USING--------------------------------------->
>--+-DEFAULT------------------------------+--------------------><
'-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-'
'-'N'-'
Un message d'avertissement est renvoyé lorsque l'une des tâches ci-après est effectuée via Query Patroller Center ou à partir de la ligne de commande Query Patroller :
Le message d'avertissement est le suivant :
DQP1024W
La création, la modification ou la suppression d'une classe de requêtes ne
sera prise en compte que lorsque le serveur Query Patroller aura été redémarré.
Parallèlement, la version 8.2 du manuel DB2 Query Patroller : Guide d'installation, d'administration et d'utilisation indique que vous devez redémarrer le serveur Query Patroller après avoir créé, modifié ou supprimé des classes de requêtes et ce, afin que vos modifications prennent effet.
Le texte du message et celui figurant dans le guide ne sont plus exacts. Les trois tâches de classe de requête indiquées prendront effet immédiatement, à moins qu'il n'existe des requêtes en file d'attente ou en cours d'exécution. S'il existe des requêtes en file d'attente ou en cours d'exécution, y compris les requêtes nouvellement soumises, les modifications de classe de requête prendront effet lorsque les requêtes en file d'attente ou en cours d'exécution seront terminées. Si vous ne souhaitez pas attendre la fin de toutes les requêtes (en file d'attente et en cours d'exécution), vous devez redémarrer le serveur Query Patroller.
La signification des états de requête Canceled (Annulé) et Done (Terminé) est désormais la suivante :
Lors de l'exécution du générateur de données historisées pour Query Patroller, si les tables Explain n'existent pas déjà, le générateur les créera. Il est cependant fortement recommandé de créer ces tables sur la même partition. Ceci permet d'améliorer les performances de la fonction Explain. Cette amélioration augmente les performances du générateur de données historisées.
Si la colonne Exécution d'un Explain du rapport d'activité des requêtes (analyse historique) affiche un statut Echec de l'exécution pour une requête, les données historiques n'ont pas été générées pour cette requête. La requête n'apparaîtra alors pas dans les rapports ou graphiques d'analyse historique. Comme décrit dans la version 8, vous pouvez examiner le fichier qpuser.log afin de déterminer la cause de l'échec de la requête.
Outre ce fichier, vous devez examiner le fichier qpdiag.log.
Si vous exécutez le générateur de données historisées et l'arrêtez d'une façon anormale, vous recevrez une erreur lorsque vous tenterez de l'exécuter à nouveau. Exemples d'arrêt anormal :
Lorsque le générateur de données historisées s'arrête de façon anormale, vous devez lancer la commande suivante avant de tenter de le réexécuter :
qp -d base de données generate historical_data stop
où base de données identifie la base de données sur laquelle est lancée la commande.
Certaines opérations sur les classes de requêtes ne nécessitent plus l'arrêt et le redémarrage de Query Patroller pour être prises en compte.
Dans le tableau ci-après, une requête active est une requête dont l'état est En cours d'exécution ou Mis en file d'attente.
Les requêtes imbriquées ne peuvent pas être mises en file d'attente. Une requête de ce type s'exécutera immédiatement si elle dépasse un seuil qui entraînerait normalement sa mise en file d'attente.
Contrairement aux informations fournies dans la documentation précédente, les requêtes contenant les instructions suivantes peuvent être mises en file d'attente :
Lors de l'utilisation de Terminal Services Client avec une résolution de 640x480 pour se connecter à une station distante exécutant le Centre Query Patroller, la fenêtre Préférences de soumissions peut être vide. Pour que l'affichage soit correct, utilisez une résolution supérieure à 640x480.
A partir de la version 8.2, DB2 Universal Database (UDB) prend en charge les groupes utilisateur au-delà des groupes du système d'exploitation. Par conséquent, il y a une légère différence dans la liste déroulante Profil de l'émétteur à utiliser dans la fenêtre Préférences de soumission de requêtes du Centre Query Patroller.
Si vous êtes connecté, mais que vous ne disposez pas des droits DBADM ou Edition pour l'administration utilisateur Query Patroller, vous ne pouvez qu'ajouter ou mettre à jour une préférence de soumission pour vous-même. Dans ce cas, la liste déroulante Profil de l'émetteur à utiliser contiendra les profils émetteur existants des groupes DB2 UDB auxquels vous appartenez, et non uniquement les groupes du système d'exploitation auxquels vous appartenez.
Si vous êtes connecté et que vous ne disposez pas des droits DBADM ou Edition pour l'administration utilisateur Query Patroller, vous pouvez ajouter ou mettre à jour une préférence de soumission pour les autres utilisateurs. Dans ce cas, la liste déroulant Profil de l'émetteur à utiliser contiendra toutes les profils d'émetteurs des groupes existants.
Lorsque vous travaillez avec des planifications dans le Centre Query Patroller, vous pouvez utiliser la fenêtre Planification pour enregistrer les planification dans un fichier et les importer ultérieurement. Si votre planification est enregistrée avec le FixPack 6 ou antérieur, vous ne pourrez pas l'importer à l'aide de la version 8.2 ou ultérieure. Cette limitation est due au changement de sérialisation entre les niveaux de JDK introduites avec DB2 UDB version 8.2.
Pour exécuter la commande RUN IN BACKGROUND QUERY, vous devez être l'émetteur qui a soumis d'abord la requête.
Dans Query Patroller Version 8.1 FixPack 5, la création de tables de résultats dans le schéma qui correspondait à l'ID autorisation de l'émetteur de la requête était impossible. Query Patroller commençait par créer des tables de résultats dans un schéma DB2QPRT commun. Pour permettre aux tables de résultats d'être référencées à l'aide du schéma de l'émetteur, Query Patroller Version 8.2 introduit une option pour créer automatiquement un alias pour chaque nouvelle table de résultats créée par Query Patroller. La table de résultats est créée dans le schéma DB2QPRT et l'alias est créé dans un schéma correspondant à l'ID d'autorisation de l'émetteur.
Pour activer/désactiver cette option, émettez la commande UPDATE QP_SYSTEM avec l'option CREATE_RESULT_TABLE_ALIASES :
Les alias créés avec l'option CREATE_RESULT_TABLE_ALIASES sont automatiquement supprimé lorsqu'une table de résultats est supprimée. Toutefois, il existe deux cas où la table de résultats peut être supprimée sans que les alias correspondant soient supprimés.
Pour nettoyer les alias n'ayant pas de tables de résultats correspondantes, un nouvelle commande, REMOVE RESULT_TABLE_ALIASES, a été créée. Cette commande est automatiquement exécutée lorsque les tables de résultats sont purgées (processus de purge planifié). La commande REMOVE RESULT_TABLE_ALIASES permet d'obtenir la liste d'alias à purger à l'aide de la requête suivante :
with a as (select tabschema, tabname from syscat.tables
where type = 'A' and tabname like 'QUERY%_RESULTS'),
t as (select tabname from syscat.tables
where type = 'T' and tabname like 'QUERY%_RESULTS')
select all tabschema, tabname from a
where not exists (select * from t where t.tabname=a.tabname)
Vous devez disposer des droits DBADM.
Cette commande supprimer tous les alias existant après avoir supprimé les tables correspondantes. Les alias ont été créés par Query Patroller pour les tables de résultats.
Query Patroller utilise des procédures mémorisées isolées pouvant consigner des entrées dans le fichier qpdiag.log. Par conséquent, l'ID utilisateur isolé a besoin d'un accès en écriture au fichier journal qpdiag.log et du chemin d'accès de ce fichier.
[ Début de page |Page précédente | Page suivante | Table des matières ]