Komplexes Statement optimieren

Hallo,

ich stehe momentan vor einem Problem, dass ich ein sehr komplexes
Statement auf einen relativ großen Datenbestand ausführen muss und die
Laufzeit daher übelst lang ist (teilweise mehrere Stunden).

Ausgangssituation: eine Tabelle mit den Spalten

SID | LOGTIME | MESSAGE

Jeweils 4 Datensätze gehören zusammen und haben die gleiche SID.
Je nachdem, was in MESSAGE steht, ist entweder die LOGTIME als START
oder als ENDE oder ein Teilstring von MESSAGE als Vorgang oder Dokument
zu werden.

Was ich im Endeffekt brauche, ist ein Statement, was mir zu jeder SID
die Werte START, ENDE, Laufzeit(Differenz Start und Ende), Vorgang und
Dokument liefert.

Folgendes Statement liefert dies:

----------------------------------------------
select start.SID,
start.logtime as START,
ende.logtime as END,
((hour(ende.logtime)-hour(start.logtime)) * 3600 +
(minute(ende.logtime) - minute(start.logtime)) * 60 +
(second(ende.logtime) - second(start.logtime)) +
((microsecond(ende.logtime) - microsecond(start.logtime)) /
1000) / 1000) as SECONDS,
substring(vorgang.message,6) as VORGANG,
substring(document.message,6) as DOCUMENT
from TABELLENNAME start,
TABELLENNAME ende,
TABELLENNAME vorgang,
TABELLENNAME document
where date_format(start.logtime,'%Y-%m-%d') = ''
and start.sid = ende.sid
and start.sid = vorgang.sid
and start.sid = document.sid
and start.message like '%Archive,%'
and ende.message like '%Archive done%'
and vorgang.message like '1038=%'
and document.message like '1039=%'
----------------------------------------------

Dadurch, dass die Tabelle TABELLENNAME also viermal mit sich selber
verknüpft wird und dabei ca. 90.000 Datensätze hat, läuft die ganze
Chose Ewigkeiten.

Ich habe jetzt als erste Optimierung dafür gesorgt, dass zunächst die
Werte START, ENDE, VORGANG und DOCUMENT in 4 Zwischentabellen
geschrieben werden, welche jeweils auch die Spalte SID haben.

Dadurch verknüpfe ich dann 4 verschiedene Tabellen, welche jeweils gut
20.000 Datensätze haben:

----------------------------------------------
select distinct start.SID, START, END,
((hour(END)-hour(START)) * 3600 +
(minute(END) - minute(START)) * 60 +
(second(END) - second(START)) +
((microsecond(END) - microsecond(START)) / 1000) / 1000) as SECONDS,
VORGANG, DOCUMENT
from ZWISCHENTABELLE_START start,
ZWISCHENTABELLE_END ende,
ZWISCHENTABELLE_VORGANG vorgang,
ZWISCHENTABELLE_DOCUMENT document
where start.SID = ende.SID
and start.SID = vorgang.SID
and start.SID = document.SID
----------------------------------------------

Läuft immer noch grottig langsam, auch wenn ich die Berechnung von
SECONDS rausnehme...

Da ich mich mit den Feinheiten von SQL nicht besonders auskenne und auch
nicht mit Performanceoptimierung bei MySQL (auf die
DB-Servereinstellungen habe ich übrigens keinen Einfluss), wäre ich
dankbar für jeden Tip, wie ich das obige Statement vielleicht noch tunen
kann...

Vielen Dank, viele Grüße und ein frohes Fest,
Jens

Re: Komplexes Statement optimieren

Jens Riedel schrieb:
> Hallo,
>
> ich stehe momentan vor einem Problem, dass ich ein sehr komplexes
> Statement auf einen relativ großen Datenbestand ausführen muss und die
> Laufzeit daher übelst lang ist (teilweise mehrere Stunden).
>
> Ausgangssituation: eine Tabelle mit den Spalten
>
> SID | LOGTIME | MESSAGE
>
> Jeweils 4 Datensätze gehören zusammen und haben die gleiche SID.
> Je nachdem, was in MESSAGE steht, ist entweder die LOGTIME als START
> oder als ENDE oder ein Teilstring von MESSAGE als Vorgang oder Dokument
> zu werden.

