performance: index PF oder LF

[andreaspr@aon.at]

soviel ich weiß ist eine table mit key-feldern ein wenig schneller, da bei einem LF auf 2 objekte zugegriffen werden müssen (LF -> PF). und bei einem table mit keys brauch ich nur die eine table für den zugriff.$
wenn ich eine große abrage mache ist meines wissens der performance-unterschied verschwindend gering. interessant wäre es wenn in einer schleife 1 mio mal ein update ausgeführt wird.

lg andreas

[Fuerchau]

Da die LF mit der PF verpointert ist, ist der Zugriff hier genauso schnell. Selbst wenn 2mal zugegriffen werden müsste, ist dies auch nur beim Open der Fall.
Ein Schlüssel verweist direkt auf den Datensatz per Adresse.
Deshalb dauert ja ein RGZPFM oder Neuaufbau eines Index ja so lange, da nun mal diese Referenzen neu aufgebaut werden müssen.

[cbe]

Hallo allerseits,

vielleicht noch ein anderer Aspekt:

Ich hatte eine _große_ PF, die ein 6-stelliges Feld mit JJMMTT als Key-Feld enthielt.
Vor gut 10 Jahren wurde dann das Feld erweitert und anschl. das JH zugefügt

Da habe ich geflucht! Die vielen LFs konnte ich abhängen und nach der Bestückung mit JH wieder gesamt aufbauen. Das hat nur ein paar Stunden gedauert.
Den Key in der PF konnte ich halt nicht abhängen, d.h. jeder einzelne geänderte Satz sorgte für ein umsortieren der Datei. Das hat _ewig_ gedauert :-(


Vorher fand ich PF mit Key auch ganz ok, aber man lernt ja immer wieder dazu...

Gruß,
Christian

[BenderD]

... nur am Rande: Für einen Index wird nix sortiert, das ist als (mehrstufiger) binärer Baum implementiert, da werden nur Verpointerungen von Knoten gepflegt. Bei einer solchen Änderung (Feld des Primärindexes vergrößern) müssen die betroffenen Indexe gelöscht werden, egal ob sie zur PF gehören oder nicht und selbige muss eh gelöscht werden (Copy Arie hin und zurück), wenn sich ein Feld in der Dimenionierung ändert.
Früher galt mal: wenn der Primär Index beschädigt ist und zur PF gehört, dann muss per Restore geheilt werden, ist er separat reicht Neuaufbau des Index. Dieses Argument ist für SQL wahrscheinlich schwächer geworden (eine Constraint kann man mit drop bearbeiten) aber möglicherweise nicht ganz weg.
Ansonsten ist das ganze Perfomance Gedöns mit Prüfung ob und wann und Tralala bestenfalls nutzlose Beschäftigung auf Nebenkriegsschauplätzen, daran entscheidet sich nicht, ob eine Anwendung langsam oder schnell ist, oder ob die Datenbank besser oder schlechter skaliert, das ist alles Marketing Getute aus der Schublade: DB2 jetzt auch mit Kalkseifenentferner oder jetzt wäscht RPG noch weißer als vorher - und da wusch es schon so weiß, dass es weißer nicht ging!

D*B

Hallo allerseits,

vielleicht noch ein anderer Aspekt:

Ich hatte eine _große_ PF, die ein 6-stelliges Feld mit JJMMTT als Key-Feld enthielt.
Vor gut 10 Jahren wurde dann das Feld erweitert und anschl. das JH zugefügt

Da habe ich geflucht! Die vielen LFs konnte ich abhängen und nach der Bestückung mit JH wieder gesamt aufbauen. Das hat nur ein paar Stunden gedauert.
Den Key in der PF konnte ich halt nicht abhängen, d.h. jeder einzelne geänderte Satz sorgte für ein umsortieren der Datei. Das hat _ewig_ gedauert :-(


Vorher fand ich PF mit Key auch ganz ok, aber man lernt ja immer wieder dazu...

Gruß,
Christian

[cbe]

klar musste der Index neu aufgebaut werden, wenn ich das Feld vergrößere.

Hierfür habe ich die Daten gesichert
die LFs gelöscht
die PF neu erstellt
die Daten wieder per CPYF zukopiert
dann 19 bzw. 20 in das Key-Feld dazugeschrieben
und zuletzt die LFs wieder aufgebaut

Das Problem war eben, dass _beim_Update_jedes_einzelnen_Satzes die AS den Index in der PF aktualisiert hat, was dadurch viel länger dauerte, als 1x neuaufbauen am Ende, so wie bei den LFs

[BenderD]

... das kann man mit CHGPF bzw. CHGLF einstellen, ob der Zugriffspfad sofort aktualisiert wird, oder nicht, bzw. man muss eine Constraint nicht sofort anlegen, kann sie auch mit alter table drop constraint aufheben und später einrichten...

D*B

klar musste der Index neu aufgebaut werden, wenn ich das Feld vergrößere.

Hierfür habe ich die Daten gesichert
die LFs gelöscht
die PF neu erstellt
die Daten wieder per CPYF zukopiert
dann 19 bzw. 20 in das Key-Feld dazugeschrieben
und zuletzt die LFs wieder aufgebaut

Das Problem war eben, dass _beim_Update_jedes_einzelnen_Satzes die AS den Index in der PF aktualisiert hat, was dadurch viel länger dauerte, als 1x neuaufbauen am Ende, so wie bei den LFs

[cbe]

oh, gut zu wissen.
Das hätte mir beim y2k einiges an Zeit + Nerven gespart, danke für den Tip

(also auch kein Argument für oder wider Key in PF)

[BenderD]

... die diversen Indexe kann man dann noch in parallelen Jobs aufbauen, dann geht das noch fixer.

D*B

oh, gut zu wissen.
Das hätte mir beim y2k einiges an Zeit + Nerven gespart, danke für den Tip

(also auch kein Argument für oder wider Key in PF)

[Robi]

Ich klink mich hier mal ein ..

wir haben hier ein PF mit Key

K FINRCD
K SARTCD
K SPRCCD
K SAKZCD
K RKEYCD

beim Zugriff mit SQL hab ich unter debug diese Zugriffspfad Empfehlung
FINRCD SARTCD SPRCCD SAKZCD

Das versteh ich nicht.
Kann SQL nicht mit Key PF ?

Danke
Robi

[Pikachu]

Da müßte eigentlich auch noch stehen, welche Zugriffspfade alle berücksichtigt wurden und welcher ausgewählt wurde und welche anderen warum nicht ausgewählt wurden.

[andreaspr@aon.at]

und welcher Zugriffspfad wurde schlussendlich genommen?
Mit welchen Schlüsseln gehst du auf die Tabelle Lesen?
Welche Schlüssel hat der Zugriffspfad der von SQL genommen wurde, falls nicht direkt die PF genommen wurde?

[Robi]

Ist ne gekeyte PF, ohne LF

Joblog
... alle Zugriffspfade berücksichtigt
(und bei F1 dann soetwas wie keiner der Zugriffspfade passt) sorry, der log ist weg
dann kommt sowas wie ... nach Eingangsreihenfolge (nur sinngemäß)
und dann halt der empfohlene Zugriffspfad.

mehr nicht
Robi