create index - wann?

[Bobou]

Hallo Zusammen,

ich habe eine Frage zur SQL-Funktion "create index".

Wann ist es erforderlich ein Index neu zu erstellen?
Wir löschen und erstellen diese täglich neu, ist dieses überhaupt erforderlich?
Und wenn ja aus welchem Grund?

Vielen Dank im Voraus
schöne Grüße

Bobou

[Fuerchau]

Löschen und Neu erstellen ist vollkommen unsinnig!
Wozu sollte das gut sein?
Ein Index wird vom System vollständig und permanent mit gepflegt. Je mehr Indizes, desto länger dauert ein Insert/Update/Delete.
Für bestimmte Massenupdates lohnt es sich durchaus, die Pflege temporär auszuschalten (CHGLF reicht da) und hinterher wieder einzuschalten (was sich auch parallelisieren läst).

Ein Index ist per Grundsatz nicht erforderlich sondern dient lediglich der Beschleunigung von Zugriffen, wenn die Schlüsselauswahl der jeweiligen join/where/group/order-Klausel entspricht.

[Bobou]

Danke für die Antwort.

Wie ist es wenn die physische Datei gelöscht wird.
Sollte danach der Index neu erstellt werden?

[B.Hauser]

Danke für die Antwort.

Wie ist es wenn die physische Datei gelöscht wird.
Sollte danach der Index neu erstellt werden?

Indices sind immer uptodate, wenn also die Tabelle/Datei (bzw. die Daten in der Tabelle) gelöscht wird, werden auch die Indices automatisch bereinigt.

Ein Index ist (fast) nichts anderes als eine geschlüsselte logische Datei.
... und ich gehe stard davon aus, dass Ihr Eure logischen nicht jede Nacht neu erstellt.

Birgitta

[Fuerchau]

Wobei das Beeinigen des Indexes beim Löschen einer PF auch als Delete des Objektes interpretiert werden kann.
Ein DLTF einer PF ist nicht möglich, wenn DDS-LF's noch angehängt sind.
Ein DLTF einer TABLE impliziert das Löschen seiner Indizes gleich mit.

[andreaspr@aon.at]

Beim Erstellen eines Index wird zuerst eine Analyse der Daten gemacht und basierend darauf der Baum aufgebaut.
Wenn sich die Daten im laufe der Zeit in eine ganz andere Richtung bewegen als von der DB angenommen, kann es sein das der Baum nicht sooo optimal aufgebaut ist.
Da kann es schon zu besseren Werten kommen wenn der Baum neu aufgebaut wird.

Das ist aber normalerweise nicht nötig. Und selbst wenn, braucht man das nur 1 mal machen und fertig.

lg Andreas

[B.Hauser]

Ein DLTF einer PF ist nicht möglich, wenn DDS-LF's noch angehängt sind.
Ein DLTF einer TABLE impliziert das Löschen seiner Indizes gleich mit.

Wie kommst Du bloß auf solche schwindeligen Aussagen?
Der CL-Befehl DLTF löscht WEDER DDS-beschriebene physische Dateien NOCH SQL Tabellen, wenn auf diesen mindestens ein Index, eine View, eine DDS beschriebene logische Dateie oder Trigger liegt!

Der SQL Befehl DROP TABLE löscht sowohl eine physische Datei als auch eine SQL Tabelle mitsamt den abhängigen Objekten (Indices, Views, logische Dateien, Trigger), unabhängig davon, ob diese DDS oder SQL beschrieben sind.

@Andreas:
Im Prinzip hast Du recht (für andere Datenbanken u.a. DB2 LUW).
Da die DB2 for i jedoch im Betriebssystem integriert ist, können ganz andere Mechanismen greifen, so dass auch die Struktur-Bäume immer optimiert sind.

Birgitta

[BenderD]

- die Unterschiede zwischen einzelnen DB Systemen dürften hier marginal sein, insbesondere zwischen den einzelnen DB2 Varianten. Der Urahn von DB2, das System R hat von Beginn an sogenannte B-trees für die Indexe verwendet - und die sind selbst balancierend.
- die mesiten Datenbanksysteme verwenden da auch B-trees (die kamen bis auf System 38 später)
- Einbettung in das Betriebssystem bringt hier nichts, das sind Operatioen, die sich auf Table Ebene abspielen.
- DB2/400 ist hier klar im Nachteil, da die Datenbank auch noch Datenschrank (ISAM mit RLA) können muss. (funktioniert aber trotzdem gut, seit die Hardware stark genug ist)
- neu Erstellung könnte gerade auf der AS/400 auch Nachteile bringen, da die Reihenfolge der Erstellung von Zugriffspfaden auf der AS/400, wg. Access path sharing, kritisch ist.

D*B

[andreaspr@aon.at]

Und wieder gilt, fast jeder Post = eine andere Meinung.
Zusammengefasst sind sich zumindest alle einig, dass ein Rebuild nicht notwendig ist.