Features und Vorteile der pureQuery-Clientoptimierung

Die Aktivierung einer Java™-Anwendung für die pureQuery-Clientoptimierung kann die Anwendungssicherheit, Wartungsfreundlichkeit und Leistung verbessern. Ein wesentlicher Vorteil der pureQuery-Clientoptimierungsaktivierung ist die Fähigkeit, dynamische SQL-Ausführung durch die Anwendung in statische SQL-Ausführung zu konvertieren.
Andere Vorteile der pureQuery-Clientoptimierung: Mit der pureQuery-Clientoptimierung kann ein Datenbankadministrator das im Unternehmen vorhandene Know-how zum Verwalten der Anwendungen verwenden.
In den folgenden Abschnitten werden die Vorteile der pureQuery-Clientoptimierung und der statischen SQL-Ausführung in den folgenden Bereichen beschrieben:

Zusammenfassung der Features und Vorteile

In der folgenden Liste wird die Funktionalität zusammengefasst, die für die pureQuery-Clientoptimierung verfügbar ist:
  • Unabhängigkeit des Entwicklungsframeworks
  • Toolintegration (mit Optim-Produkten)
  • SQL-Anweisungsabruf
  • Ermittlung von leistungsschwachem SQL (bei der Arbeit mit anderen Optim-Produkten)
  • Erfassung von SQL-Leistungsdaten (bei der Arbeit mit anderen Optim-Produkten)
  • Erfassung der Datentypinformationen von SQL-Anweisungen
  • Dynamische oder statische Ausführung von SQL-Anweisungen
  • Ausführung nur des zuvor erfassten SQL
  • Fähigkeit, SQL-Literale durch SQL-Parametermarken zu ersetzen
  • SQL-Anweisungsersetzung
In der folgenden Liste werden die Vorteile der statischen Ausführung von SQL-Anweisungen zusammengefasst:
  • Konsistente SQL-Leistung
  • Vorhersehbare SQL-Zugriffspläne
  • Verbesserte Datenbanksicherheit bei der Ausführung von SQL
  • Reduzierter Datenaustausch im Netz
  • Ausschluss von PREPARE- und DESCRIBE-Laufzeitanweisungen
  • SQL-Anweisungsabruf
  • Verfolgung der SQL-Ausführung
  • DB2-EXPLAIN-Unterstützung
  • Fähigkeit, leistungsschwaches SQL zu ermitteln
  • Ausführungsspezifische Fehlerinformationen

Entwicklungsprozessvorteile

Sie können Anwendungen in einer flexiblen Umgebung entwickeln, testen und implementieren.

Dies bietet u. a. die folgenden Vorteile:
Wahl des Frameworks während der Entwicklung
Bei der Java-Anwendungsentwicklung stehen Anwendungsentwicklern mehrere Technologien für den Datenzugriff zur Verfügung. Die pureQuery-Clientoptimierung arbeitet mit den Frameworks und schränkt die Auswahl eines bestimmten Frameworks für die Anwendungsentwicklung nicht ein.

Beispielsweise können Frameworks wie Spring, iBatis und Java Persistence Architecture (JPA) während der Entwicklung verwendet werden. Die pureQuery-Clientoptimierung arbeitet mit dem JDBC-Treiber und ist von den darüber liegenden Ebenen der Anwendungslogik nicht betroffen. Entwickler können weiterhin Anwendungen entwickeln, die dynamisches SQL verwenden, und brauchen sich nicht mit der Semantik von statischem SQL und den entsprechenden Implementierungsaspekten auseinander zu setzen.

Die pureQuery-Clientoptimierung ist mehr ein Konfigurationsschritt als ein Entwicklungsschritt. Die pureQuery-Clientoptimierung muss während der integrierten Anwendungstests aktiviert sein. Die Erfassung von SQL-Anweisungen während des Tests stellt sicher, dass die meisten SQL-Anweisungen erfasst und in statische Ausführung konvertiert werden, um die maximalen Vorteile statischer SQL-Ausführung zu erzielen.

