Gérer les jobs base de données

les jobs base de données associés au serveur d’applications.

Il faut séparer les jobs base de données pour pouvoir contrôler la quantité de paging mémoire et la priorité des jobs. La priorité d’exécution des jobs de connexion à la base de données peut n’être pas assez élevée pour délivrer les temps de réponse désirés. Le serveur d’applications met en pool les connexions base de données. Une connexion dans le pool est l’équivalent d’un job iSeries actif. La priorité de ces jobs doit être ajustée. Pour changer la priorité d’un job, une astuce consiste à exécuter une procédure stockée dans le job base de données associé à une connexion dans le pool. Cette procédure stockée ne doit s’exécuter qu’une fois : la première fois que la connexion est extraite du pool. Pour ce faire, vous devez exécuter la procédure stockée la première fois qu’une connexion est obtenue de la part du pool. Une fois la procédure stockée exécutée, placez un attribut arbitraire sur l’objet connexion pour vous faire savoir que vous avez déjà changé la priorité du job.

Il est un peu plus difficile de contrôler le paging (c’est-àdire la quantité de mémoire associée aux jobs base de données). En séparant les jobs base de données dans leur propre pool mémoire, vous pouvez contrôler la quantité de mémoire dont ils disposent. Pour cela, vous devez acheminer les jobs base de données vers leur propre soussystème. En V4R4, IBM a introduit une fonction qui permet aux administrateurs système de personnaliser le soussystème dans lequel certains jobs du serveur hôte s’exécutent. Certains jobs peuvent désormais être exécutés dans n’importe quel sous-système, y compris ceux définis par l’utilisateur. (La technique à cet effet est aussi décrite dans « Host Server Customization Requirements for TCP/IP Address Subnet Mask ».)

En outre, vous pouvez acheminer les mêmes types de requêtes client vers de multiples sous-systèmes d’après l’adresse TCP/IP du client. Cela permet aux administrateurs système de contrôler les propriétés de gestion des tâches (par exemple, priorité des jobs, pool de stockage), soussystème par sous-système. Vous allez réacheminer les jobs vers un sous-système séparé d’après l’adresse IP du serveur d’applications. En appliquant ce niveau de contrôle, vous pouvez établir n’importe quel paramètre sur la description du job, la classe du job ou le sous-système avec des options personnalisées.

Dans le même esprit, la V5R3 vous permet d’acheminer le travail d’après l’ID utilisateur. Vous utiliserez pour cela le nouveau job commutateur, API QWCCHGJP (les PTF SI19363 et SI19279 sont nécessaires pour cette API). Par conséquent, vous pouvez acheminer votre connexion base de données avec un ID utilisateur donné vers le sous-système choisi. Le lissage des temps de réponse peut aussi être délicat si l’on s’appuie sur DB2 SMP (Symmetric Multiprocessing). Certes, cette fonction peut exécuter quelques requêtes rapidement quand des ressources substantielles sont appliquées à la requête. En revanche, quand le système gère diverses charges de travail, les requêtes comptant sur la fonction SMP seront très ralenties. Nous vous conseillons d’éviter l’utilisation de SMP de DB2 comme moyen d’accélération des performances dans un environnement OLTP. S’il est vrai que SMP joue un rôle important dans le calcul, il s’agit ici d’éviter son utilisation à mauvais escient. Autrement dit, ne demandez pas à SMTP de pallier deux points déficients : mauvaise conception des fichiers et médiocre administration de la base de données.