Szenario: pureQuery-Clientoptimierung von einer Test- in eine Produktionsumgebung migrieren

Sie aktivieren eine Anwendung in einer Testumgebung für die pureQuery-Clientoptimierung. Nach Abschluss der erforderlichen Tests wie den Tests der Anwendungsfunktion und -leistung und nach dem Prüfen der SQL-Anweisungen und Bindeprozeduren können Sie die Anwendung in einer Produktionsumgebung implementieren.
Dieses Thema beschreibt, wie Sie die für die Datenbank zu bindenden Pakete in die Produktionsumgebung versetzen bzw. dort erstellen können, und enthält die folgenden Abschnitte:

In einer idealen Umgebung führen Sie die für die pureQuery-Clientoptimierung aktivierte Anwendung aus, erfassen Sie SQL-Daten und testen Sie die statische SQL-Ausführung in einer Umgebung, die mit der Produktionsumgebung identisch ist. Identische Test- und Produktionsumgebungen sind jedoch nicht immer möglich. Beispielsweise verwenden Testsysteme möglicherweise DB2 for Linux, UNIX, and Windows, während die Produktionsumgebung DB2 for z/OS verwendet.

Beim Migrieren einer für die pureQuery-Clientoptimierung aktivierten Anwendung müssen Sie möglicherweise die Merkmale der DB2-Pakete wie die Paket- und Objektgruppennamen ändern, die sich in der pureQueryXML-Datei befinden. Nach der Ausführung des Dienstprogramms Configure für die pureQueryXML-Datei mit produktionsspezifischen Optionen können Sie die Pakete mit dem Dienstprogramm StaticBinder in der Produktionsdatenbank erstellen und sie für die Datenbank binden.

Sie können auch die in der Produktionsumgebung zu verwendenden pureQuery Runtime-Eigenschaften und pureQueryXML-Daten migrieren. Sie müssen möglicherweise die Eigenschaften finalRepositoryProperties, captureMode und allowDynamicSQL modifizieren.

Wenn Sie ein Repository verwenden, können Sie auch ein Repository in der Produktionsumgebung erstellen, die Laufzeitgruppenversion für die Anwendung erstellen und pureQuery Runtime-Eigenschaftsinformationen sowie die pureQueryXML-Datei in das Repository hochladen.

Beispiel für das Migrieren von SQL-Anweisungen mit den pureQuery-Dienstprogrammen Configure und StaticBinder

In den vorherigen Tasks im Szenario haben Sie eine Anwendung für die pureQuery-Clientoptimierung auf einem Testsystem konfiguriert. Nach dem Abschluss der Tests wollen Sie nun die SQL-Anweisungen in der pureQueryXML-Datei für die Produktionsdatenbank binden. Im folgenden Beispiel wird vorausgesetzt, dass die Produktionsobjektgruppe PRODCOL und QUALIFIER PROD ist. Sie aktualisieren dementsprechend die Datenquelle mit der richtigen Einstellung packagePath, damit die Pakete erkannt werden. Bei den Beispielen in diesem Thema wird auch vorausgesetzt, dass die Produktionsdatenbank den Paketnamen PRODPKG verwendet.

Als Teil der Migration rufen Sie die in der Testumgebung erstellte pureQueryXML-Datei ab. Wenn sich die Datei in einem Repository befindet, extrahieren Sie die Datei mit dem pureQuery-Dienstprogramm ManageRepository. Sie führen einen Befehl aus, der dem folgenden Befehl ähnelt:
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 

Nach dem Abrufen der Datei führen Sie die pureQuery-Dienstprogramme Configure und StaticBinder für die pureQueryXML-Datei mit den entsprechenden Optionen aus.

Die Ausführung des folgenden Dienstprogramms Configure ändert den Stammpaketnamen in PRODAPPL und die Standardobjektgruppe in PRODCOL. Die Option -cleanConfigure true gibt an, dass alle SQL-Anweisungen in der pureQueryXML-Datei verarbeitet sind. Hierzu gehören neben den neuen auch vorhandene SQL-Anweisungen. Die Option -replaceSchemas ändert den in der pureQueryXML-Datei angegebenen Schemanamen von TEST in PROD. Mit der Option -validateXml true stellt das Dienstprogramm Configure mittels XML-Schemaüberprüfung sicher, dass die Eingabedatei eine gültige pureQueryXML-Datei ist:
java com.ibm.pdq.tools.Configure -pureQueryXml prodApp.pdqxml 
  –validateXml true
  –collection PRODCOL 
  -rootPkgName PRODAPPL 
  -replaceSchemas "(TEST>PROD)"
  -cleanConfigure true
Die Ausführung des Dienstprogramms StaticBinder für den Zieldatenbankserver mit den folgenden Optionen erstellt Pakete, die SQL-Anweisungen aus der pureQueryXML-Datei in der Datenbank enthalten, und bindet die Pakete:
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

Wenn Sie die Option -showDetails true angeben, zeigt das Dienstprogramm StaticBinder Übersichtsdaten zu den erstellten DB2-Paketen an.