sparsames Datenmodell.

Leider verschweigst Du die Ausgabe von SHOW CREATE TABLE - und damit,
auf welchen Feldern es Indizes gibt.

>
> Was ich im Endeffekt brauche, ist ein Statement, was mir zu jeder SID
> die Werte START, ENDE, Laufzeit(Differenz Start und Ende), Vorgang und
> Dokument liefert.
>
> Folgendes Statement liefert dies:
>
> ----------------------------------------------
> select start.SID,
> start.logtime as START,
> ende.logtime as END,
> ((hour(ende.logtime)-hour(start.logtime)) * 3600 +
> (minute(ende.logtime) - minute(start.logtime)) * 60 +
> (second(ende.logtime) - second(start.logtime)) +
> ((microsecond(ende.logtime) - microsecond(start.logtime)) /
> 1000) / 1000) as SECONDS,
> substring(vorgang.message,6) as VORGANG,
> substring(document.message,6) as DOCUMENT
> from TABELLENNAME start,
> TABELLENNAME ende,
> TABELLENNAME vorgang,
> TABELLENNAME document
> where date_format(start.logtime,'%Y-%m-%d') = ''
> and start.sid = ende.sid
> and start.sid = vorgang.sid
> and start.sid = document.sid
> and start.message like '%Archive,%'

Böse. Like mit einem '%' schließt in den meisten MySQL-Versionen die
Benutzung eines Index aus.

> and ende.message like '%Archive done%'
> and vorgang.message like '1038=%'
> and document.message like '1039=%'
> ----------------------------------------------
>
> Dadurch, dass die Tabelle TABELLENNAME also viermal mit sich selber
> verknüpft wird und dabei ca. 90.000 Datensätze hat, läuft die ganze
> Chose Ewigkeiten.
>
> Ich habe jetzt als erste Optimierung dafür gesorgt, dass zunächst die
> Werte START, ENDE, VORGANG und DOCUMENT in 4 Zwischentabellen
> geschrieben werden, welche jeweils auch die Spalte SID haben.
>

Tja, ein vernünftiges Datenmodell könnte ohnehin helfen.

> Dadurch verknüpfe ich dann 4 verschiedene Tabellen, welche jeweils gut
> 20.000 Datensätze haben:
>
> ----------------------------------------------
> select distinct start.SID, START, END,
> ((hour(END)-hour(START)) * 3600 +
> (minute(END) - minute(START)) * 60 +
> (second(END) - second(START)) +
> ((microsecond(END) - microsecond(START)) / 1000) / 1000) as SECONDS,
> VORGANG, DOCUMENT
> from ZWISCHENTABELLE_START start,
> ZWISCHENTABELLE_END ende,
> ZWISCHENTABELLE_VORGANG vorgang,
> ZWISCHENTABELLE_DOCUMENT document
> where start.SID = ende.SID
> and start.SID = vorgang.SID
> and start.SID = document.SID
> ----------------------------------------------
>
> Läuft immer noch grottig langsam, auch wenn ich die Berechnung von
> SECONDS rausnehme...
>
Nun könntest Du natürlich einfach mal ein
EXPLAIN
auf dein Select loslassen und Dir danach überlegen, welche
Optimierungsmöglichkeiten es gibt.

> Da ich mich mit den Feinheiten von SQL nicht besonders auskenne und auch
> nicht mit Performanceoptimierung bei MySQL (auf die
> DB-Servereinstellungen habe ich übrigens keinen Einfluss), wäre ich
> dankbar für jeden Tip, wie ich das obige Statement vielleicht noch tunen
> kann...
>

Vermutlich hast Du schlicht gar keinen Index auf die Tabelle definiert.

