Hallo,

wir haben zurzeit ein Incident offen. Der Support kommt nach etlichen Tracings/Scans nicht wirklich weiter... Hat jemand evtl. auch Performanceprobleme mit der genannten Session gehabt? Bei uns läuft diese im manuellen Modus zum Teil durch (meistens im zweiten Anlauf). Im Job-Modus jedoch ist die Session dermaßen Langsam, dass Sie selbst nach zehn Stunden nicht fertig wird (früher 1 bis 2 Stunden). Primär betrifft es eine Artikelgruppe, zu der über 100.000 Artikel gehören...

Gruß

pet

Hallo Pet.

Gerade bei solchen Dingen (Session läuf plötzlich langsamer als sonst, Software nicht verändert) würde ich mir mal ansehen, was die Datenbank so zu tun hat. Bei Informix tut hier "onstat -g ses ..." gute Dienste; wenn sich dann herausstellt, dass eine Tabelle besonders lange benötigt, könnte auch mal ein "Update Statistics" bzw. ein "Reorganize Tables" helfen.

Ich habe damit auch schon Abfrage-Sessions, die von einem Satz zum nächsten eine gefühlte Minute gebraucht haben, wieder in den Sekundenbereich gebracht. Und Langzeit-Sessions sind manchmal auch Stunden mgölich.

Gruß Günther

Hallo,

danke für die Antwort. Update Statistics lassen wir regelmäßig laufen und ein Reorg haben wir über die betroffenen Tabellen laufen lassen (beides hat auch der Support empfohlen). Nun sollen wir direkt auf der Informix ebene ein Query ausführen, um sagen zu können, ob es nicht doch an der DB liegt und nicht an der Applikation. Heute hat uns der Support geraten die entsprechenden Tabellen auszudumpen und wieder einzudumpen (wg. Index). Den Query haben wir noch nicht zum laufen bekommen (wir bekommen den Fehler Too many or too few host variables given in dbaccess)...

Gruß

pet

Okay, okay. Aber trotzdem würde ich mal nachsehen, was denn so läuft. Nur so könnt ihr erkennen, welche Abfrage auf welcher Tabelle das Problem ergibt.
=> Also echt mal mit "onstat -g ses ..." (muss evtl. als User Informix laufen) reinsehen.

(Bei LN gibt es ja noch so nette Tracing Tools; ich vermute aber, dass ihr nicht die Terrabytes habt, um über 10 Stunden oder so alles mitzuprotokollieren ...)

Günther

Hallo,

mit dem Befehl bekomen wir folgendes raus:

Current Role : baanr

Current SQL statement :
SELECT a0.t_pacc,a0.t_wday FROM "baan".tttaad100000 a0 WHERE a0.t_comp =
?

Host variables :
address type flags value
-----------------------------------------
0x0000000115adbb70 INT 0x000 500

Last parsed SQL statement :
SELECT a0.t_pacc,a0.t_wday FROM "baan".tttaad100000 a0 WHERE a0.t_comp =
?

Was können wir damit anfangen? Mit anderen Session-IDs (für diesen User) bekommen wir noch diese Ausgaben

Current statement name : c10

Current Role : baanr

Current SQL statement :
SELECT
a0.t_pacc,a0.t_cpac,a0.t_sequ,a1.t_mess,a1.t_expi,a1.t_za_mtyp,a1.t_txtc,a1
.t_zb_mqst FROM "baan".tttadv112000 a0 ,"baan".tttadv450000 a1 WHERE
a1.t_clan = ? AND a1.t_cpac = ? AND a1.t_cmes = ? AND a1.t_vers =
a0.t_vers AND a1.t_rele = a0.t_rele AND a1.t_cust = a0.t_cust AND
a0.t_pacc = ? AND a0.t_cpac = ? ORDER BY 1,2,3

