... 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
Zitat Zitat von cbe Beitrag anzeigen
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