Re: Komplexes Statement optimieren

Jens Riedel schrieb:
> Hallo,
>
> ich stehe momentan vor einem Problem, dass ich ein sehr komplexes
> Statement auf einen relativ großen Datenbestand ausführen muss und die
> Laufzeit daher übelst lang ist (teilweise mehrere Stunden).
>
> Ausgangssituation: eine Tabelle mit den Spalten
>
> SID | LOGTIME | MESSAGE
>
> Jeweils 4 Datensätze gehören zusammen und haben die gleiche SID.
> Je nachdem, was in MESSAGE steht, ist entweder die LOGTIME als START
> oder als ENDE oder ein Teilstring von MESSAGE als Vorgang oder Dokument
> zu werden.
>

Aus meiner Sicht ein kaputtes Design. Diese 4 Datensätze bedeuten für
mich, dass zu einer SID eigentlich 8 verschiedene Daten gespeichert
werden, und das würde ich in einer Zeile machen. Und dann sind 90.000
Datensätze Kinderkram und du wirst die während der Ausführungszeit nicht
mal OOps sagen können.

Ich würde ernsthaft über ein Redesign nachdenken.

Grüße

Dirk

Re: Komplexes Statement optimieren

Christian Kirsch wrote:

> sparsames Datenmodell.

Ich weiß, leider vorgegeben aus der vorgeschalteten Anwendung...

> Nun könntest Du natürlich einfach mal ein
> EXPLAIN
> auf dein Select loslassen und Dir danach überlegen, welche
> Optimierungsmöglichkeiten es gibt.

Ich google gleich mal, wie genau das funktioniert...

> Vermutlich hast Du schlicht gar keinen Index auf die Tabelle definiert.

Hast recht, mittlerweile hab ich jeweils auf die SID-Spalten Indizes,
jetzt schau ich mal, ob es fixer geht.

Gruß,
Jens


--
Der Kluegere gibt nach - Eine traurige Wahrheit:
sie begruendet die Weltherrschaft der Dummen.
- Marie von Ebner-Eschenbach

Re: Komplexes Statement optimieren

Dirk Brosowski wrote:

> Aus meiner Sicht ein kaputtes Design. Diese 4 Datensätze bedeuten für
> mich, dass zu einer SID eigentlich 8 verschiedene Daten gespeichert
> werden, und das würde ich in einer Zeile machen.

Das ist leider nicht zu ändern. Durch eine vorangeschaltete Anwendung
wird ein Server-Log analysiert, welches pro Zeile einen Datensatz erzeugt.
Die Zeilen im File sehen dann unfähr so aus:

Start...
Vorgang X
Document X
Ende...

Dementsprechend werden für eine SID dann 4 Datensätze erzeugt, die ich
anschließend per Abfrage zusammensuchen muss.

> Ich würde ernsthaft über ein Redesign nachdenken.

Wie gesagt, da ist leider nix zu machen.

einziger Trost ist, dass das besagte Statement nur einmal pro Nacht im
Batch läuft, da ist die Laufzeit relativ egal - nur fertig werden sollte
es, daher möchte ich es so optimal wie möglich gestalten, um nicht
irgendwo Grenzen zu überschreiten und ein timeout o.ä. zu kriegen.

Gruß,
Jens


--
Der Kluegere gibt nach - Eine traurige Wahrheit:
sie begruendet die Weltherrschaft der Dummen.
- Marie von Ebner-Eschenbach

Re: Komplexes Statement optimieren

Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)

Re: Komplexes Statement optimieren

Andreas Kretschmer wrote:

> Ach gottchen, das kann man doch mit $Tool auch zusammenfassen.

Kann sein.

>>Wie gesagt, da ist leider nix zu machen.
>
> [x] Du irrst.

Gut, ich formuliere es anders: die Server-Betreuer beim Kunden, der
diese Logfiles anliefert, sind nicht gewillt, hier etwas zu ändern. ;-)

Gruß,
Jens

