Durchführung statischer SQL -Abfragen gegen DB2 ohne reine Quartal

Question

Ich möchte JPA über JDBC für eine neue Anwendung verwenden. Ich verwende streng benannte Abfragen und grundlegende CRUD -Methoden des JPA -Entitätsmanagers, mit denen ich (mit Hilfe von Hibernate oder einer anderen JPA -Implementierung) alle nativen SQL -Abfragen extrahieren kann, die in der Datenbank durchgeführt werden. Mit dieser Liste statischer Abfragen verstehe ich, dass ich ein DB2 -Paket erstellen kann, das alle Ausführungspläne meiner Anfragen enthält.

Meine Frage lautet also: Wird die Ausführung dieser Abfragen über JDBC gegen DB2 diese Ausführungspläne nutzen oder nicht? Ich verstehe, dass das PureQuery -Produkt die Liste der SQL -Bestellungen erfassen kann. Liefert es, immer noch durch JDBC und nicht durch reine Query -spezifische API, mehr? So ein spezifisches DB2 -statischer Bindungsmerkmal? Oder entspricht es JDBC?

Vielen Dank für jede Antwort.

Answer 1

JDBC -Anwendungen führen nur dynamische SQL aus (dh DB2 verwendet keine statischen Pakete).

Es gibt nur zwei Möglichkeiten, statische SQL zu erhalten (wobei die Abfragen in einem Paket in der Datenbank gespeichert werden): Schreiben Sie Ihre Anwendung mit SQLJ (wodurch JPA/Hibernate eliminiert wird) oder verwenden Sie PureQuery (die zwischen JDBC und der Datenbank liegt).

Denken Sie daran, dass DB2 selbst mit dynamischem SQL die Ausführungspläne für Abfragen durchspeichert. Wenn sie also häufig genug ausgeführt werden (dh im Cache bleiben), werden Sie den Overhead nicht aus der Abfragebildung sehen. Der Cache ist nur nützlich, wenn die Abfragen ein genaues Byte-for-byte-Match sind, also select * from t1 where c1 = 1 ist nicht dasselbe wie select * from t1 where c1 = 2, weder noch select * from t1 where C1 = 1 (Was das gleiche Ergebnis ergibt, aber die Abfrage unterscheidet sich). Verwenden von Parametermarkern (select * from t1 where c1 = ?) ist Schlüssel. Ihr DBA kann die Größe des Katalog -Cache einstellen, um das Trefferverhältnis in diesem Cache zu maximieren.

Obwohl das Caching hilft, wiederholt eine Abfrage zusammenzustellen, bietet es nicht die Planstabilität, die statische SQL tut, also ymmv.