Scénario : Migration de l'optimisation client pureQuery d'un environnement de test vers un environnement de production

Vous activez une application avec l'optimisation client pureQuery dans un environnement de test. Une fois que vous avez effectué les tests requis, tels que le test des fonctionnalités et des performances de l'application, et que vous avez vérifiez les instructions SQL et les procédures d'édition de liens, vous pouvez déployer l'application dans un environnement de production.
Cette rubrique décrit comment déplacer ou créer les packages à lier à la base de données dans l'environnement de production et contient les sections suivantes :

Dans l'environnement idéal, vous exécutez l'application qui est activée à l'aide de l'optimisation client pureQuery, vous capturez les données SQL et testez l'exécution de l'instruction SQL qui s'exécute de façon statique dans un environnement identique à l'environnement de production. Toutefois, il n'est peut-être pas possible de disposer d'environnements de test et de production identiques. Par exemple, les systèmes de test peuvent utiliser DB2 for Linux, UNIX et Windows, alors que l'environnement de production utilise DB2 for z/OS.

Lorsque vous migrez une application qui est activée avec l'optimisation client pureQuery, il vous faudra peut-être modifier les caractéristiques des packages DB2 telles que les noms de package et de collection se trouvant dans le fichier pureQueryXML. Après avoir exécuté l'utilitaire Configure sur le fichier pureQueryXML à l'aide d'options spécifiques à la production, vous pouvez utiliser l'utilitaire StaticBinder pour créer les packages dans la base de données de production et lier les packages à la base de données.

Vous pouvez également migrer les propriétés d'exécution de pureQuery et les données pureQueryXML à utiliser dans l'environnement de production. Vous devrez peut-être modifier les propriétés finalRepositoryProperties, captureMode et allowDynamicSQL.

Si vous utilisez un référentiel, créez également un référentiel dans l'environnement de production, créez la version du groupe d'exécution pour l'application et chargez dans le référentiel les informations de propriété d'exécution de pureQuery ainsi que le fichier pureQueryXML.

Exemple de migration des instructions SQL à l'aide des utilitaires de configuration pureQuery et StaticBinder

Dans les tâches précédentes du scénario, vous avez configuré une application avec l'optimisation client pureQuery sur un système de test. Une fois le test terminé, vous souhaitez maintenant lier les instructions SQL du fichier pureQueryXML vers la base de données de production. Les exemples suivants supposent que la collection de production est PRODCOL et QUALIFIER PROD. Vous devez donc mettre à jour la source de données avec le paramètre packagePath correct afin que les packages soient reconnus. Les exemples de cette rubrique supposent également que la base de données de production utilise la convention de dénomination de package PRODPKG.

Lors de la migration, vous récupérez le fichier pureQueryXML créé dans l'environnement de test. Si le fichier se trouve dans un référentiel, vous extrayez le fichier à l'aide de l'utilitaire pureQuery ManageRepository. Vous exécutez une commande du type suivant :
java com.ibm.pdq.tools.ManageRepository 
  -extract runtimeGroup 
  -repositoryDriverClass com.ibm.db2.jcc.DB2Driver 
  -repositoryURL "jdbc:db2://testserver.test.com:32706/sample" 
  -repositoryUsername "myuser" -repositoryPassword "mypwd" 
  -runtimeGroupId testApp -runtimeGroupVersion V2 
  -outputDirectory C:\TEMP\out 
  –pureQueryXml prodApp.pdqxml 

Après avoir récupéré le fichier, vous exécutez les utilitaires de configuration pureQuery et StaticBinder sur le fichier pureQueryXML à l'aide des options appropriées.

Exécuter l'utilitaire Configure suivant modifie le nom du package racine par PRODAPPL et modifie la collecte par défaut par PRODCOL. L'option -cleanConfigure true spécifie que toutes les instructions SQL du fichier pureQueryXML sont traitées, notamment toutes les instructions SQL existantes et les nouvelles instructions SQL. L'option -replaceSchemas remplace le nom de schéma TEST spécifié dans le fichier pureQueryXML par PROD. Suivi de l'option -validateXml true, l'utilitaire Configure garantit que le fichier d'entrée est un fichier pureQueryXML valide en effectuant la validation du schéma XML sur le fichier :
java com.ibm.pdq.tools.Configure -pureQueryXml prodApp.pdqxml 
  –validateXml true
  –collection PRODCOL 
  -rootPkgName PRODAPPL 
  -replaceSchemas "(TEST>PROD)"
  -cleanConfigure true
Exécuter l'utilitaire StaticBinder sur le serveur de base de données cible avec les options suivantes crée des packages qui contiennent des instructions SQL provenant du fichier pureQueryXML dans la base de données et lie les packages :
java com.ibm.pdq.tools.StaticBinder 
  –url jdbc:db2://prodserver.prod.com:446/STLEC1” 
  -username "myuser" -password "mypwd" 
  -isolationLevel CS 
  -bindOptions "QUALIFIER PROD" 
  -pureQueryXml prodApp.pdqxml 
  -showDetails true