--
Der Kluegere gibt nach - Eine traurige Wahrheit:
sie begruendet die Weltherrschaft der Dummen.
- Marie von Ebner-Eschenbach

Re: Komplexes Statement optimieren

Jens Riedel wrote:
> Hallo,
>
> ich stehe momentan vor einem Problem, dass ich ein sehr komplexes
> Statement auf einen relativ großen Datenbestand ausführen muss und die
> Laufzeit daher übelst lang ist (teilweise mehrere Stunden).
>
> Ausgangssituation: eine Tabelle mit den Spalten
>
> SID | LOGTIME | MESSAGE

Das ist dann keine Tabelle, sondern einfach ein Logfile in einer
etwas eigenwilligen Form.

Warum will eigentlich jeder seine Logfiles in einer Datenbank
speichern? Wird das Logfile dadurch geadelt? Werden die Daten irgendwie
wertvoller? Vereinfacht es die Auswertung? Irgendwie nix von allem.

> Jeweils 4 Datensätze gehören zusammen und haben die gleiche SID.

Dann faß doch wenigstens die Daten aus den ursprünglich mal 4 Logzeilen
zu einem Datensatz zusammen.

> Je nachdem, was in MESSAGE steht, ist entweder die LOGTIME als START
> oder als ENDE oder ein Teilstring von MESSAGE als Vorgang oder Dokument
> zu werden.

Das würde dann also zu


typ = vorverarbeitung()
switch (typ)
case START: INSERT ... (sid, start) VALUES ()
case VORGANG: UPDATE ... SET vorgang= WHERE sid=...
case DOKUMENT: UPDATE ... SET dokument= WHERE sid=...
case ENDE: UPDATE ... SET ende= WHERE sid=...
end switch


> Da ich mich mit den Feinheiten von SQL nicht besonders auskenne und auch
> nicht mit Performanceoptimierung bei MySQL (auf die
> DB-Servereinstellungen habe ich übrigens keinen Einfluss), wäre ich
> dankbar für jeden Tip, wie ich das obige Statement vielleicht noch tunen
> kann...

Das wäre Herumpfuschen an den Symptomen. Ich werde den Teufel tun und
dir irgendwelche Tips geben, mit denen du ein derart kaputtes Design
unnötig länger am Leben halten kannst.

Eigentlich frage ich mich ja, wozu du überhaupt eine Datenbank
brauchst. Den Report den dein SELECT dir liefert, kann die oben
skizzierte Verarbeitung auch direkt liefern. Du mußt nur die
halbfertigen Datensätze zwischenspeichern und im letzten Schritt
(case ENDE) rausschreiben. In Perl würde das Programm vermutlich
auf eine Bildschirmseite passen.


XL

Re: Komplexes Statement optimieren

Jens Riedel schrieb:
> Dirk Brosowski wrote:
>
>> Aus meiner Sicht ein kaputtes Design. Diese 4 Datensätze bedeuten für
>> mich, dass zu einer SID eigentlich 8 verschiedene Daten gespeichert
>> werden, und das würde ich in einer Zeile machen.
>
>
> Das ist leider nicht zu ändern. Durch eine vorangeschaltete Anwendung
> wird ein Server-Log analysiert, welches pro Zeile einen Datensatz erzeugt.
> Die Zeilen im File sehen dann unfähr so aus:
>
> Start...
> Vorgang X
> Document X
> Ende...
>
> Dementsprechend werden für eine SID dann 4 Datensätze erzeugt, die ich
> anschließend per Abfrage zusammensuchen muss.
>
>> Ich würde ernsthaft über ein Redesign nachdenken.
>
>
> Wie gesagt, da ist leider nix zu machen.

Sehe ich anders: Bei der Anlieferung der Daten direkt eine Aggregation
in ein sinnvolles Tabellendesign. Zeile lesen, testen ob die SID in der
Zieltabelle vorhanden ist, entsprechende Fehlder updaten oder neuen
Datensatz generieren und den Ursprungsdatensatz in der Log-Tabelle
löschen oder markieren. Das alle x Stunden durchführen und auf der
Aggregationstabelle deine Berechnungen durchführen. Fertig.