Host variables :
address type flags value
-----------------------------------------
0x000000011b0c7d28 CHAR 0x000 3
0x000000011b0c7db8 CHAR 0x000 ti
0x000000011b0c7e48 CHAR 0x000 cpr99996
0x000000011b0c7ed8 CHAR 0x000 b61a3pro
0x000000011b0c7f68 CHAR 0x000 ti

Last parsed SQL statement :
SELECT
a0.t_pacc,a0.t_cpac,a0.t_sequ,a0.t_vers,a0.t_rele,a0.t_cust,0,a1.t_za_clab,
a1.t_expi FROM "baan".tttadv112000 a0 ,"baan".tttadv330000 a1 WHERE
a1.t_clan = ? AND a1.t_cpac = ? AND a1.t_cmod = ? AND a1.t_crep = ? AND
a1.t_vers = a0.t_vers AND a1.t_rele = a0.t_rele AND a1.t_cust = a0.t_cust
AND a0.t_pacc = ? AND a0.t_cpac = ? ORDER BY 1,2,3

bzw.

Current statement name : c1

Current Role : baanr

Current SQL statement :
SELECT
a0.t_tdep,a0.t_tver_1,a0.t_tver_2,a0.t_tver_3,a0.t_tver_4,a0.t_tver_5,a0.t_
tver_6,a0.t_tver_7,a0.t_tver_8,a0.t_tver_9,a0.t_tver_10,a0.t_tver_11,a0.t_t
ver_12,a0.t_tver_13,a0.t_tver_14,a0.t_tver_15,a0.t_tver_16,a0.t_tver_17,a0.
t_tver_18,a0.t_tver_19,a0.t_tver_20,a0.t_tver_21,a0.t_tver_22,a0.t_tver_23,
a0.t_tver_24,a0.t_tver_25,a0.t_tver_26,a0.t_tver_27,a0.t_tver_28,a0.t_tver_
29,a0.t_tver_30,a0.t_tver_31,a0.t_tver_32,a0.t_tver_33,a0.t_tver_34,a0.t_tv
er_35,a0.t_tver_36,a0.t_tver_37,a0.t_tver_38,a0.t_tver_39,a0.t_tver_40,a0.t
_trel_1,a0.t_trel_2,a0.t_trel_3,a0.t_trel_4,a0.t_trel_5,a0.t_trel_6,a0.t_tr
el_7,a0.t_trel_8,a0.t_trel_9,a0.t_trel_10,a0.t_trel_11,a0.t_trel_12,a0.t_tr
el_13,a0.t_trel_14,a0.t_trel_15,a0.t_trel_16,a0.t_trel_17,a0.t_trel_18,a0.t
_trel_19,a0.t_trel_20,a0.t_trel_21,a0.t_trel_22,a0.t_trel_23,a0.t_trel_24,a
0.t_trel_25,a0.t_trel_26,a0.t_trel_27,a0.t_trel_28,a0.t_trel_29,a0.t_trel_3
0,a0.t_trel_31,a0.t_trel_32,a0.t_trel_33,a0.t_trel_34,a0.t_trel_35,a0.t_tre
l_36,a0.t_trel_37,a0.t_trel_38,a0.t_trel_39,a0.t_trel_40,a0.t_tcus_1,a0.t_t
cus_2,a0.t_tcus_3,a0.t_tcus_4,a0.t_tcus_5,a0.t_tcus_6,a0.t_tcus_7,a0.t_tcus
_8,a0.t_tcus_9,a0.t_tcus_10,a0.t_tcus_11,a0.t_tcus_12,a0.t_tcus_13,a0.t_tcu
s_14,a0.t_tcus_15,a0.t_tcus_16,a0.t_tcus_17,a0.t_tcus_18,a0.t_tcus_19,a0.t_
tcus_20,a0.t_tcus_21,a0.t_tcus_22,a0.t_tcus_23,a0.t_tcus_24,a0.t_tcus_25,a0
.t_tcus_26,a0.t_tcus_27,a0.t_tcus_28,a0.t_tcus_29,a0.t_tcus_30,a0.t_tcus_31
,a0.t_tcus_32,a0.t_tcus_33,a0.t_tcus_34,a0.t_tcus_35,a0.t_tcus_36,a0.t_tcus
_37,a0.t_tcus_38,a0.t_tcus_39,a0.t_tcus_40 FROM "baan".tttadv111000 a0
WHERE a0.t_cpac = ? AND a0.t_vers = ? AND a0.t_rele = ? AND a0.t_cust = ?

