Firebird DB optimieren

[DataCool]

Hi,

ich habe eine Firebird Datenbank mit ca. 400-500 MB.
In naher Zukunft werde ich diese nach MySQL portieren, aber das tut nicht zur Sache !

Die Datenbank setzt sich aus diversen Einzel-Datenbanken von deutschland weiten Clients zusammen, die Nachts Ihre Daten übertragen.
Die Daten werden dann per Batchmove(über BDE) in die Zentral/Hauptdatenbank integriert.

Auf diese Weise wächst die Grösse der DB immer sehr schnell, deshalb habe ich mir(Quick und Dirty) eine Routine geschrieben,
die Nachts nach den ganzen Syncronisationen der Clients, die Datenbank packt bzw. optimiert.

Ich nehme mir eine leere DB kopiere die Tablestruktur und dann schiebe ich die Daten per Batchmove rüber,
das bringt immer 100 - 150 MB ersparnis.

Ich denke das liegt an den Datensätzen die nur einen Flag gelöscht haben oder ?

Da ich jetzt in der Zentral-Datenbank mittlerweile auch Stored Procedures und Generatoren verwende ist das oben genannte Verfahren leider nicht mehr günstig, da diese beim oben genannten Verfahren nicht übernommen werden.

Meine Fragen:

1. Gibt es eine andere Lösung die Datenbank zu packen/optimieren ?

2. Wie must die Syntax lauten wenn ich mit meinem Programm per SQL eine SP anlegen will ? bei "SET Term ^" meckert der immer schon.

3. Wie lautet bei Firebird die SQL Syntax um zusätzliche Indizies auf bestimmte Tabellen anzulegen ? <---- Hat sich erledigt !

Thx & Greetz DataCool

[Neumann]

Hallo,

zu 1.
Man kann einfach die Datenbank sichern und wieder zurücksichern. Wenn die Datenbank wächst, ist das noch nicht unbedingt ein Problem; es sollte reichen wenn man das ab und zu macht (1*Woche oder Monat).

2.
Set Term braucht man da nicht, einfach die Befehle mit ; abschliessen. Beispiel:

IBSQLUpdate.SQL.Add('CREATE TRIGGER BUCHUNGEN_BI FOR BUCHUNGEN');
IBSQLUpdate.SQL.Add(' ACTIVE BEFORE INSERT POSITION 0 AS ');
IBSQLUpdate.SQL.Add(' BEGIN ');
IBSQLUpdate.SQL.Add(' IF (NEW.BUCH_NR IS NULL) THEN ');
IBSQLUpdate.SQL.Add(' NEW.BUCH_NR = GEN_ID(GEN_BUCHUNG,1); ');
IBSQLUpdate.SQL.Add(' END ');

3. Geht auch einfach, Beispiel:
CREATE INDEX ABUCHUNGEN_IDX1
ON ABUCHUNGEN (BUCH_NR)

Indiziert wird Feld Buch_Nr in Tabelle ABuchungen. Der Effekt ist aber oft nicht so riesig, da Firebird selbst die Abfragen schon optimiert.

Gruß

Ralf

[Elvis]

Das "Schrumpfen" einer fdb sollte normal nicht nötig sein.
Die Datei wird im Betrieb immer wachsen, aber nie von selbst schrumpfen.
Warum? Nun, wenn sie größer werden muss, dann muss sie halt wachsen. Aber wenn sie einmal diese Größe hatte ist es nur wahrscheinlich, dass sie wieder wachsen wird. Warum sollte der Server also sinnlos Zeit verschwenden und die FDB zu einer kleineren Datei kopieren? ;)
Das hat nicht viel mit Optimierungen zu tun, in etwa soviel wie Spoiler an eine Familienkutsche wie einen Golf zu klatschen. :mrgreen:

[hoika]

Hallo,

noch mal zu leere Tabelle und rüberkopieren.
Keiner verhindert, dass deine leere DB die Trigger und SP's
nicht schon enthält.

Ich würde das aber trotzdem nicht machen,
siehe die Postings obendrüber.


Heiko

[DataCool]

Hi,

@Hoika:

Genau das habe ich ja vor, bevor ich die Daten rüber kopiere die SPs, Generatoren und Indizies neu anzulegen.
Aber wie unter Frage 2 beschrieben hatte ich damit ja so meine Probleme, werde gleich nochmal die beschriebenen Lösungen testen.
Wenn's damit klappt ist alles gut ;-)

Zum Sinn und Unsinn dieser Methode lässt sich streiten, klar wird eine DB nicht von alleine kleiner !
Aber bei den Daten die von den Clients kommen(ca. 100 Stück) sind sehr sehr viele Datensätze logisch gelöscht.
Und wenn die oben genannte Methode eine Verkleinerung von 450 auf 250 MB bringt,
sollte sich das auch positiv auf die Geschwindigkeit der Datenbank auswirken.
Vor allen Dingen, weil der Server auf dem die Datenbank läuft im moment nur 512 MB RAM hat.

Ich werde die oben genannte Lösung für Frage 2 austesten und berichten,

Thx & Greetz DataCool

[Elvis]

Zitat:

Zitat von DataCool

Und wenn die oben genannte Methode eine Verkleinerung von 450 auf 250 MB bringt,
sollte sich das auch positiv auf die Geschwindigkeit der Datenbank auswirken.
Vor allen Dingen, weil der Server auf dem die Datenbank läuft im moment nur 512 MB RAM hat.

Er hält ja nicht die FDB im Speicher, das würde ihm nix bringen.
Er hält die Daten in aufbereiter Form im Speicher, da sind natürlich keine gelöschten Datensätze dabei. ;)