View Full Version : performance: index PF oder LF
Tach auch
gibt es Aussagen über die Zugriffsgeschwindigkeit von SQL in abh. von PF mit Key vs. PF ohne Key + LF
möglichst nicht geschätzt oder vermutet, sondern von IBM
Danke
Euer IleMax
... was denn nun, von IBM oder keine Marketing Aussagen? Bei letzterem kannst du nur konkrete Fälle messtechnisch untersuchen und kriegst Blech abhängige Werte in Abhängigkeit von Hauptspeicher, Platten und CPU und deren Verhältnis zueinander.
D*B
Tach auch
gibt es Aussagen über die Zugriffsgeschwindigkeit von SQL in abh. von PF mit Key vs. PF ohne Key + LF
möglichst nicht geschätzt oder vermutet, sondern von IBM
Danke
Euer IleMax
Ob eine PF einen Key hat oder nicht dafür entsprechende LF's vorhanden sind ist unerheblich.
Der Optimizer sucht sich das zusammen.
Schneller angeblich ist SQL wohl mit TABLE und INDEX, da hier größere Blöcke verwendet werden.
Ansonsten heißt es immer wieder: probieren, probieren, probieren.
Pauschale Aussagen sind da nicht hilfreich.
Danke,
ich dachte ich könnte die Grundsatzdiskussion die hier grade läuft mit dem performance Argument für mich entscheiden (ich bin für PF + LF)
mit 'egal' ist mir nicht geholfen
Trotzdem Danke
IleMax
Wie gesagt TABLE + INDEX ist meist schneller als PF+LF.
Eine PF mit eigenen Keys ist genauso schnell wie eine PF mit einer LF.
Siehe auch Diskussion:
PF - prüfen beim Lesen, nicht prüfen beim Schreiben
TABLE - prüfen beim Schreiben, nicht prüfen beim Lesen
Das erklärt auch, warum eine TABLE schneller ist als eine PF.
Messbar wird das allerdings erst bei Massenzugriffen und nicht bei einzelnen Sätzen.
andreaspr@aon.at
22-03-10, 20:48
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
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.
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
... 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
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