günstiger Reorg-Startzeitpunkt
- Dieses Thema hat 5 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 18 Jahre, 11 Monaten vonMitglied.
- AuthorPosts
- 19. Juni 2004 um 5:36 Uhr #2407
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
21. Juni 2004 um 6:15 Uhr #2890Hallo 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
Rolf24. Juni 2004 um 15:30 Uhr #3242Hallo 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
Alexander24. Juni 2004 um 18:54 Uhr #3472Hallo 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
Gernot26. Juni 2004 um 2:41 Uhr #3618Hallo 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
28. Juni 2004 um 8:31 Uhr #3729ich denke, Gernot meint mit "Update des Catalogs mit repräsentativen Werten " einen RUNSTATS zum richtigen Zeitpunkt.
Alexander
- AuthorPosts
You must be logged in to reply to this topic.