Eine pureQueryXML-Datei enthält SQL-Anweisungen und kann von einer Anwendung verwendet werden, die für die pureQuery-Clientoptimierung aktiviert ist. Sie können eine pureQueryXML-Datei mit einer der folgenden Ressourcen erstellen:
  • XML-Dateien der JPA-Anwendung: Wenn Sie die IBM® JPA-Implementierung verwenden, können Sie mit dem Dienstprogramm wsdb2gen eine XML-Datei generieren, die die in den Persistenzeinheiten verwendeten SQL-Anweisungen enthält.

    Die mit dem Dienstprogramm wsdb2gen generierte Datei ist mit der pureQuery-Clientoptimierung kompatibel. Mit dieser Datei können Sie optional zusätzliche SQL-Anweisungen für eine Anwendung erfassen, die für die pureQuery-Clientoptimierung aktiviert ist. Die Datei enthält die vom Dienstprogramm wsdb2gen erstellten SQL-Anweisungen und alle zusätzlichen SQL-Anweisungen, die von pureQuery Runtime erfasst wurden. Sie verwenden die Datei mit den pureQuery-Dienstprogrammen Configure und StaticBinder, um DB2-Pakete zu erstellen, die die SQL-Anweisungen enthalten, und um die Pakete für die Datenbank zu binden.

  • SQL-Textdateien: Einige Anwendungen grenzen die in der Anwendung verwendeten SQL-Anweisungen in eine Textdatei ein und verarbeiten die Datei mit der Anwendungslogik. Die Textdatei enthält die SQL-Anweisungen, die durch ein Trennzeichen wie ein Semikolon (;) voneinander getrennt sind. Mit dem pureQuery-Dienstprogramm GeneratePureQueryXml können Sie aus der Textdatei eine pureQueryXML-Datei generieren.

    Nach der Erstellung einer pureQueryXML-Datei mit dem Dienstprogramm GeneratePureQueryXml können Sie die Datei mit pureQuery Runtime verwenden, um zusätzliche SQL-Anweisungen zu erfassen, oder Sie können die Datei mit den pureQuery-Dienstprogrammen Configure und StaticBinder verwenden, um DB2-Pakete zu erstellen, die die SQL-Anweisungen enthalten, und um die Pakete für die Datenbank zu binden.

Wahl zwischen dynamischer oder statischer SQL-Ausführung
Wenn eine Anwendung für die pureQuery-Clientoptimierung aktiviert ist, können Sie angeben, welche SQL-Anweisungen von der Anwendung statisch und welche dynamisch ausgeführt werden sollen. Sie können z. B. entscheiden, dass die kritischsten SQL-Anweisungen statisch und andere SQL-Anweisungen dynamisch ausgeführt werden sollen.

Entwickler brauchen Details der Datenbankartefakte, die sich auf die statische SQL-Ausführung auswirken, oder die Implementierungsschritte, die zum Konvertieren der der Anwendung für statische SQL-Ausführung erforderlich sind, nicht zu kennen oder zu verstehen. Entwickler können Anwendungen entwickeln, die SQL basierend auf dem ihnen vertrautem Framework dynamisch ausführen. Entwickler können sich auf die Funktionsbeschreibung und Geschäftslogik der Anwendung konzentrieren. Die Datenbankadministratoren können sich auf die Implementierung und Optimierung der von der Anwendung verwendeten SQL-Anweisungen konzentrieren.

Bei statischer SQL-Ausführung kann die pureQuery-Clientoptimierung die Funktion für Paketversionssteuerung von statischem SQL auf einem DB2-Datenbankserver verwenden. Statische SQL-Ausführung ermöglicht einen schrittweisen Rollout mit gleichzeitiger Ausführung des neuen Anwendungscodes und der DB2-Zugriffsplanänderungen. Mit der Paketversionssteuerung können Sie vorhandene DB2-Pakete speichern und neue Pakete erstellen. Mit Paketversionen können Sie eine klare und einfache Rückübertragungsprozedur erstellen, falls sich die Änderungen negativ auswirken.