Grüße

Dirk

Re: Komplexes Statement optimieren

Jens Riedel wrote:
> Andreas Kretschmer wrote:
>
>
>>Ach gottchen, das kann man doch mit $Tool auch zusammenfassen.
>
>
> Kann sein.
>
>
>>>Wie gesagt, da ist leider nix zu machen.
>>
>>[x] Du irrst.
>
>
> Gut, ich formuliere es anders: die Server-Betreuer beim Kunden, der
> diese Logfiles anliefert, sind nicht gewillt, hier etwas zu ändern. ;-)
>
>
Irrelevant - Du kannst die Daten, die Du von denen bekommst, in
beliebiger Form ablegen. Es gibt keine EU-Verordnung, die Dich zwingt,
aus jedem Eingangs- genau einen Ausgangsdatensatz zu machen.

Re: Komplexes Statement optimieren

Dirk Brosowski wrote:

>> Wie gesagt, da ist leider nix zu machen.
>
> Sehe ich anders: Bei der Anlieferung der Daten direkt eine Aggregation
> in ein sinnvolles Tabellendesign. Zeile lesen, testen ob die SID in der
> Zieltabelle vorhanden ist, entsprechende Fehlder updaten oder neuen
> Datensatz generieren und den Ursprungsdatensatz in der Log-Tabelle
> löschen oder markieren.

O.k., dann nochmals: ;-)

Ich kann am Format der Logfiles nichts ändern.

Das Tool, welches ich zum Auswerten der Logfiles verwenden MUSS, liest
jeweils eine Zeile, trennt sie nach einem Muster in ihre Bestandteile
und schreibt diese in jweils einen Datensatz in eine Tabelle.
Mit zusätzlichem Überprüfen ist da nix...

Genau diese beiden Vorgaben führen ja dazu, dass ich solche Probleme mit
dem Statement hatte...

Gruß,
Jens

--
Der Kluegere gibt nach - Eine traurige Wahrheit:
sie begruendet die Weltherrschaft der Dummen.
- Marie von Ebner-Eschenbach

Re: Komplexes Statement optimieren

Christian Kirsch wrote:

> Irrelevant - Du kannst die Daten, die Du von denen bekommst, in
> beliebiger Form ablegen. Es gibt keine EU-Verordnung, die Dich zwingt,
> aus jedem Eingangs- genau einen Ausgangsdatensatz zu machen.

Nein, aber es gibt ein Tool, welches ich zum Auslesen des Logfiles
verwenden MUSS und welches mir daraus genau EIN Ausgabeformat in Form
von Datensätzen zurückgibt.

