> Tech > Considérations

Considérations

Tech - Par iTPro - Publié le 24 juin 2010
email

Bien que la réutilisation des ODP puisse nécessiter de la mémoire supplémentaire, leur non-réutilisation provoque un nombre élevé de défauts non-base de données. Face à ce problème, beaucoup de clients ont augmenté la mémoire ; pourtant, les défauts restent aussi nombreux. Dès lors que l’on a modifié les applications, la

Considérations

quantité de mémoire existante est généralement suffisante.

Contrairement à RLA, il n’y a pas de partage des ODP entre les instructions SQL. Si le programme A et le programme B contiennent tous deux la même instruction SQL et si tous deux sont appelés dans le même job, chaque programme aura un ODP séparé. Cette forme de doublon d’ODP peut être résolue en isolant les instructions SQL dans les modules d’I/O appelés, ou partagés, par les deux programmes.
Comme SQL ne partage pas les ODP, il n’y a aucun intérêt à pré-ouvrir les fichiers avec la commande OPNDBF (Open Database File).

On peut modifier le comportement normal de SQL pour qu’il réutilise les ODP non pas après la seconde exécution mais après la première, en créant une zone de données nommée QSQPSCLS1 dans une bibliothèque de votre choix. DB2 recherche cette zone de données dans la liste des bibliothèques d’un job au début de chaque job. Si DB2 trouve la zone de données, tous les ODP qui sont candidats à la réutilisation ne seront pas supprimés après la première exécution. Le contenu, le type et la longueur de l a zone de données n’ont pas d’importance. La première transaction traitée paiera tout le prix, et les transactions suivantes bénéficieront de l’utilisation de l’ODP existant.

Le remplacement des membres provoque la revalidation du plan d’accès et, parfois, la suppression et la recréation des ODP. On n’améliorera pas la performance en créant un sous-ensemble physique de données sur la plate-forme iSeries/i5 via le support de membres. En fait, on ne peut pas créer un index SQL ou visualiser par-dessus un membre autre que le premier membre d’un fichier physique. Le moment est donc venu de songer à reconcevoir les bases de données avec membres multiples pour en faire une table base de données unique.

Le fait de changer les listes de bibliothèques se traduit par la revalidation du plan d’accès et, parfois, la suppression et la recréation des ODP pour des instructions SQL non qualifiées fonctionnant sous le nommage système (bibliothèque/ fichier) par rapport au nommage SQL (schema.

table). Revoyez les exigences de gestion pour utiliser ce type de technique pour isoler les bases de données. Beaucoup d’entreprises ont des systèmes de développement séparés pour la compilation et le test, ce qui dispense de changer les listes de bibliothèques. Si vous devez séparer des données pour des raisons de sécurité (c’est-à-dire, données Société A versus données Société B), considérez le support IASP (Independent ASP). Avec cette fonction, de multiples bases de données peuvent coexister sur un système iSeries/i5 unique avec des noms de schémas (bibliothèque) identiques.

En séparant l’I/O dans des modules indépendants et en déployant ceux-ci sur toutes les bases de données, on peut réduire l’effet de la validation du plan d’accès – particulièrement si l’on utilise la qualification (spécifiant le schéma et table). Aujourd’hui, chaque instruction SQL qualifiée qui est optimisée par le nouveau moteur SQE peut stocker jusqu’à trois plans dans le cache de plans SQE.

Téléchargez gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

Tech - Par iTPro - Publié le 24 juin 2010