Lorsque vous indiquez l'option -showDetails true, l'utilitaire StaticBinder affiche des informations récapitulatives concernant les packages DB2 qu'il produit.

L'option StaticBinder -isolationLevel CS spécifie que StaticBinder crée un seul package avec un niveau d'isolement de lecture non reproductible. Le niveau d'isolement de lecture non reproductible est le niveau par défaut des bases de données DB2 for Linux, UNIX et Windows.

Le résultat de la commande StaticBinder est identique à l'exemple suivant :
L'utilitaire
StaticBinder commence par lier le fichier pureQueryXml capture.xml.

Début de traitement des options : -username "*****" -password "*****" 
 -url "jdbc:db2://prodserver.prod.com"
 -pureQueryXml prodApp.pdqxml 
 -isolationLevel "CS" 
 -bindOptions "QUALIFIER PROD" 
 

L'utilitaire StaticBinder a lié avec succès le package 'PRODAPPL2' pour le niveau
d'isolement de lecture non reproductible.

Modifications des informations d'identification SQL statiques lors de la migration vers un environnement de production

Lorsque vous migrez une application vers un environnement de production, des informations d'identification SQL statiques telles que les marques de cohérence et les versions des packages peuvent nécessiter des changements.

Modifications des marques de cohérence et des versions de package
Pour migrer un package DB2 vers un autre sous-système ou une autre base de données DB2 tout en conservant les mêmes marque de cohérence et informations de version de package, exécutez l'utilitaire StaticBinder avec le fichier pureQueryXML afin de lier les bases de données ou sous-systèmes DB2 supplémentaires. Lors de la migration, vous pouvez garantir la concordance des marques de cohérence dans le fichier pureQueryXML et dans les versions de package DB2 si vous ne modifiez pas le fichier pureQueryXML. Si vous modifiez le fichier et que vous utilisez l'utilitaire Configure, la marque de cohérence peut être modifiée. Pour des informations sur les marques de cohérence et les versions de package DB2, voir Informations d'identification du package DB2.
Remarque : L'utilitaire Configure pureQuery modifie les marques de cohérence lorsque des modifications des ensembles d'instructions sont nécessaires. Si vous devez configurer le fichier pureQueryXML mais que vous ne souhaitez pas modifier les marques de cohérence, vous devez vous assurer que l'utilitaire Configure ne modifie pas les ensembles d'instructions existants nommés dans le fichier pureQueryXML. Par exemple, ne configurez pas le fichier avec l'option -setPreStatusOfAllPkgs REQUIRED ou l'option -cleanConfigure true.
Modifications apportées aux propriétés JDBC
Si l'ID collection est différent sur le système de test et sur le système de production, vous devez mettre à jour l'environnement d'exécution correspondant afin de spécifier la collecte correcte lors de la migration des packages entre les sous-systèmes DB2. La collecte est définie dans la définition de source de données WebSphere à l'aide de la propriété currentPackageSet (ou la propriété currentPackagePath pour DB2 pour Linux, UNIX et Windows ou DB2 pour z/OS).

Exemple

Lors de l'exécution, si la propriété personnalisée currentPackageSet du fournisseur JDBC WebSphere n'est pas définie par PRODCOL1B sur la source de données WebSphere Application Server, le paramètre de collecte PRODCOL du fichier pureQueryXML est utilisé. Le package ne sera pas détecté sur STLEC1B et SQLCODE 805 sera renvoyé à l'application.

Si vous disposez d'instructions SQL dynamiques, vous devez alors indiquer la propriété de source de données currentPackagePath. Si les packages dynamiques JDBC sont liés à l'ID collection NULLID, vous devez définir la valeur de la propriété currentPackagePath de la source de données WebSphere Application Server sur PRODCOL1B,NULLID.

Migration sur une base de données DB2 for z/OS
En plus de l'utilitaire StaticBinder, DB2 for z/OS fournit la commande DSN distante BIND COPY, qui peut être utilisée pour lier à nouveau le package sur un système DB2 for z/OS différent. Vous lancez la commande BIND PACKAGE à l'aide du nom d'emplacement distant dans l'argument BIND PACKAGE et vous spécifiez l'option COPY.

Exemple

Si les instructions SQL du fichier pureQueryXML sont liées à un emplacement à des fins de test, par exemples, STLEC, avec le paramètre de collecte PRODCOL, vous pouvez utiliser la commande BIND COPY pour copier le package sur l'emplacement de production STLEC1B avec le paramètre de collecte PRODCOL1B


Commentaires