DB2 geeft geen resultaat terug

[Verwijderd]

wie kan ons helpen met een timeoutprobleem in DB2 ?

er wordt een Query gestart vanuit een webapplicatie
de database is DB2 op z/OS
de tabel bevat 100 miljoen records
De SELECT ziet er als volgt uit

SQL:

SELECT * FROM TABEL1 T1, TABEL2 T2 
WHERE T1.zoeksleutel LIKE '123456789%'
and T1.veld1 = T2.veld1
order by T1.veld3 asc,
             T2.veld4 desc

via een monitor in DB2 kun je zien dat de query pages blijft benaderen terwijl de web-applicatie allang een time-out heeft gegeven.

Als de query buiten de applicatie om op het mainframe wordt uitgevoerd komt er binnen 1 seconde resultaat terug.
Het lijkt er op dat op RUNTIME een ander toegangspad bepaald wordt.


Groeten,
Marco Sajtos
Hans van Nieuwenhuijzen

[ Voor 1% gewijzigd door een moderator op 04-06-2007 18:31 . Reden: Code tags toegevoegd ]

[RobIII]

Wat is er mis met je vorige topic? Wil je dat ik dit topic merge met het vorige (gezien je hier (nieuwe?) informatie verschaft)?

Daarnaast: Wij tweakers doen elkaar permanent de groeten

Verder ben ik niet (al te) bekend met DB2, maar kun je die join niet beter anders schrijven?

En tot slot nog wat leesvoer: code tags

[ Voor 46% gewijzigd door RobIII op 04-06-2007 18:55 ]

[whoami]

Als die query snel gaat 'buiten' je webapp, dan zijn het misschien de componenten die de DB access verzorgen (de drivers die je gebruikt om met je DB te connecten) waar de bottleneck zit?
Aangezien je 'binnen de seconde' (over welke tijd spreken we dan) je resultaten terugkrijgt, veronderstel ik dat je wel de nodige indexen gedefinieerd hebt.

In wat is de applicatie geschreven ?

[CubicQ]

De SQL client die ik heb gebruikt op z/os (ik ben de naam kwijt), limiteerde het resultaat automatisch tot 250 records. 't is natuurlijk een flauw iets, maar ik noem het toch maar even.

Hebben jullie al eens gekeken naar het explain plan?

[Verwijderd]

whoami schreef op maandag 04 juni 2007 @ 20:34:
Als die query snel gaat 'buiten' je webapp, dan zijn het misschien de componenten die de DB access verzorgen (de drivers die je gebruikt om met je DB te connecten) waar de bottleneck zit?
Aangezien je 'binnen de seconde' (over welke tijd spreken we dan) je resultaten terugkrijgt, veronderstel ik dat je wel de nodige indexen gedefinieerd hebt.

In wat is de applicatie geschreven ?

de applicatie is geschreven met JAVA Websphere
de drivers zijn gecontroleerd en goed bevonden
inderdaad er zijn indexen gedefinieerd, gezien het aantal records
ook het toegangspad is gechecked en ziet er goed uit

[Verwijderd]

we verwachten max 10 records terug dus van die limit verwacht ik niet zo veel
de explain geeft een positief antwoord , alles is OK

[rachez]

Heb zelf vroeger met deze materie gewerkt vanuit een beheerperspectief, dus bij deze uit interesse:

Het klinkt alsof jullie vanuit het mainframe de tabel via een matching index scan benaderen, maar vanuit de webapp niet.

Hoe connecten jullie trouwens naar het mainframe: DB2 connect of een andere tool?
Wat is de result van het explain report?
Draaien jullie de explain vanuit DB2 connect of op het mainframe?

[Verwijderd]

rachez schreef op dinsdag 05 juni 2007 @ 21:33:
Heb zelf vroeger met deze materie gewerkt vanuit een beheerperspectief, dus bij deze uit interesse:

Het klinkt alsof jullie vanuit het mainframe de tabel via een matching index scan benaderen, maar vanuit de webapp niet.

Hoe connecten jullie trouwens naar het mainframe: DB2 connect of een andere tool?
Wat is de result van het explain report?
Draaien jullie de explain vanuit DB2 connect of op het mainframe?

De applicatie maakt connectie met DB2. DB2 draait op het Mainframe.
De explain geeft een goed resultaat, nix bijzonders.
De explain wordt op het mainframe uitgevoerd.

[rachez]

Het volgende hebben wij eens bij de hand gehad. Zou je dus eens kunnen controleren.
Het ging erom dat de kolommen in java anders gedefinieerd stonden, dan de tabel op het mainframe:

De tabel KA_KART heeft een index op rekeningnummer en pasvolgnummer.
De kolommen rekeningnummer en pasvolgnummer zijn respectievelijk gedefinieerd als char(10) en small integer.
In java staat het als varchar en integer (andere datatypes). DB2 kan daardoor geen gebruik maken van de index en gaat een tablespace scan uitvoeren.
Deze definities staan in de zgn "ser" files (vergelijk het met het DBRM bij cobol programma's)

[Verwijderd]

we hebben de datatypes vergeleken en dat ziet er volgens de boeken goed uit.
DB2 : CHAR(19), CHAR(6), CHAR(3), DATE(10), INTEGER(10)
JAVA : String, String, String, Date, Integer
daar lijkt het dus niet aan te liggen :-)
zou je nog een andere reden kunnen bedenken waarom de index niet gebruikt wordt ?

[rachez]

Heb je al eens de packages die je webapplicatie gebruikt opnieuw gebind? Gebruik bij die rebind eens de optie reopt(vars), hij gaat dan zijn toegangspad bepalen als de query vanuit de webapp wordt uitgevoerd.

[ Voor 19% gewijzigd door rachez op 09-06-2007 01:54 ]

[Verwijderd]

rachez schreef op vrijdag 08 juni 2007 @ 19:15:
Heb je al eens de packages die je webapplicatie gebruikt opnieuw gebind? Gebruik bij die rebind eens de optie reopt(vars), hij gaat dan zijn toegangspad bepalen als de query vanuit de webapp wordt uitgevoerd.

nou, dat willen we nu juist niet, dat het toegangspad runtime bepaald wordt.

[rachez]

Begrijp ik, het gaat er alleen om te kijken of het op een eerder tijdstip bepaalde toegangspad wel juist is. Dan kan je vanuit die optiek verder troubleshooten.
Het lijkt erop dat hij nu een tablespacescan uitvoert. Succes in ieder geval! Laat even weten waar het aan lag.

[Verwijderd]

We zien in de DB2 trace nu een mismatch opduiken :
11:45:20.510571 65 SQL Start: Open Cursor ** mismatched record
11:45:20.510585 95 Sort Execution ** mismatched record
11:45:20.510682 15 Index Scan Start ** mismatched record

we vermoeden dat de STRING vanuit JAVA mismatched met de CHAR(19) in DB2
de default van JAVA zou gebruikt worden : CHAR(254) en dit is groter dan CHAR(19) --> mismatch
dit treedt alleen op als (1) de customize niet op de client is uitgevoerd en geldt alleen als (2) geen EQUALS gebruikt wordt.
(1) verklaart waarom het alleen in produktie omgeving optreed en niet in de test-omgeving
(2) verklaart waarom het alleen optreedt bij SELECT where var1 LIKE '123456789%' en niet bij SELECT where var1 = '1234567890123456789'

[ Voor 72% gewijzigd door Verwijderd op 18-06-2007 16:42 ]

[Verwijderd]

dit was inderdaad het probleem !
ipv LIKE gebruiken we nu SELECT where var1 >= keyMin and var1 <= keyMax