Ich muss also damit arbeiten, was ich aus Kombination
Logfile-Analysetool erhalte :-(

Aber mittlerweile ist das Problem durch verschiedene nachgeschaltete
Statements und Zwischentabellen gelöst.

Gruß,
Jens

--
Der Kluegere gibt nach - Eine traurige Wahrheit:
sie begruendet die Weltherrschaft der Dummen.
- Marie von Ebner-Eschenbach

Re: Komplexes Statement optimieren

Axel Schwenke wrote:

>>Ausgangssituation: eine Tabelle mit den Spalten
>>
>>SID | LOGTIME | MESSAGE
>
> Das ist dann keine Tabelle, sondern einfach ein Logfile in einer
> etwas eigenwilligen Form.
>
> Warum will eigentlich jeder seine Logfiles in einer Datenbank
> speichern? Wird das Logfile dadurch geadelt? Werden die Daten irgendwie
> wertvoller? Vereinfacht es die Auswertung? Irgendwie nix von allem.

Ich erkläre es dir:

Aus den Logfiles werden verschiedene Auswertungen gemacht. Wir verwenden
dazu ein Tool, welches mit beliebigen Logfile-Formaten arbeitet. Dazu
wird nun mal im ersten Schritt einfach eine Transformation durchgeführt,
die aus jeder Logfile-Zeile einen Datensatz macht, der die relevanten
Informationen als Felder enthält.
Auf dieser Basis werden dann mittels weiterer Statements die endgültigen
Zieltabellen gefüllt, die die verdichteten Daten enthalten.

> Das würde dann also zu
>
>
> typ = vorverarbeitung()
> switch (typ)
> case START: INSERT ... (sid, start) VALUES ()
> case VORGANG: UPDATE ... SET vorgang= WHERE sid=...
> case DOKUMENT: UPDATE ... SET dokument= WHERE sid=...
> case ENDE: UPDATE ... SET ende= WHERE sid=...
> end switch
>

Genau. Wenn wir das programmieren würden, wäre das so. Aber wir
verwenden ja ein Standardtool für alle Logfile-Formate.

> Eigentlich frage ich mich ja, wozu du überhaupt eine Datenbank
> brauchst. Den Report den dein SELECT dir liefert, kann die oben
> skizzierte Verarbeitung auch direkt liefern. Du mußt nur die
> halbfertigen Datensätze zwischenspeichern und im letzten Schritt
> (case ENDE) rausschreiben. In Perl würde das Programm vermutlich
> auf eine Bildschirmseite passen.

Wie gesagt, es geht hier nicht um Individualprogrammierung.
Es gibt eine vorgeschriebene Vorgehensweise, in der ich nur die
Select-Statements beeinflussen kann, die mir aus der Ursprungstabelle
meine Tabelle mit Zieldaten beeinflussen. Und das heißt in diesem Fall,
jeweils 4 Datensätze zu einem zu verdichten.

Gruß
Jens


--
Der Kluegere gibt nach - Eine traurige Wahrheit:
sie begruendet die Weltherrschaft der Dummen.
- Marie von Ebner-Eschenbach

Re: Komplexes Statement optimieren

Jens Riedel wrote:

> Ausgangssituation: eine Tabelle mit den Spalten
>
> SID | LOGTIME | MESSAGE
>
> Jeweils 4 Datensätze gehören zusammen und haben die gleiche SID.

Immer genau 4?

> Je nachdem, was in MESSAGE steht, ist entweder die LOGTIME als START
> oder als ENDE oder ein Teilstring von MESSAGE als Vorgang oder Dokument
> zu werden.
>
> Was ich im Endeffekt brauche, ist ein Statement, was mir zu jeder SID
> die Werte START, ENDE, Laufzeit(Differenz Start und Ende), Vorgang und
> Dokument liefert
....
> Dadurch, dass die Tabelle TABELLENNAME also viermal mit sich selber
> verknüpft wird und dabei ca. 90.000 Datensätze hat, läuft die ganze
> Chose Ewigkeiten.

Dann mach ein Group By und berechne die Werte über MAX(CASE):

select SID,
max(case when message like '%Archive,%' then logtime end) as START,
max(case when message like '%Archive done%' then logtime end) as
END,

kannst du nicht TIMESTAMPDIFF statt der SECONDS-Berechnung nehmen? Das
wird mit den CASEs eklig zu schreiben...

substring(max(case when message like '1038=%' then message
end=,6) as VORGANG,
substring(max(case when message like '1039=%' then message
end),6) as DOCUMENT
from TABELLENNAME
where date_format(start.logtime,'%Y-%m-%d') = ''
group by SID;

Dieter

Re: Komplexes Statement optimieren

Jens Riedel schrieb:
> Dirk Brosowski wrote:
>
>>> Wie gesagt, da ist leider nix zu machen.
>>
>>
>> Sehe ich anders: Bei der Anlieferung der Daten direkt eine Aggregation
>> in ein sinnvolles Tabellendesign. Zeile lesen, testen ob die SID in
>> der Zieltabelle vorhanden ist, entsprechende Fehlder updaten oder
>> neuen Datensatz generieren und den Ursprungsdatensatz in der
>> Log-Tabelle löschen oder markieren.
>
>
> O.k., dann nochmals: ;-)
>
> Ich kann am Format der Logfiles nichts ändern.
>
> Das Tool, welches ich zum Auswerten der Logfiles verwenden MUSS, liest
> jeweils eine Zeile, trennt sie nach einem Muster in ihre Bestandteile
> und schreibt diese in jweils einen Datensatz in eine Tabelle.
> Mit zusätzlichem Überprüfen ist da nix...
>
> Genau diese beiden Vorgaben führen ja dazu, dass ich solche Probleme mit
> dem Statement hatte...

Du bist echt ein schwerer Fall... Warum liest du nicht Datensatz für
Datensatz und schreibst diese dann in eine sinnvolle Tabell? Ist das so
schwer? Ob diese Daten aus einem Logfile oder aus einer Tabelle kommen
ist mir sowas von vollkommen egal. Aber wenn du guten Rat von vielen
Leeuten hier nicht annehmen willst, bitte ...

Grüße

Dirk

Re: Komplexes Statement optimieren

Dirk Brosowski wrote:

> Du bist echt ein schwerer Fall... Warum liest du nicht Datensatz für
> Datensatz und schreibst diese dann in eine sinnvolle Tabell? Ist das so
> schwer?

Dann schau doch nochmal in mein Ursprungsposting:

"Ich habe jetzt als erste Optimierung dafür gesorgt, dass zunächst die
Werte START, ENDE, VORGANG und DOCUMENT in 4 Zwischentabellen
geschrieben werden, welche jeweils auch die Spalte SID haben."

D.h., ich verteile die Datensätze bei der momentanen Lösung bereits auf
mehrere Tabellen, und das klappt auf ganz hervorragend.
Trotzdem war ich daran interessiert, ob man das ursprüngliche Statement
auf die sehr ungünstig aufgebaute Logfile-Tabelle irgendwie optimieren
kann, um sich diesen Zwischenschritt zu sparen.

> Aber wenn du guten Rat von vielen
> Leeuten hier nicht annehmen willst, bitte ...

Will ich durchaus... allerdings geht das schlecht, wenn das Grundproblem
nicht rübergekommen ist und die Ratschläge z.B. "ändere das Logfile",
"lies es anders aus" oder "programmiere das anders" lauten.
Freue mich immer über Vorschläge, aber muss einige nunmal ablehnen, wenn
sie nicht zu verwirklichen sind, das ist dann sicher nicht böse gemeint.

Gruß,
Jens


--
Der Kluegere gibt nach - Eine traurige Wahrheit:
sie begruendet die Weltherrschaft der Dummen.
- Marie von Ebner-Eschenbach

Re: Komplexes Statement optimieren

Jens Riedel schrieb:
> Dirk Brosowski wrote:
>
>> Du bist echt ein schwerer Fall... Warum liest du nicht Datensatz für
>> Datensatz und schreibst diese dann in eine sinnvolle Tabell? Ist das
>> so schwer?
>
>
> Dann schau doch nochmal in mein Ursprungsposting:
>
> "Ich habe jetzt als erste Optimierung dafür gesorgt, dass zunächst die
> Werte START, ENDE, VORGANG und DOCUMENT in 4 Zwischentabellen
> geschrieben werden, welche jeweils auch die Spalte SID haben."
>
> D.h., ich verteile die Datensätze bei der momentanen Lösung bereits auf
> mehrere Tabellen, und das klappt auf ganz hervorragend.

Okay, habe ich überlesen, aber ..

> Trotzdem war ich daran interessiert, ob man das ursprüngliche Statement
> auf die sehr ungünstig aufgebaute Logfile-Tabelle irgendwie optimieren
> kann, um sich diesen Zwischenschritt zu sparen.

ich würde schon versuchen, dem System diese 4 Joins zu ersparen.

Für statistische und ähnliche Zwecke sind Aggregattabellen hervorragend
geeignet und die würde ich hier einsetzen und aus deinen 4 Tabellen
wieder eine machen, damit die 4 Joins weg sind.

Als erstes sollte man immer überprüfen ob der Weg den man geht effizient
ist, dann diesen Weg optimieren und erst danach denkt man z.B. in der IT
über Hardwareupdates nach. D.h. heisst bevor du ein SQL-Statement
(ins. für Statistiken) langwierig optimierst überlege, ob du mit Hilfe
von Aggregattabellen ein Teil der Arbeit trivial anders erledigen kannst.

Grüße

Dirk

Re: Komplexes Statement optimieren

Dirk Brosowski wrote:

> ich würde schon versuchen, dem System diese 4 Joins zu ersparen.
>
> Für statistische und ähnliche Zwecke sind Aggregattabellen hervorragend
> geeignet und die würde ich hier einsetzen und aus deinen 4 Tabellen
> wieder eine machen, damit die 4 Joins weg sind.

Momentan läuft es halt so:

1.) aus der Tabelle mit jeweils 4 zusammengehörigen Sätzen werden diese
4 Sätze auf 4 Zwischen-Tabellen verteilt.
2.) aus diesen Zwischentabellen werden anschließend die Daten aus den 4
zusammengehörigen Sätzen zusammengeführt und als ein Datensatz in die
endgültige Tabelle geschrieben, auf die dann die Statements zur
Auswertung bzw. Visualisierung ausgeführt werden.

