Anonym.
Liebes Forum,
unsere Datenbank hat Tabellen, die in der Nacht fast komplett abgearbeitet (gelöscht) werden und sich tagsüber wieder füllen.
Wann ist der beste Reorg-Zeitpunkt ?
Im voraus vielen Dank und herzliche Grüße !!
Eva
Hallo Eva,
das ist schwierig, ich nehme an das die Rows inserted werden (statt Load Resume).
Hast Du schon mal darüber nachgedacht den Clustering Index so anzupassen, das ein Reorg nicht notwendig ist? Ist er jetzt überhaupt notwendig?
Viele Grüße
Rolf
Hallo Eva,
kann dem Rolf im Prinzip nur Recht geben. Ich würde dem TS und dem Clustering Key (ich nehme an, das ist der, nachdem die Tabelle abgearbeitet wird) eine relativ hohes PCTFREE bzw. FREEPAGE mitgeben, damit die Daten im Laufe des Tages immer brav im TS an die richtige Stelle kommen und im IX wenig Splits verursachen.
Reorganisieren würde ich dann, wenn der TS wieder relativ leer ist, um den Platz der gelöschten Daten freizugeben. Und das zur Not auch täglich. (Hast Du mal über einen REORG DISCARD nachgedacht?)
Grüsse
Alexander
Hallo Eva,
Börsianer und UDB’ler kennen den Begriff schon lange: "[glb]Volatile[/glb]". Mit DB2 UDB LUW >= V7.x und DB2 for z/OS V8 kann man Table als VOLATILE markieren, was der Optimizer berücksichtigt. 😮
Vermutlich geht es Dir nicht um die Wiedergewinnung von Platz, sondern um die Performance: Wenn die INSERT’s in CLUSTERING Reihenfolge (fortlfd. Key, Timestamp etc) eingefügt werden, wird die CLUSTERRATIO sehr gut sein. Hier kennen die UDB’ler übrigens noch das APPEND Table Attribute, das dafür sorgt, dass alle Neueinfügungen ganz ans Ende kommen und erst gar kein Freespace gesucht wird. Mit PCTFREE 0 und FREEPAGE 0 sollte man einen ähnlichen Effekt erzielen können.
Vielleicht solltest Du, bis V8 kommt, den Reorg/Runstats nicht übermäßig bewerten, stattdessen den Update des Catalogs mit repräsentativen Werten und/oder Optimizer Hints in Betracht ziehen. :-/
War Deine Frage von akademischem Interesse oder gibt’s konkrete Probleme?!
Viele Grüße
Gernot
Hallo zusammen,
eigentlich muss die Antwort auf diese Frage wie bei DB2 üblich mit ‚it depends‘ anfangen. Es kommt stark darauf an warum georganisiert werden soll, wie das Wachstum der Tabelle aussieht und wie die restlichen SQL-Zugriffe aussehen.
Allerdings warne ich vor Catalog-Updates, nicht zuletzt auch aus eigener Erfahrung. Catalog-Updates wirken sich auf alle Packages aus und auf dynamisches SQL. Hier kann es schnell zu ungewollten Seiteneffekten kommen.
Ich m̦chte hier keine akademisch Diskussion ausl̦sen Рmeist lassen sich die Probleme recht einfach in den Griff kriegen.
Ciao Rolf
ich denke, Gernot meint mit "Update des Catalogs mit repräsentativen Werten " einen RUNSTATS zum richtigen Zeitpunkt.
Alexander
You must be logged in to reply to this topic.