In JDBC-basierten dynamischen SQL-Anwendungen gibt es bei DB2-Zugriffsplanänderungen keine Rückübertragungsprozedur. Bei statischer SQL-Ausführung können Sie SQL mithilfe der Paketversionssteuerung mit einem zuvor generierten Zugriffsplan ausführen.

Anmerkung: Bei Anwendungen, die für die pureQuery-Clientoptimierung aktiviert sind, wird für statische SQL-Ausführung empfohlen, dass die Konfigurations- und Bindeschritte für die abgeschlossene Anwendung in einer Testphase ausgeführt werden, bevor die Anwendung in eine Produktionsumgebung migriert wird. Die Ausführung der Schritte in der Testphase stellt umfangreiche Tests und eine umfassende Überprüfung der Implementierung und statischen Ausführung von SQL-Anweisungen sicher. Informationen zu den Schritten für die Aktivierung der purQuery-Clientoptimierung finden Sie in Schritte zur Aktivierung der pureQuery-Clientoptimierung.
Toolintegration
Die pureQuery-Clientoptimierung ist in Optim Development Studio integriert. Sie können pureQuery für ein Java-Projekt aktivieren. Optim Development Studio bietet viele hilfreiche Einsichten in die Anwendung und ihre zugehörigen Pakete.

Optimierungs- und Fehlerbestimmungsvorteile

pureQuery Runtime erfasst erfolgreich ausgeführte SQL-Anweisungen und zugehörige Informationen wie SQL-Parameter- und Ergebnisinformationen. Sie können die von pureQuery Runtime erfassten SQL-Anweisungen optimieren und mit den von pureQuery Runtime erfassten Informationen die Fehlerquelle ermitteln.

Dies bietet u. a. die folgenden Vorteile:
Typparameter und Ergebnismetadaten für erfasste SQL-Anweisungen
Wird eine SQL-Anweisung dynamisch ausgeführt, wird sie vom JDBC-Treiber vorbereitet und beschrieben. Diese Aktionen stellen die Gültigkeit der SQL-Anweisungssyntax und -semantik sicher. Für die Parameter und Ergebnisspalten werden anhand der Zieldatenbankspalten der Typ, die Länge, die ID des codierten Zeichensatzes und andere Attribute geprüft. Bei statischer SQL-Ausführung wird der Typ nur einmal während der Programmerstellung geprüft und nicht während der Ausführung wie bei dynamischer SQL-Ausführung.

Während des Erfassungsprozesses fängt pureQuery Runtime die Aufrufe des JDBC-Treibers ab und erfasst die Informationen. Die SQL-Anweisung wird nur erfasst, wenn sie erfolgreich ausgeführt wird.

Das Erstellen von Paketen aus den von pureQuery erfassten SQL-Anweisungen und das Binden der Pakete für die Datenbank kann glatt ablaufen, weil die SQL-Anweisungen erfolgreich für die Datenbank ausgeführt wurden. Zudem kann der Bindeprozess mithilfe der Typinformationen die entsprechenden Indizes für die Zugriffspfade auswählen.

Abrechnungs- und Momentaufnahmeinformationen auf Paketebene bei statischer Ausführung von SQL-Anweisungen
Abrechnungsinformationen auf Paketebene sind für DB2 für Linux®, UNIX® und Windows® sowieDB2 für z/OS verfügbar. In DB2 für Linux, UNIX und Windows befinden sich Informationen in der Paketmomentaufnahme und in DB2 für z/OS befinden sich die Informationen in einem Abrechnungsbericht.