Host variables :
address type flags value
-----------------------------------------
0x000000011b4a11c0 CHAR 0x000 da
0x000000011b4a1250 CHAR 0x000 7.6U
0x000000011b4a12e0 CHAR 0x000 a4
0x000000011b4a1370 CHAR 0x000 ta

Last parsed SQL statement :
SELECT
a0.t_tdep,a0.t_tver_1,a0.t_tver_2,a0.t_tver_3,a0.t_tver_4,a0.t_tver_5,a0.t_
tver_6,a0.t_tver_7,a0.t_tver_8,a0.t_tver_9,a0.t_tver_10,a0.t_tver_11,a0.t_t
ver_12,a0.t_tver_13,a0.t_tver_14,a0.t_tver_15,a0.t_tver_16,a0.t_tver_17,a0.
t_tver_18,a0.t_tver_19,a0.t_tver_20,a0.t_tver_21,a0.t_tver_22,a0.t_tver_23,
a0.t_tver_24,a0.t_tver_25,a0.t_tver_26,a0.t_tver_27,a0.t_tver_28,a0.t_tver_
29,a0.t_tver_30,a0.t_tver_31,a0.t_tver_32,a0.t_tver_33,a0.t_tver_34,a0.t_tv
er_35,a0.t_tver_36,a0.t_tver_37,a0.t_tver_38,a0.t_tver_39,a0.t_tver_40,a0.t
_trel_1,a0.t_trel_2,a0.t_trel_3,a0.t_trel_4,a0.t_trel_5,a0.t_trel_6,a0.t_tr
el_7,a0.t_trel_8,a0.t_trel_9,a0.t_trel_10,a0.t_trel_11,a0.t_trel_12,a0.t_tr
el_13,a0.t_trel_14,a0.t_trel_15,a0.t_trel_16,a0.t_trel_17,a0.t_trel_18,a0.t
_trel_19,a0.t_trel_20,a0.t_trel_21,a0.t_trel_22,a0.t_trel_23,a0.t_trel_24,a
0.t_trel_25,a0.t_trel_26,a0.t_trel_27,a0.t_trel_28,a0.t_trel_29,a0.t_trel_3
0,a0.t_trel_31,a0.t_trel_32,a0.t_trel_33,a0.t_trel_34,a0.t_trel_35,a0.t_tre
l_36,a0.t_trel_37,a0.t_trel_38,a0.t_trel_39,a0.t_trel_40,a0.t_tcus_1,a0.t_t
cus_2,a0.t_tcus_3,a0.t_tcus_4,a0.t_tcus_5,a0.t_tcus_6,a0.t_tcus_7,a0.t_tcus
_8,a0.t_tcus_9,a0.t_tcus_10,a0.t_tcus_11,a0.t_tcus_12,a0.t_tcus_13,a0.t_tcu
s_14,a0.t_tcus_15,a0.t_tcus_16,a0.t_tcus_17,a0.t_tcus_18,a0.t_tcus_19,a0.t_
tcus_20,a0.t_tcus_21,a0.t_tcus_22,a0.t_tcus_23,a0.t_tcus_24,a0.t_tcus_25,a0
.t_tcus_26,a0.t_tcus_27,a0.t_tcus_28,a0.t_tcus_29,a0.t_tcus_30,a0.t_tcus_31
,a0.t_tcus_32,a0.t_tcus_33,a0.t_tcus_34,a0.t_tcus_35,a0.t_tcus_36,a0.t_tcus
_37,a0.t_tcus_38,a0.t_tcus_39,a0.t_tcus_40 FROM "baan".tttadv111000 a0
WHERE a0.t_cpac = ? AND a0.t_vers = ? AND a0.t_rele = ? AND a0.t_cust = ?

