Glaubensfrage LF / index und performance

[Robi]

Hi *all
hat das mal einer versucht oder gibt es ein begründetes theoretisches 'richtig'?

Ein Job erzeugt 10 Statistik Dateien
die kleinsten beiden beinhalten 73 Sätze, die größte 50 Mio
Dann noch eine mit 11 Mio und der Rest zwischen 1,5 und 2 Mio Sätzen.

In die Dateien wird nur geschrieben.
Für den später benötigten Zugriff wird je ein LF benötigt. (Oder Index)

Was ist schneller?
a) Alle PF erstellen, alle LF erstellen, alle Dateien füllen
b) Alle PF erstellen, alle Dateien füllen, alle LF erstellen
c) wie a nur mit Index statt LF
d) wie b nur mit Index statt LF

Robi

[Fuerchau]

b) ist der schnellste, zumal bei großen Dateien die Indexmaintenance kostet.
Die LF's/Indizes können später aber parallel in mehreren Job's erstellt werden.

Der Unterschied LF/Index ist nur marginal (betrifft die Blockgröße).
Was tatsächlich schneller ist bleibt zu testen.

Bei einem meiner Kunden werden die LF's regelmäßig gelöscht, die Statistiken neu aufgebaut und die LF's dann erstellt.
Laufzeit früher ca. 4 Stunden, heute ca. 30 Minuten!
Datei 1 ca. 9 Mio Sätze 7 Indizes, Datei 2 ca. 7 Mio., 3 Indizes

[ILEMax]

Hi,
unsere Erfahrung ist genau anders rum (vor ca. 4 Jahren getestet).
Das nachträgliche aufbauen des LF über große Datenmengen läuft so lange, das es besser ist das LF zur Laufzeit mit auf zu bauen. Ok, das war V5R4. Wir habe es extra getestet. Der Unterschied lag bei 2 Dateien a ca. 14 Mio Sätzen bei etwas über 10 Minuten (soweit ich mich erinnere).
Müsst ich glatt noch mal testen, ...
Der ILEMax

[Fuerchau]

Nun, zusammen mit Dieter Bender habe ich da andere Erfahrungen (s.o.) machen müssen.

Allerdings kommt da noch mehr zusammen.
Angenommen die DB kann 2000 Sätze/Sekunde ohne Index schreiben (ich weiß, die kann auch mehr).
Pro Index reduziert sich dies um angenommene 5%.
D.h., bei 2 Indizes sind das dann nur noch 1800/Sekunde.
Da das Programm aber auch Daten sammeln und berechnen muss, kann die Schreibrate unter dem maximal Möglichen liegen, z.B. nur bei 1000/Sekunde.
D.h., dass man ruhig 10 Indizes (=50%) parallel pflegen lassen kann, da das System genug Zeit hat und das Programm eben langsam ist. Ein späterer Neuaufbau ist in diesem Fall zeitlich schädlich.
Dazu kommt ja auch noch, dass man das Parallel-Feature für die DB aktiv haben muss um Indizes über mehrere CPU's parallel aufbauen zu können.

Die obigen Zahlen entsprechen jetzt keiner Realität sondern dienen nur als Beispiel.

Extrem kann man dies bei z.B. CPYF bzw. SQL Insert-Select beobachten.

[andreaspr@aon.at]

Allein schon wegen der Baumstruktur sollte ein Index erst am Ende angelegt werden, sofern dies möglich ist.
Die DB weis anhand der ersten Daten nicht wie sich die Baumstruktur des Index entwickeln wird. Da kann ein Rebuild eines Index nach einer Zeit schon empfehlenswert sein.
Wenn der Index jedoch am Ende erzeugt wird, wird die Baumstruktur schon entsprechend korrekt aufgebaut.

lg Andreas

[BenderD]

... die Überschrift war schon treffend: Glaubensfrage!!!
Für die Gottlosen unter uns: da hilft nur im Einzelfall messen und sich darüber im klaren sein, dass sich das ändern kann.
Zu den konkreten Fragen: wenn sich das bei diesen lächerlich kleinen Datenmengen störend bemerkbar macht, dann sollte man untersuchen was da faul ist. Bei wirklich großen Datenmengen (mehr als einige hundert Millionen records) muss man sich darüber im klaren sein, dass da manche Zeiten exponentiell mit Datenmenge ansteigen, da muss man im Einzelfall untersuchen und Lösungen finden (nur Scharlatane haben Patentrezepte).
Beim Indexaufbau kommt es auch darauf an wie sortiert die physischen Daten sind, sind die sehr strubbelig, ist es wurscht, ob ich das mit maint mache. oder ohne; "fast sortierte" Daten sind meist beim nachgelagerten indizieren/sortieren schneller. Index und LF ist tendenziell egal, es sei denn, dass es da mix zwischen Indexdesign und RLA gibt, dann sind Indexe besser; das vielbeschrieene Page sizes etc, ist eher im Bereich des Grundrauschens (unter der Messbarkeitsschwelle) - gerade hier toben sich wieder viele Scharlatane beiderlei Geschlechts aus.
Baldurs angesprochene gemeinsame Studien beziehen sich primär auf SQL bulk Operationen mit Terrabyte Daten und parallel Database Feature, bei transactional workload ist massiv parallel, mit Commit und allen Indexen meist das schnellste (wenn man die Ressourcen hat).

D*B

Hi *all
hat das mal einer versucht oder gibt es ein begründetes theoretisches 'richtig'?

Ein Job erzeugt 10 Statistik Dateien
die kleinsten beiden beinhalten 73 Sätze, die größte 50 Mio
Dann noch eine mit 11 Mio und der Rest zwischen 1,5 und 2 Mio Sätzen.

In die Dateien wird nur geschrieben.
Für den später benötigten Zugriff wird je ein LF benötigt. (Oder Index)

Was ist schneller?
a) Alle PF erstellen, alle LF erstellen, alle Dateien füllen
b) Alle PF erstellen, alle Dateien füllen, alle LF erstellen
c) wie a nur mit Index statt LF
d) wie b nur mit Index statt LF

Robi

[UFK]

Dem stimme ich erstmal zu, also was die Kollegen Fürchau und Bender oben geschrieben haben.

Im Weiteren finde ich es noch lohnenswert, die Schlüssel der LF's oder Index-Dateien zu betrachten,
soweit es nicht zu viele sind, und sie auch längerfristig gleich bleiben. Mit etwas Geschick kann man da
erstmal komplexe Schlüssel auswählen und bilden lassen, bei denen die einfacheren nebenbei abfallen,
so daß man den Zeitaufwand einiger CRTLF oder CREATE INDEX-Befehle reduzieren kann.

Ich würde auch z.B. STRDBG eingeben, bevor ich beginne, und die bei F10 eingeblendeten Kommentare der DB-Engine lesen, nachdem ich die LF's oder Indizes gebildet habe. Außerdem würde ich dies auch beim Aufruf der Reports machen, um sicher zu gehen, daß die LF's und Indizes auch wie gedacht verwendet werden, denn manchmal werden die auch von der SQL-Engine ignoriert, und temporär nochmal neue Indizes gebildet. Man kann das evtl. auch ahnen, wenn der Report vorm Start eine gewisse Denkpause einlegt, bevor er die ersten Seiten Output liefert.