Indizes einer Datenbank neu aufbereiten

[ibp]

Mit
SET STATISTICS INDEX dingensfeldIDX kann man den Index aufbereiten und die Statistik aktualisieren. Dadurch kann unter Umständen die Suche auf inizierten Feldern deutlich beschleunigt werden.
Sinnvoll ist die Aktualisierung mindestens ein mal pro Tag, je nach Datenaufkommen.

Nachfolgender Code bereitet alle Inizes einer Datenbank auf. (Getestet mit Interbase 6.5 ohne Fehlerbehandlung)

Delphi-Quellcode:

..
qIndex.SQL.Text:='select rdb$index_name from RDB$INDICES where NOT (RDB$RELATION_NAME LIKE ''RDB$%'')';
qIndex.Open;

while not qIndex.Eof do
begin
  qUpdateIndex.SQL.Text:='set statistics index '+qIndex.FieldByName('rdb$index_name').AsString;
  qUpdateIndex.ExecSQL;
  ..
  qIndex.Next;
end; // while
..

[mkinzler]

Eigentlich sollte ein manuelle Aktualisierung von Idinzes nicht notwendig sein.

[TBx]

Zitat von mkinzler:

Eigentlich sollte ein manuelle Aktualisierung von Idinzes nicht notwendig sein.

Hier muß ich Dir widersprechen.
Interbase (zumindest bis 6.5, dannach habe ichs nicht mehr weiter verfolgt) und Firebird errechnen die Selektivität eines Indexes nur bei Anlage des Indexes und beim Restore der Datenbank.
Von daher ist das SET STATISTICS eine recht sinnvolle Sache. Es sollte durchgeführt werden, sobald ein repräsentativer Datenbestand vorhanden ist. Auch wenn die Geschwindigkeit zu wünschen übrig läßt, sollte man die Selektivität der Indexe mitels SET STATISTICS INDEX neu berechnen lassen.
Von einer häufigen Anwendung des SET STATISTICS INDEX würde ich abraten.

Gruß

Thomas

[ibp]

Zitat von mkinzler:

Eigentlich sollte ein manuelle Aktualisierung von Idinzes nicht notwendig sein.

..teste es doch mal und schau dir vorher und nacher die Statistik an.

Zitat von onlinekater:

Von einer häufigen Anwendung des SET STATISTICS INDEX würde ich abraten.

..was heisst häufig?

P.s.: geht übrigens auch bei den nachfolgeversionen von Interbase

[IBExpert]

geht übrigens bei fb >=15 direkt als prozedur

SQL-Code:

CREATE PROCEDURE REINDEX
AS
declare variable SQL VARCHAR(200);
BEGIN
  FOR
    select rdb$index_name from rdb$indices
    INTO :SQL
  DO
  BEGIN
    SQL='SET STATISTICS INDEX '||SQL||';';
    execute statement :sql;
  END
END

[edit=Matze]SQL-Tags gesetzt. Mfg, Matze[/edit]

[alzaimar]

Bei MSSQL (falls es interessiert) gibt es ein ähnliches Problem: Die Performance ist nur so gut wie die Aktualität der Index-Statistiken. Daher haben wir einen Dafault-Maintenance-Job, der 1x pro Woche (Sonntags, weil da sowieso nix los ist) so eine Routine am laufen: Die Datenbank wird gesäubert, die Indexe neu erstellt etc.

Die Theorie besagt, das sich die Statistiken selbst optimieren. Also ich kann das nicht bestätigen, aber vielleicht habe ich es auch nur nicht ausprobiert. Jedenfalls läuft das System ordendlich mit wöchtentlichen Indexupdates.

NB: Es kommen täglich ca. 20MB Daten hinzu. Die 'Statistik' eines Indexes verändert das natürlich nicht mehr, sodaß man den Job vermutlich nicht benötigt. Eine Index-Statistik enthält informationen über die Verteilung und Anzahl der unterschiedlichen Schlüssel relativ zur Gesamtanzahl. Wenn sich dieses Verhältnis nicht großartig ändert, kann man -meine ich- auf die Neuberechnung verzichten.

[ibp]

Zitat von alzaimar:

Eine Index-Statistik enthält informationen über die Verteilung und Anzahl der unterschiedlichen Schlüssel relativ zur Gesamtanzahl. Wenn sich dieses Verhältnis nicht großartig ändert, kann man -meine ich- auf die Neuberechnung verzichten.

..wann ändert sich das verhältnis? kann man das bei jedem index einschätzen? das hängt doch von der art des feldes und der dazukommenden daten ab.

[alzaimar]

ibp: Natürlich ist das immer unterschiedlich, deshalb werden ja die Statistiken geführt. Wenn Du z.B. einen Index über die Kunden-PLZ hast und hattest bis jetzt nur Kunden aus dem berliner Raum ('1xxxx'), und nun erweiterst Du dein Einzugsgebiet auf ganz Deutschland, wird sich der Inhalt der PLZ, und damit die Statistik relevant ändern.

Bleibt es hingegen bei 'business as usual', ist nach einer gewissen Einarbeitungszeit kein Statistik-Update erforderlich.

Und da das eben von Fall zu Fall unterschiedlich ist, bauen wir das präventiv in einem Sonntagslauf ein. Anfangs macht man das vielleicht täglich (solange man Testdaten hat, die DB tuned oder noch nicht so viele Daten drin sind).

[Elvis]

@alzaimar
Ich habe noch nicht lange genug mit MSSQL zu tun, um zu wissen wie die Nebeneffekte von forcierten Statistiken dort aussehen, aber...
Bei Oracle kann man so sehr schnell in die Falle rennen.
Wenn die Statistiken nicht einmal mehr grob den Daten entsprechen kann es dazu führen, dass mit im Generieren eines Abfrageplans der bisherige verworfen und ein neuer erstellt wird.
Sowas macht IMHO nur Sinn wenn sich die Verteilung der Daten tatsächlich über die Zeit radikal ändert und dann sollte man möglichst zügig eine neue Statistik haben.

[alzaimar]

Mir ist nicht bekannt, das es zu radikalen Performance-Einbußen nach einer Neuberechnung der Statistiken führt. Allerdings setze ich mich da auf die faule Haut und sage mir:"Alles ist OK, solange der Kunde nicht meckert". Weiterhin loggen wir, wenn eine Op länger als erwartet (5x länger) benötigt, um eventuelle Probleme sofort zu erkennen. Bis auf die Aussetzer infolge eines kranken Netzes ist Nichts zu erkennen, also wird es wohl nicht so schlimm sein.

Der Maintenance Plan Wizzard im Enterprise Manager bietet die Option, die Statistiken neu zu erstellen. Vermutlich ist MSSQL hier etas freundlicher zum Anwender/Admin, als Oracle. Oracle ist dafür aber eben unerreicht schnell.