Die StaticBinder-Option -isolationLevel CS gibt an, dass StaticBinder ein einzelnes Paket mit der Isolationsstufe CS (Cursorstabilität) erstellt. Die Isolationsstufe CS ist die Standardstufe für Datenbanken von DB2 for Linux, UNIX, and Windows.

Die Ausgabe des StaticBinder-Befehls ähnelt dem folgenden Beispiel:
Das Dienstprogramm StaticBinder beginnt, die pureQueryXml-Datei capture.xml zu binden.

Start der Verarbeitung von Optionen: -username "*****" -password "*****" 
 -url "jdbc:db2://prodserver.prod.com"
 -pureQueryXml prodApp.pdqxml 
 -isolationLevel "CS" 
 -bindOptions "QUALIFIER PROD" 
 

Das Dienstprogramm StaticBinder hat das Paket 'PRODAPPL2' für die Isolationsstufe 'CS' erfolgreich gebunden.

Änderungen an den Identifikationsinformationen für statisches SQL bei der Migration in eine Produktionsumgebung

Bei der Migration einer Anwendung in eine Produktionsumgebung müssen möglicherweise Identifikationsinformationen für statisches SQL wie Konsistenztokens und Paketversionen geändert werden.

Änderungen an Konsistenztokens und Paketversionen
Soll ein DB2-Paket unter Beibehaltung derselben Konsistenztoken- und Paketversionsinformationen in ein anderes DB2-Subsystem oder eine andere DB2-Datenbank migriert werden, führen Sie das Dienstprogramm StaticBinder mit der pureQueryXML-Datei aus, um es für zusätzliche DB2-Datenbanken oder -Subsysteme zu binden. Während der Migration können Sie sicherstellen, dass Konsistenztokens in der pureQueryXML-Datei und in den DB2-Paketversionen weiterhin übereinstimmen, wenn Sie die pureQueryXML-Datei nicht modifizieren. Wenn Sie die Datei modifizieren und das Dienstprogramm Configure verwenden, ändert sich das Konsistenztoken möglicherweise. Informationen zu Konsistenztokens und DB2-Paketversionen finden Sie in DB2-Paketidentifikationsinformationen.
Anmerkung: Das pureQuery-Dienstprogramm Configure ändert Konsistenztokens, wenn Änderungen an Anweisungsgruppen erforderlich sind. Wenn Sie die pureQueryXML-Datei konfigurieren müssen und die Konsistenztokens nicht ändern wollen, müssen Sie sicherstellen, dass das Dienstprogramm Configure keine vorhandenen benannten Anweisungsgruppen in der pureQueryXML-Datei ändert. Konfigurieren Sie z. B. die Datei nicht mit der Option -setPreStatusOfAllPkgs REQUIRED oder -cleanConfigure true.
Änderungen an JDBC-Eigenschaften
Wenn sich die Objektgruppen-ID auf dem Testsystem und Produktionssystem unterscheidet, müssen Sie die entsprechende Laufzeitumgebung aktualisieren, um die richtige Objektgruppe während der Migration von Paketen zwischen DB2-Subsystemen anzugeben. Die Objektgruppe wird als Teil der WebSphere-Datenquellendefinition mit der Eigenschaft currentPackageSet (oder mit der Eigenschaft currentPackagePath für DB2 for Linux, UNIX, and Windows bzw. DB2 for z/OS) angegeben.

Beispiel

Wenn die angepasste WebSphere-JDBC-Provider-Eigenschaft currentPackageSet während der Ausführung für die WebSphere Application Server-Datenquelle nicht auf PRODCOL1B gesetzt ist, wird die Objektgruppe PRODCOL in der pureQueryXML-Datei verwendet. Das Paket wird auf STLEC1B nicht gefunden und SQLCODE 805 wird an die Anwendung zurückgegeben.

Wenn Sie über dynamische SQL-Anweisungen verfügen, müssen Sie die Datenquelleneigenschaft currentPackagePath angeben. Wenn die dynamischen JDBC-Pakete für die Objektgruppe NULLID gebunden sind, müssen Sie den Wert der Eigenschaft currentPackagePath für die WebSphere Application Server-Datenquelle auf PRODCOL1B,NULLID setzen.

In eine Datenbank von DB2 for z/OS migrieren
Zusätzlich zum Dienstprogramm StaticBinder bietet DB2 for z/OS den fernen DSN-Befehl BIND COPY, mit dem Sie das Paket für ein anderes System mit DB2 for z/OS erneut binden können. Sie setzen den Befehl BIND PACKAGE mit dem Namen des fernen Standorts im Argument BIND PACKAGE ab und geben die Option COPY an.

Beispiel

Wenn die SQL-Anweisungen in der pureQueryXML-Datei zum Testen für einen Standort gebunden sind, z. B. STLEC mit der Objektgruppe PRODCOL, können Sie das Paket mit dem Befehl BIND COPY an den Produktionsort STLEC1B mit der Objektgruppe PRODCOL1B kopieren.


Feedback