> Als erstes sollte man immer überprüfen ob der Weg den man geht effizient
> ist, dann diesen Weg optimieren und erst danach denkt man z.B. in der IT
> über Hardwareupdates nach. D.h. heisst bevor du ein SQL-Statement (ins.
> für Statistiken) langwierig optimierst überlege, ob du mit Hilfe von
> Aggregattabellen ein Teil der Arbeit trivial anders erledigen kannst.

Ich bin mir nicht sicher, ob Aggregattabellen ungefähr das sind, was ich
oben mit der endgültigen Tabelle meine, aber ich würde es so verstehen.

Viele Grüße,
Jens

--
Der Kluegere gibt nach - Eine traurige Wahrheit:
sie begruendet die Weltherrschaft der Dummen.
- Marie von Ebner-Eschenbach

Re: Komplexes Statement optimieren

Jens Riedel schrieb:
> Dirk Brosowski wrote:
>
>> ich würde schon versuchen, dem System diese 4 Joins zu ersparen.
>>
>> Für statistische und ähnliche Zwecke sind Aggregattabellen
>> hervorragend geeignet und die würde ich hier einsetzen und aus deinen
>> 4 Tabellen wieder eine machen, damit die 4 Joins weg sind.
>
>
> Momentan läuft es halt so:
>
> 1.) aus der Tabelle mit jeweils 4 zusammengehörigen Sätzen werden diese
> 4 Sätze auf 4 Zwischen-Tabellen verteilt.
> 2.) aus diesen Zwischentabellen werden anschließend die Daten aus den 4
> zusammengehörigen Sätzen zusammengeführt und als ein Datensatz in die
> endgültige Tabelle geschrieben, auf die dann die Statements zur
> Auswertung bzw. Visualisierung ausgeführt werden.
>
>> Als erstes sollte man immer überprüfen ob der Weg den man geht
>> effizient ist, dann diesen Weg optimieren und erst danach denkt man
>> z.B. in der IT über Hardwareupdates nach. D.h. heisst bevor du ein
>> SQL-Statement (ins. für Statistiken) langwierig optimierst überlege,
>> ob du mit Hilfe von Aggregattabellen ein Teil der Arbeit trivial
>> anders erledigen kannst.
>
>
> Ich bin mir nicht sicher, ob Aggregattabellen ungefähr das sind, was ich
> oben mit der endgültigen Tabelle meine, aber ich würde es so verstehen.

Genau, und so würde ich es auch lassen. Wird die schnellste Methode sein.

Grüße

Dirk