Mit Leistungsinformationen auf Paketebene können Datenbankadministratoren die problematischen Abschnitte einer Anwendung ohne Traces auf Anwendungsebene ermitteln. Leistungsinformationen auf Paketebene können auch dazu beitragen, die am häufigsten ausgeführten und die für eine detaillierte Optimierungsanalyse in Frage kommenden Codeabschnitte zu ermitteln. In einer dynamischen Umgebung kann es schwierig sein, die Codeabschnitte zu ermitteln, ohne integrierte benutzerspezifische Traces in der Anwendung zu definieren.

pureQuery Runtime erfasst auch Stack-Traces aus der Anwendung. Der Datenbankadministrator kann die Stack-Traces verwenden und mit dem Entwickler zusammenarbeiten, um die Fehlerquelle zu diagnostizieren.

SQL-Anweisungsabruf
Datenbankadministratoren können mehrere Ansätze verwenden, um einzelne SQL-Anweisungen für weitere Optimierung abzurufen. Sollen SQL-Anweisungen in einer Anwendung erfasst werden, die SQL dynamisch ausführt, muss ein SQL-Trace aktiviert sein, müssen die in einem Cache enthaltenen Informationen abgerufen werden oder muss die SQL-Anweisung mit DB2 EXPLAIN verwendet und dynamisch ausgeführt werden. Im Gegensatz hierzu sind statische SQL-Anweisungen vordefiniert und können Informationen zu den Anweisungen einfach abgerufen werden. SQL-Anweisungen werden erfasst und in den DB2-Katalogtabellen aufbewahrt. Ihre Zugriffspläne können im Voraus in den DB2 EXPLAIN-Tabellen erfasst werden. Das Abfragen der Katalog- und EXPLAIN-Tabellen kann die betreffende SQL-Anweisung und den zugehörigen Zugriffsplan abrufen.
DB2 EXPLAIN

Sie können die Leistungsmerkmale einer SQL-Anweisung mithilfe von Visual Explain während der Entwicklung in Optim Development Studio oder mithilfe der Bindeoption EXPLAIN YES während der Ausführung des pureQuery-Dienstprogramms StaticBinder zusammenstellen.

Mit der Bindeoption EXPLAIN YES kann ein Datenbankadministrator die vom DB2-Optimierungsprogramm getroffenen Zugriffspfadentscheidungen überprüfen. Administratoren können ermitteln, welche Statistikdaten erfasst werden sollen, um die Zugriffspfadauswahl zu verbessern. Andere Tools können auch dazu beitragen, SQL-Anweisungen in EXPLAIN-Tabellen zu analysieren, und basierend auf ihrem Inhalt Optimierungsempfehlungen ausgeben. Die Zugriffsplananalyse und -optimierung wird während der Programmerstellung ausgeführt und ein vordefinierter Zugriffsplan kann in das Paket aufgenommen werden, das für die statisch auszuführenden SQL-Anweisungen erstellt wird. Wenn Sie SQL dynamisch ausführen, können Zugriffspläne nicht vordefiniert sein.

DB2-Fehlernachrichten
Wenn Sie eine DB2-Datenbank verwenden, enthalten Fehlernachrichten wie die Überschreitung der Sperrzeit, Deadlocks und Fehler aufgrund nicht verfügbarer Ressourcen bei statischer SQL-Ausführung häufig einen Paketnamen. Ein Datenbankadministrator kann mithilfe der Paketinformationen die SQL-Anweisung ermitteln, die den Fehler verursacht oder vom Fehler betroffen ist, indem er den Fehler mit dem Anwendungsmodul verbindet.

Fehlernachrichten von DB2 für z/OS enthalten Informationen zum ausgeführten Paket. Diese Fehlernachrichten enthalten Informationen zur Position, zum Paketnamen und zum Konsistenztoken. Mit diesen Informationen kann die Anwendungsquelle schnell ermittelt werden. Eine ähnliche Fehlernachricht, die bei der dynamischen Ausführung einer SQL-Anweisung generiert wird, liefert keine Informationen zu der Anwendung, die dieses SQL ausgegeben hat. Alle SQL-Anweisungen durchlaufen dieselben JDBC-Pakete.

