Requêtes ad hoc sur des fichiers de production

voir si les jobs exécutaient des requêtes utilisateur. Si les requêtes ont mis longtemps à s’exécuter, vous pouvez voir le fichier sur lequel elles travaillaient, via les vues Job Watcher ou en interrogeant le fichier TDE QAPYJWTDE de Job Watcher Collection.

Le contrat de niveau de service (SLA, service level agreement) de Company aBc permet à ses clients de soumettre des requêtes SQL, OPNQRYF ou AS400 Query sur les fichiers base de données de production, sur le système de production. S’il est vrai que le type de requête ne change pas l’effet sur le système, il est important de savoir si la requête va causer de longs conflits pour le fichier soumis à requête. En effet, certains utilisateurs n’hésitent pas à soumettre des requêtes complexes et ad hoc sans se soucier de la charge qu’ils infligent au système. Dans ce cas, d’autres jobs sont temporairement empêchés de changer le fichier si une requête a besoin de construire un index. Cela se produit généralement pendant un court instant, pendant qu’un pointeur vers le nouvel index est ajouté à l’en-tête du fichier. Ensuite, le mécanisme de construction d’index détient une saisie de fichier partagée que les fonctions de base de données SLIC (System Licensed Internal Code) surveillent périodiquement et libèrent temporairement s’il y a une mise à jour en suspens.

Les délais causés par la construction de l’index peuvent s’avérer trop longs pour les transactions de haute priorité du client. Mais, direz-vous, la priorité des jobs pour la CPU se charge de cela, non ? Détrompez-vous ! Le fichier est indisponible pendant une partie de la construction de l’index et même si la requête s’exécute avec une priorité zéro, sa performance est essentiellement constituée de beaucoup de temps d’attente d’I/O disque.

Il existe un compromis entre exécuter des requêtes ad hoc d’une part et définir et maintenir les fichiers logiques supplémentaires pour un fichier physique, d’autre part. Les deux options peuvent allonger le temps d’attente et la longueur du chemin, dans différents programmes. Si la charge de la requête est suffisamment pénalisante, il vaudra peutêtre mieux créer des index supplémentaires. Une médiocre stratégie d’indexation est en principe plus pénalisante que la charge de maintenance, même si cela peut ne pas être vrai pour les périodes de changement intensif. La V5R4 possède une fonction index advisor qui vous aidera à déterminer les index les plus bénéfiques.

Les requêtes ODBC et JDBC ont, par défaut, le priorité 20. Une requête ad hoc de priorité 20 avec beaucoup d’I/O et de traitement a des effets négatifs sur la production. Pour repérer et arrêter proactivement ces requêtes, définissez une valeur limite de temps de requête appropriée (System Value QQRYTIMLMT). Construisez et maintenez un ODS (operational data store) ou un entrepôt de données sur un autre système, pour faciliter les requêtes ad hoc productives. Les techniques miroir haute disponibilité sont aussi un excellent moyen de peupler le stockage de données.

Utiliser la fonction de journal à distance sur i5/OS et une fonction apply bien réglée sur une boîte de sauvegarde, est un bon moyen de faciliter d’autres solutions éventuelles, comme exécuter des requêtes ad hoc sur le système de sauvegarde. Pour plus d’informations, lire l’IBM Redbook Striving for Optimal Journal Performance on DB2 Universal Database for iSeries (SG24-6286) à www.redbooks.ibm.com).