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.
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.
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.
java com.ibm.pdq.tools.Configure -pureQueryXml prodApp.pdqxml
–validateXml true
–collection PRODCOL
-rootPkgName PRODAPPL
-replaceSchemas "(TEST>PROD)"
-cleanConfigure true
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.
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.
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.
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.
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