bzw.

Current statement name : c22

Current Role : baanr

Current SQL statement :
SELECT
a0.t_item,a0.t_spit,a0.t_vpwh,a0.t_acpm,a0.t_acpo,a0.t_acps,a0.t_ccur,a0.t_
ecpr_1,a0.t_ecpr_2,a0.t_ecpr_3,a0.t_emtc_1,a0.t_emtc_2,a0.t_emtc_3,a0.t_eop
c_1,a0.t_eopc_2,a0.t_eopc_3,a0.t_ltcp,a0.t_acpr_1,a0.t_acpr_2,a0.t_acpr_3,a
0.t_amtc_1,a0.t_amtc_2,a0.t_amtc_3,a0.t_aopc_1,a0.t_aopc_2,a0.t_aopc_3,a0.t
_lcda,a0.t_cuid,a0.t_chrt,500,a2.t_cprj,a2.t_kitm,a1.t_cwar,a3.t_dsca FROM
( "baan".tticpr007500 AS a0 LEFT JOIN "baan".ttcibd200500 AS a1 ON
a1.t_item = a0.t_item),( "baan".ttcibd001500 AS a2 LEFT JOIN
"baan".ttcmcs052500 AS a3 ON a3.t_cprj = a2.t_cprj) WHERE (? <> ? OR
a0.t_ltcp = ?) AND (a2.t_kitm = ? OR a2.t_kitm = ? OR a2.t_kitm = ? OR
a2.t_kitm = ? OR a2.t_kitm = ?) AND (a2.t_citg >= ?) AND (a2.t_citg <= ?)
AND (a0.t_item >= ?) AND (a0.t_item <= ?) AND a0.t_item = a2.t_item ORDER
BY 1

Host variables :
address type flags value
-----------------------------------------
0x000000011f0656e8 INT 0x000 2
0x000000011f065778 INT 0x000 1
0x000000011f065808 DTIME 0x000 1970-01-01 00:00:00
0x000000011f065898 INT 0x000 1
0x000000011f065928 INT 0x000 3
0x000000011f0659b8 INT 0x000 2
0x000000011f065a48 INT 0x000 4
0x000000011f065ad8 INT 0x000 5
0x000000011f065b68 CHAR 0x000 020
0x000000011f065bf8 CHAR 0x000 020
0x000000011f065c88 CHAR 0x000
0x000000011f065d18 CHAR 0x000 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

Last parsed SQL statement :
SELECT
a0.t_item,a0.t_spit,a0.t_vpwh,a0.t_acpm,a0.t_acpo,a0.t_acps,a0.t_ccur,a0.t_
ecpr_1,a0.t_ecpr_2,a0.t_ecpr_3,a0.t_emtc_1,a0.t_emtc_2,a0.t_emtc_3,a0.t_eop
c_1,a0.t_eopc_2,a0.t_eopc_3,a0.t_ltcp,a0.t_acpr_1,a0.t_acpr_2,a0.t_acpr_3,a
0.t_amtc_1,a0.t_amtc_2,a0.t_amtc_3,a0.t_aopc_1,a0.t_aopc_2,a0.t_aopc_3,a0.t
_lcda,a0.t_cuid,a0.t_chrt,500,a2.t_cprj,a2.t_kitm,a1.t_cwar,a3.t_dsca FROM
( "baan".tticpr007500 AS a0 LEFT JOIN "baan".ttcibd200500 AS a1 ON
a1.t_item = a0.t_item),( "baan".ttcibd001500 AS a2 LEFT JOIN
"baan".ttcmcs052500 AS a3 ON a3.t_cprj = a2.t_cprj) WHERE (? <> ? OR
a0.t_ltcp = ?) AND (a2.t_kitm = ? OR a2.t_kitm = ? OR a2.t_kitm = ? OR
a2.t_kitm = ? OR a2.t_kitm = ?) AND (a2.t_citg >= ?) AND (a2.t_citg <= ?)
AND (a0.t_item >= ?) AND (a0.t_item <= ?) AND a0.t_item = a2.t_item ORDER
BY 1