Bei DB2 für Linux, UNIX und Windows können Tools wie der Ereignismonitor db2deadlock bei Verwendung mit statischen SQL-Anweisungen den Paketnamen und Abschnittsnummerinformationen für das Deadlock-Ereignis zusätzlich zu den am Deadlock beteiligten Sperrenressourcen bereitstellen. Diese Informationen können mit dem DB2-Tool db2evmon angezeigt werden.

Anwendungs-Stack-Traces
Wenn Sie Zugriff auf den Java-Code für die Anwendung haben, können Sie die von pureQuery Runtime erfassten Stack-Trace-Informationen verwenden, um eine SQL-Anweisung einer Position im Java-Quellcode zuordnen. pureQuery Runtime speichert die Stack-Trace-Informationen mit der SQL-Anweisung in der pureQueryXML-Datei. In Optim Development Studio können Sie mit den Stack-Trace-Informationen den Java-Code suchen, der die Anweisung ausgegeben hat.

Operative Vorteile

Wenn eine für die pureQuery-Clientoptimierung aktivierte Anwendung SQL-Anweisungen statisch ausführt, werden die SQL-Anweisungen der Datenbank vor der Programmausführung bereitgestellt. Bei der Ermittlung der SQL-Anweisungen können Datenbankadministratoren alle verfügbaren Optimierungstools nutzen, ohne dass ein Online-Trace erforderlich ist.

Einige operative Vorteile lauten wie folgt:
Sicherheitsmodell bei der statischen Ausführung von SQL-Anweisungen
Im Modell für statische SQL-Ausführung braucht die während der Ausführung verwendete Berechtigungs-ID keinen Zugriff auf Basisdatenbankobjekte zu haben. Der Berechtigungs-ID für Laufzeit wird Zugriff auf ein bestimmtes vordefiniertes Paket und die eingeschlossenen SQL-Anweisungen anstatt Zugriff auf Basisdatenbankobjekte wie in einer dynamischen JDBC-Implementierung gegeben.

Die Berechtigung eines Pakets ermöglicht eine verbesserte Sicherheitsimplementierung, weil Berechtigungs-IDs die SQL-Anweisungen nicht mit Programmierungslogik ändern können. Wenn die ID zudem gewöhnlich eine Verbindung von einem alternativen Zugriffsmechanismus herstellt, kann die ID das SQL aufgrund eines Sicherheitsverstoßes nicht dynamisch ausführen. Die Berechtigung eines Pakets ermöglicht außerdem eine strikte Protokollierung aller SQL-Anweisungen, die für eine Tabellengruppe ausgeführt werden.

Im statischen Modell bindet ein Benutzer, der über die Berechtigung zum Zugreifen auf die Basistabelle verfügt, die Pakete und wird der Paketeigner. Der Paketeigner kann dann die Fähigkeit, das Paket auszuführen, einer Berechtigungs-ID in der Laufzeitumgebung erteilen, beispielsweise der in der WebSphere Application Server-Datenquellendefinition gespeicherten Benutzer-ID. Die WebSphere-Benutzer-ID kann kein anderes SQL dynamisch für die Datenbankobjekte außerhalb der SQL-Anweisungen ausführen, die im Paket definiert sind.

Im Gegensatz hierzu wird eine Benutzer-ID in einer dynamischen SQL-Umgebung für den gesamten Datenzugriff stellvertretend für die Benutzer verwendet, die mit dem Anwendungsserver verbunden sind. Diese Benutzer-ID kann SQL dynamisch für die Datenbank außerhalb der Anwendungsserverumgebung ausführen.

