| Autor |
Beitrag |
alzaimar
 
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Mi 21.12.05 11:22
Wir haben hier einen hübschen Reportgenerator, der per TCP-Library an einem MSSQL-Server 2000 hängt.
Bei einer sehr komplexen Abfrage, die nun mal lange dauert, kommt es zu einem Timeout. Kann man den nicht irgendwo hochsetzen? Da wir den Reportgenerator handgebissen haben, kommen wir auch an sämtliche ADO-connectionstrings ran. Das wär also nicht das Problem...
Ich hab total ein Brett vor dem Kopf...
Danke schonmal
(crossposting in der DP, weil es etwas dringend ist)
_________________ Na denn, dann. Bis dann, denn.
|
|
OlliWausD
Beiträge: 212
Win 2000/XP
Delphi 5 Professional - Interbase/Firebird
|
Verfasst: Mi 21.12.05 14:13
entschulde, wenn ich frage, aber:
wenn die Abfrage sowieso elends lang dauert, ist es doch eher besser, dass sql-Statement zu ändern, als den Kunden "Warten zu lassen" (Timerout) bis alles fertig wird.
ich würde dir empfehlen, deinen SQL-Code auf, gegebenenfalls mehrere, SP's umzulagern.
Selbst in Statistikauswertungen über mehrere Tabellen mit Gruppierung und ca 500000 DS sind Zeiten von <10 sec drin, wenn man seine Statements nacheinander schön aufbaut.
wenn du hilfe brauchst, meld dich.
mfg
OlliW
_________________ Take it easy
|
|
alzaimar 
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Mi 21.12.05 14:46
Es sind ca. 4.000.000 Datensätze die nur 1x pro Jahr kummuliert werden.
Im täglichen Betrieb (Tags/Monatsauswertung maximal) sind die Antwortzeiten <1sec bis max 10 sec (was auch schon lang ist), aber wenn die eben mal ein Jahr auswerten wollen ...
Der Report ist ca. 8 Jahre alt, ich werde ihn vielleicht doch mal überdenken:
  SQL-Anweisung
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
| Create PROCEDURE IDENT_RPT_Shrinkage
@FromDate DateTime,
@ToDate DateTime
AS
select Dp.Dept as Kosten,
wn,
NWN = COUNT(DISTINCT w.wnkeyid),
"KALK" = MAX(w.mvkalk),
"PLAN" = MAX(w.mvplan),
"M1000" = MAX(case when w.einsatzstueck=0 then 0 else convert(float,w.einsatzmeter)*1000/w.einsatzstueck end),
"VPM" = MIN(convert(INT,w.vpm)),
"EM" = sum(POEINSATZMETER),
"ES" = sum(Cast (1.0*poeinsatzmeter*w.einsatzstueck/w.einsatzmeter as int)),
"PM1" = sum (case when ertype = 5 and popm = 1 AND w.vPM = 1 THEN poliefermenge else 0 end),
"PM2" = sum (case when ertype = 5 and popm = 2 AND w.vPM = 1 then poliefermenge else 0 end),
"PM3" = sum (case when ertype = 5 and popm = 3 AND w.vPM = 1 then poliefermenge else 0 end),
"LO" = sum (case when popm is null and e.ertype = 4 and w.einsatzmeter > 0 then
poeinsatzmeter*w.einsatzstueck/w.einsatzmeter else 0 end),
"LF" = sum(case when ertype = 5 then COALESCE (poliefermenge,0) else 0 end),
"BR" = sum(case when ertype = 5 then COALESCE (poausschuss,0) else 0 end),
"POSTEN" = COUNT (*),
"FKZ" = max (w.fkz)
from ereignis e
join posten p on (e.pokeyid = p.pokeyid)
join wnlookup w on p.wnkeyid = w.wnkeyid
join IDEDepartments Dp On w.DeptID = Dp.DeptID
where e.ertimedate between @Fromdate and @ToDate and (ertype = 5 or (erType = 4 and e.fokeyid<>1))
group by Dp.Dept, wn
order by 1 |
Indiziert ist auch alles mit clustered indexen, wo's past. _________________ Na denn, dann. Bis dann, denn.
|
|
OlliWausD
Beiträge: 212
Win 2000/XP
Delphi 5 Professional - Interbase/Firebird
|
Verfasst: Mi 21.12.05 15:50
woar, ok. Das die SP lang dauert kann ich mir vorstellen 
OK gehn wir mal an die sache ran
- Was steht in den einzelnen Tabellen und was soll am ende raus kommen.
- Für was stehen die Typen, und wie ist der Zusammenhang der Berechnungen für die Einsatzmeter/Stück
- Was für logischer Wert steht hinter den Feldern, welche du Summierst
Ich muss erst den Sinn und den logischen Ablauf verstehen, bevor wir hier ans Konzeptionieren gehn 
Was sehr schön wäre, wenn du ein paar DS der Einzelnen Tabellen zur Veranschaulichung mit rein postest. Dann sieht man zusammenhang und Zielsetzung besser
mfg
OlliW _________________ Take it easy
|
|
alzaimar
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Mi 21.12.05 16:05
Prinzipiell geht es um Lieferergebnisse einer Produktionsstätte.
Stell Dir vor, es geht um z.B. Nägel. Die werden aus Draht gefertigt. Pro Spule sind, sagen wir ca. 200m Draht drauf und daraus werden nun Nägel gemacht.
Nageltyp #1 (wnkeyid) benötigt für (wnlookup.einsatzStück) 1000 Stk 200m (wnlookup.Einsatzmeter) von dem Draht.
Auf der konkreten Spule (ID = pokeyid) waren (posten.poEinsatzmeter) 250m drauf.
Also ergäbe das theoretisch 1000*250/200 Stück, hier also 1250 Stk.
Am Ende kommen aber nur 1200 Stück raus, der Rest ist eben 'Shrinkage'.
Die Größenordnungen sind nun mittlerweile auch so, das man unbedingt in Floats umrechnen muss, weil man sonst einen Int32 überlauf bekommt.
Das die Angabe 'Einsatzmeter' suboptimal ist, weiss ich, aber 'never change a running system'.
Nageltyp #2 ist viel kleiner, also benötigt er dünneren Draht. Auf eine Standardspule passt viel mehr, sagen wir 1000m. Da der Nagel kurz ist, bekommen wir aus 1000m normalerweise 20000 Stück.
Die Qualitätskontrolle der Nägel geschieht auf diverse Art und Weise (PM1..PM3), man kann alle manuell prüfen, oder Stichproben machen, oder sie sogar durch eine Nagelprüfmaschine jagen.
In der Tabelle 'Ereignis' stehen nun alle 'Ereignisse' drin, die einer Spule denn so zustoßen, wenn Sie durch die Fertigung läuft. Ein 'Ereignis' ist das Abliefern (ertype = 5) oder aber, der Posten war nicht mehr zu gebrauchen (erType=4). Beides ist für die Mehrverbrauchsanalyse wichtig.
_________________ Na denn, dann. Bis dann, denn.
|
|
OlliWausD
Beiträge: 212
Win 2000/XP
Delphi 5 Professional - Interbase/Firebird
|
Verfasst: Mi 21.12.05 16:38
also auf deutsch:
du hast in:
der Tabelle Posten deine Artikel
der Tabelle wnlookup deine anzahlStück mit benötigter menge Draht. Quasi eine 1-1 verknüpfung zu Posten
der Tabelle IDEDepartments deine Preise mit 1-1 (oder 1-n?) auf Tabelle Posten
und in ereignisse deinen Fertigungsaufträge/Qualitätsprüfungen(korrekt und fehlerhaft) welche diesen Nagel enthalten.
richtig??
Das Ergebnis der Liste ist dann also eine auflistung aller artikel mit der Anzahl der Fertigungsaufträge, Qualitätsprüfungen, Anzahl der gefertigten Stück, benutzter Draht, ...
kommen wir dann mal auf die Anzahl der DS zurück.
Ausschlaggebend für deine Liste ist ja die Tabelle Ereignisse, welche 4mio DS über 8Jahre enthält, und die anderen 3 Tabellen ja nur "NebenInfos" dastellen.
Damit hätten wir die 1. Eingrenzung, da du ja "nur" 1 Jahr benötigst. Das würde ich zum Beispiel als die Erste SP behandeln, ohne Berechnung, ohne alles. nur die Felder der Tabelle Ereignisse, die du brauchst in die SP.
Danach holst du die per 2. SP die Daten von SP1 und machst deine Joins über die anderen Tabellen. Pack die Berechnung rein, gruppiere aber noch nicht!
und mit schritt nummer3 gruppierst du deine DS in einer stink normalen Query. Müsstest mindestens doppelt so schnell zum Ziel kommen, als mit dem obigen Text
falls das jetzt weng schnell ging, sag bescheid.
mfg
OlliW
_________________ Take it easy
|
|
alzaimar
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Mi 21.12.05 16:59
Nicht ganz:
Posten sind die drahtspulen, die durch die fertigung rauschen (einzelne chargen)
Wnlookup ist die Artikelstammdatentabelle
IDEDepartments sind die KOSTEN-stellen (klar, das man gleich an Preise denkt)
Und es sind 4mio pro Jahr. Das System läuft schon 3 Jahre.
Zu Deinem Vorschlag:
Bei einer Monatsauswertung ist die Aufteilung 20% langsamer, bei der Jahresauswertung 20% (!) schneller. Diese Aufteilung (erst sammeln, dann kummulieren) hatte ich bei einem anderen Report schon mal gemacht, da hat es auch wirklich viel gebracht. Hier dachte ich, das 'Time between a and b' (time ist ein clustered index), würde schon optimal sein, aber na ja: Man lernt nie aus.
Zum Problem des ADO-Timeouts: Das ist eine waschechte MS-Macke. Man muss die Abfrage asynchron absetzen (eine Option im ADODataset), dann gehts, sonst nicht.
Danke für den Hinweis (hab ich natürlich ohne SP gemacht, sondern einfach mit temporären tabellen), manchmal ist man eben einfach blind...
_________________ Na denn, dann. Bis dann, denn.
|
|
OlliWausD
Beiträge: 212
Win 2000/XP
Delphi 5 Professional - Interbase/Firebird
|
Verfasst: Mi 21.12.05 17:14
 alzaimar hat folgendes geschrieben: | | Danke für den Hinweis (hab ich natürlich ohne SP gemacht, sondern einfach mit temporären tabellen), manchmal ist man eben einfach blind... |
ich geb dir trotzdem den Rat, es noch mal mit SP's auszuprobieren. Du wirst sehen, es geht noch mal um einiges schneller
mfg
OlliW _________________ Take it easy
|
|
|