bzw.

Current Role : baanr

Last parsed SQL statement :
SELECT a0.t_flang,a0.t_tlang,500 FROM "baan".ttttxt040500 a0 WHERE
a0.t_flang = ?

bzw.

Current Role : baanr

Last parsed SQL statement :
SELECT a0.t_flang,a0.t_tlang,500 FROM "baan".ttttxt040500 a0 WHERE
a0.t_flang = ?

Die Session selbst ist dermaßen langsam, dass nach 30 Minuten noch nicht mal der Progress-Balken erscheint...

Danke/Gruß

pet

Dear peturba,

can you check the program script if it has something like

....._index3 between {:field1.f, :field2.f, :field3.f, :field4.f} and {:field1.t, :field2.t, :field3.t, :field4.t}

improvement:

..._index3 between {:field1.f} and {:field1.t} and
table.field2 between :field2.f and field2.t and
table.field3 between :field3.f and field3.t ...

After an upgrade from oracle 8.1.7 to oracle 10gr2 the old code runs hours instead of minutes (statistic was updated etc). Avoiding more than 1 or 2 fields in the index and extending the where clause the session runs now again in minutes. Data is from hughe tables from the production.

Hope it hepls.

Kozure

Sorry, bin leider erst jetzt wieder online. Das sieht doch gut aus! Jetzt könnt ihr im laufenden System einen Blick auf die Statements werfen; wenn über einen längeren Zeitraum immer dieselbe SQL Abfrage erscheint, lohnt es sich, das Ganze mal näher zu untersuchen. (Es ist normal, dass ein Baan-Anwender mehrere Informix-Sessions hat; hier gilt es, die "richtige" zu finden.)

Aus dem genannten Beispiel kann man dann wohl eine vergleichbare SQL Abfrage zusammensuchen:

SELECT
...
WHERE (2 <> 1 OR a0.t_ltcp = '1970-01-01 ...')
AND (a2.t_kitm = 1 OR a2.t_kitm = 2 OR a2.t_kitm = 3 OR
a2.t_kitm = 4 OR a2.t_kitm = 5)
AND (a2.t_citg >= '') AND (a2.t_citg <= '')
AND (a0.t_item >= '') AND (a0.t_item <= '')
AND a0.t_item = a2.t_item
ORDER BY 1

(Nur als Beispiel gedacht, Syntax Datum muss nicht stimmen...)

Gruß Günther

Hi,

this is a standard session and we would like to avoid customization by any means. Also we dindn't change our DB since we started with LN...

The support told us tu dump out and dump in the tables but we dind't tested it yet (no user should be on the system). I don't really believe that it will solve the problem but who knows, it's Baan ;-)

Regs

pet

Hallo,

also das Aus- und Eindumpen der Tabellen hat nichts gebracht. Immer noch die gleiche, schlechte Performance... Was noch auffiel war ein Query auf die Tabelle tttxt040500. Da es die Tabelle nur in der Firma 0 gibt ist es schon merkwürdig bzw. ergibt keinen Sinn. Wenn man wüsste, ob es was bringt, könnte man die Solution 234032 installieren...

Gruß

pet

Letzte Idee vom Infor-Support ist ein Update auf Informix 10.00.xC6... Angeblich gibt es dort eine neue Funktion "INDEX_SELFJOIN", die das Problem beheben soll. Wir bezweifeln, dass diese aufwändig umzusetzende Idee etwas bringen würde (der Fehler wäre sicherlich schon früher aufgetreten und nicht von einem Tag auf den anderen).

Gruß

pet