SQL-Literalersetzung
pureQuery Runtime hat eine SQL-Literalersetzungsfunktion, die nicht parametrisierte SQL-Anweisungen, die die Anwendung ausführt, in parametrisierte SQL-Anweisungen konvertieren kann. Diese Funktion ist für Anwendungen nützlich, die SQL-Anweisungen während der Ausführung generieren. Zudem senkt SQL-Literalersetzung bei dynamisch ausgeführten SQL-Anweisungen die Gesamtzahl SQL-Anweisungen im dynamischen Server-Cache, was die Cachetrefferquote für Anweisungen erhöht.
Fähigkeit, nur erfasstes SQL auszuführen
Die pureQuery-Clientoptimierung hat die Fähigkeit, nur erfasste SQL-Anweisungen auszuführen. Diese Fähigkeit beschränkt die Anweisungen, die eine Anwendung ausführen kann, auf jene, die der Datenbankadministrator genehmigt hat und die sich in der pureQueryXML-Datei befinden, selbst wenn die SQL-Anweisungen dynamisch ausgeführt werden. Die Ausführung von nur erfasstem SQL verbessert die Sicherheit aller Anwendungen. Diese Fähigkeit ist in Umgebungen nützlich, die statisches SQL nicht unterstützen. Diese Fähigkeit kann zur Vermeidung von SQL-Injection-Attacken beitragen.

Die pureQuery-Clientoptimierung kann auch die Ausführung von SQL-Anweisungen auf Anweisungen begrenzen, die statisch ausgeführt werden können.

SQL-Anweisungsersetzung
Die Verwendung der pureQuery-Clientoptimierung für eine vorhandene JDBC-Anwendung vereinfacht die Ersetzung von ausgeführtem SQL durch ein optimiertes äquivalentes SQL. Ein Datenbankadministrator kann eine eine leistungsschwache SQL-Anweisung durch eine optimierte SQL-Anweisung ersetzen, ohne die Anwendung zu modifizieren.

Die ersetzte SQL-Anweisung kann Änderungen wie zusätzliche WHERE-Klauseln für bessere Indexselektivität enthalten. Die ersetzte SQL-Anweisung kann keine Parameter oder Ergebnisspalten hinzufügen, weil die Metadaten bereits erfasst wurden.

Leistungsvorteile

Abgesehen von den operativen, Optimierungs- und Entwicklungsvorteilen kann statische SQL-Ausführung die Leistung verbessern.

Einige Leistungsoptimierungsvorteile lauten wie folgt:
Ausschluss von PREPARE- und DESCRIBE-Laufzeitanweisungen

Bei statischer SQL-Ausführung findet die einmalige Anweisungsvorbereitung vor der Ausführung der Anweisung in der Laufzeitumgebung statt. Daher werden die PREPARE- und DESCRIBE-Aktivitäten für die SQL-Anweisung in jeder Transaktion nicht wiederholt, wie dies bei dynamischer SQL-Ausführung der Fall ist. Statische SQL-Ausführung führt zu einer Senkung der CPU-Belegung auf dem Datenbankserver, auf dem die Vorbereitung stattfindet, und auf dem Anwendungsserver, auf dem ein PreparedStatement-Objekt erstellt wird.

In einer JDBC-Umgebung können Sie versuchen, diesen Aufwand für vorbereitete Anweisungen zu reduzieren, indem Sie die SQL-Cachetreffer verbessern. Die Caching-Implementierungen garantieren jedoch keine hundertprozentige Trefferquote.

Reduzierter Datenfluss im Netz
Da nicht jede SQL-Anweisung vorbereitet werden muss, ist für die einzelnen Anweisungen auch keine PREPARE- und DESCRIBE-Aktivität im Netz erforderlich. Daher sind der Datenaustausch im Netz und die abgelaufene Transaktionszeit reduziert.
Vorhersehbare Zugriffspfadauswahl
Zugriffspläne für SQL-Anweisungen werden im Voraus und nicht während der Ausführung erstellt. Zugriffspfade werden als Ergebnis eines aktiven Dienstprogramms RUNSTATS oder aufgrund von Änderungen in der Datenverteilung nicht geändert. Eine getestete Anwendung kann dieselbe SQL-Anweisung wiederholt ausführen und die ausgewählten Zugriffspfade ändern sich aufgrund von Datenvariationen oder Datenbankpflege nicht.

Feedback