Oracle Hibernate - Oracle-VarChar-Index wird nicht genutzt

[Polli86]

Hallo zusammen,

ich bin langsam am vereifeln...

Ich habe ein Problem mit einem dynamischen Sql von Hibernate.
Ich nutze die Query-Klasse von Hibernate um mir ein solches
zusammenbauen zu lassen.

// zusammenbauen des queryStr
// ...
// Query-Object aus Session erstellen

Query query = session.createQuery(queryStr.toString());

// if (filter instanceof String) {
//query.setParameter("j_filter", "'" + filter + "'");
//} else {                
       query.setParameter("j_filter", filter);
//}
// Query absetzen und Ergebnis empfangen
List<Entity> dataSets = query.list();

der Filter, der dem Query als Parameter mitgegeben wird ist ein String.
Auf der Datenbankseite von Oracle sitzt auf diesem Attribut
ein Index (VarchChar(15)-Feld)

dieses Query dauert ab "query.list()" ganze 2 Minuten

Setze ich die auskommentierten Teile (if-else) aktiv,
dauerts nur 2 Sekunden...
---ABER dann bekomme ich bei weiterern/erneuten Ausführungen Caching-Probleme im JBoss

Hat jemand Tipps/Erfahrungen mit Hibernate und Index-Use auf Datenbankebene ?
Ich bin für jeden Hinweis dankbar.

MfG
Polli

 

[schalentier]

Kommst du irgendwie an das tatsaechlich generierte SQL ran? Am besten einmal mit und einmal ohne das auskommentiere Zeug - da muesste ja ein Unterschied sein, wenn es solche krass verschiedenen Ausfuehrzeiten gibt.

query.list() ist generell nicht unbedingt empfehlenswert (haengt aber stark von der Query und vor allem der Anzahl der Ergebnisse ab). Besser ist dort, mit nem Iterator zu arbeiten.

 

[Polli86]

jo die erste Variante habe ich als select,
bin noch gar nicht auf die idee gekommen mir das zweite
mit Hochkomma anzuschauen 😉

Dauert aber noch ein paar Monmente bis ich das zweite rausgepflückt habe ^^

Hier das Original, ohne Hochkomma
-- asou, als Hinweis... die Spalte AFL032_29_BTNR15 ist der "filter" Parameter

SELECT DISTINCT gesetzteve0_.AFL001_00_ID AS AFL1_50_,
  gesetzteve0_.AFL001_07_INDEX            AS AFL2_50_,
  gesetzteve0_.AFL001_14_VERSION          AS AFL3_50_,
  gesetzteve0_.AFL001_17_BTNR15           AS AFL4_50_,
  gesetzteve0_.AFL001_05_FLST_SATZNR      AS AFL5_50_,
  gesetzteve0_.AFL001_04_SCHLAG_SATZNR    AS AFL6_50_,
  gesetzteve0_.AFL001_12_SYS_VON          AS AFL7_50_,
  gesetzteve0_.AFL001_10_BEARBEITER       AS AFL8_50_,
  gesetzteve0_.AFL001_13_SYS_BIS          AS AFL9_50_,
  gesetzteve0_.AFL001_15_GUELTIG_VON      AS AFL10_50_,
  gesetzteve0_.AFL001_16_GUELTIG_BIS      AS AFL11_50_,
  gesetzteve0_.AFL001_01_VERMERK_ID       AS AFL12_50_,
  gesetzteve0_.AFL001_09_SYS_BIS_SATZART  AS AFL13_50_,
  gesetzteve0_.AFL001_11_H_BEARBEITER     AS AFL14_50_,
  gesetzteve0_.AFL001_06_FELDTYP          AS AFL15_50_,
  gesetzteve0_.AFL001_08_LFD              AS AFL16_50_
FROM LBD.AFL001_GESETZTEVERM_DA_TB gesetzteve0_,
  LBD.AFL032_ANTFL2ANTRAG_DA_TB antfl2antr1_,
  LBD.AFL032_ANTFL2ANTRAG_DA_TB antfl2antr2_
WHERE antfl2antr2_.AFL032_29_BTNR15     = ?
AND antfl2antr2_.AFL032_05_FLURSTUECK   =antfl2antr1_.AFL032_05_FLURSTUECK
AND antfl2antr1_.AFL032_02_SCHLAG_SATZNR=gesetzteve0_.AFL001_04_SCHLAG_SATZNR
AND gesetzteve0_.AFL001_12_SYS_VON     <=?
AND gesetzteve0_.AFL001_13_SYS_BIS      >?
AND gesetzteve0_.AFL001_15_GUELTIG_VON <=?
AND gesetzteve0_.AFL001_16_GUELTIG_BIS >=?
AND antfl2antr1_.AFL032_22_SYS_VON     <=?
AND antfl2antr1_.AFL032_23_SYS_BIS      >?
AND antfl2antr1_.AFL032_03_JAHR         =?
AND antfl2antr2_.AFL032_22_SYS_VON     <=?
AND antfl2antr2_.AFL032_23_SYS_BIS      >?
AND antfl2antr2_.AFL032_03_JAHR         =?;

* Ok nach dem ich jetzt das mit Hockkomma habe laufen lassen,
war es im 1stelligen Sekundenbereich und das select sieht 100% gleich aus :/

 

[Polli86]

Soooo... nach langem hin und her
und Debug an und Debug aus,
habe ich nun das Rätsel um die schnellen Hochkommas gelöst.

Und zwar waren die Ergebnisse einfach leer,
im Gegensatz zu dem anderen select ohne hochkomma.

Bringt mich zwar nicht immens weiter, da das andere select immernoch
locker 2Minuten rumrattert *heul*

Jemand vielleicht noch nen Tip?