Firebird schaukelt sich hoch

[Harald Lietz]

Hallo,

wir haben immer wieder Probleme mit der Speicherauslastung des Firebird. Wir benutzen die IBX-Komponenten in Delphi für den Zugriff. Wir stellen fest, dass sich der Firebird, je länger das Programm läuft "hochschaukelt". Selbst folgender einfacher Ablauf bewirkt, dass die Speicherauslastung immer größer wird.


if not IBT2.InTransaction then IBT2.StartTransaction;
try

IBQ_ARCHIV.Open;
While not IBQ_ARCHIV.eof do
begin

IBT_ARCHIV.Append;

... Zuweisen Felder

IBT_ARCHIV.Post;
IBQ_ARCHIV.Next;
end;

IBQ_ARCHIV.Close;
if IBT2.InTransaction then IBT2.Commit;
Except
if IBT2.InTransaction then IBT2.Rollback;
end;

Wir haben schon mit verschiedenen Varianten beim DB-Zugriff gearbeitet (IBTable, IBDataset usw). Jedoch mit wenig Erfolg.

Wo müssen wir ansetzen, um das Problem lösen zu können ?

[Markus Kinzler]

Ich würde das Programm nocheinmal überprüfen, es scheint hängende Transaktionen zu erzeugen.
Ich vermute mal IBT2.InTransaction nicht richtig arbeitet

[Thomas Steinmaurer]

Hallo Harald,

wie groß ist denn die Datenmenge die hinter IBQ_ARCHIV liegt?

Wenn ein drüberiterieren wirklich notwendig ist (und z.B. nicht in einem INSERT INTO erledigt werden kann), dann wird dir das setzen von Unidirectional = True der IBQ_ARCHIV Komponente etwas bringen.

Ich würde aber versuchen diese Einfügeoperation mit einem INSERT INTO ... SELECT ... FROM ... zu erledigen, sofern in der jetzigen Schleife keine Logik enthalten ist, die nicht mit reinem SQL erledigt werden kann.

Thomas

[Harald Lietz]

Hallo Thomas,

leider kann ich nicht mit INSERT INTO.. SELECT FROM.. arbeiten, zumal es da doch eine Logik gibt. Zusätzlich handelt es sich um zwei Datenbanken. Es sollen Daten aus einer DB in eine andere DB kopiert (archiviert) werden. Die Datenmenge von IBQ_ARCHIV kann schon einige 10000 Datensätze enthalten. Ich werde die Transaktionen nochmal überprüfen. Für jeden Hinweis diesbezüglich bin ich dankbar. Übrigens wächst nicht nur die Speichernutzung des Firebird , sondern auch die des Programmes.

[Thomas Steinmaurer]

Hallo,

dann versuch wirklich mal Unidirectional der TIBDatabase / TIBQuery Komponente auf True zu setzen.

Thomas

[Harald Lietz]

Hallo Thomas,

Unidirectional=true bewirkt nur dass die Speichernutzung meine Applikation konstant bliebt. Ich habe mal die o.g. Ablauf dahin verändert, dass eine einfach While.. do Schleife mit IBQ_ARCHIV durchlaufen wird. Selbst dabei erhöht sich die Speichernutzung der fbserver.exe. Kann dass vieleicht doch mit den IBX-Komponenten zu tun haben ?

[Sven Jehmlich]

Hallo Harald,

ich hatte Gestern das gleiche Problem. Wie Du es beschrieben hast schaukelt sich der Speicher des SQL-Servers nach oben. Selbst ein Commit hat den Speicher im Server nicht aufgeräumt.
Erst ein schliessen aller Queries und ein Unprepare aller Queries die in der Transaktion (der Zieldatenbank) benötigt werden, gab den Speicher wieder frei.

Ich habe mir eine kleine Aufräumfunktion gebastelt, die den Speicher nach einer gewissen Anzahl von Datensätzen wieder frei gibt. Sie funktioniert aber nur wenn Du Deine Transaktion zwischendurch commiten kannst.

Wenn Du Interesse hast, gib mir einfach Bescheid.

Sven

[Harald Lietz]

Danke, ich habe selbstverständlich Interesse.

[swen.cramer]

Hallo Harald,

diese Problem hatten wir auch mit den DBX-Komponenten. Nach jedem Select blieb etwas Speicher belegt. Konnte man prima in einer Schleife testen. Irgendwie hängt das mit implizieten Transaktionen zusammen. Wir habe es gelöst, in dem wir jedes Select und ExecSQL in eine Transaktion eingeschlossen haben. Seit dem Tage läuft unser Programm gut.

Swen

[Henri van de Velde]

if not IBT2.InTransaction then IBT2.StartTransaction;
try

IBQ_ARCHIV.Open;
While not IBQ_ARCHIV.eof do
begin

IBT_ARCHIV.Append;

... Zuweisen Felder

IBT_ARCHIV.Post;
IBQ_ARCHIV.Next;
end;

IBQ_ARCHIV.Close;
if IBT2.InTransaction then IBT2.Commit;
Except
if IBT2.InTransaction then IBT2.Rollback;
end;

Im C++Builder, der die gleichen IBX-Komponenten benutzt funktioniert das ganze so, ohne Speicher zu fressen

   try {

      IBQ_ARCHIV->Active = true;
      IBQ_ARCHIV->First();

      while (!IBQ_ARCHIV.Eof)
      {
          IBT_ARCHIV->Insert();

... Zuweisen Felder

          IBT_ARCHIV->Post ();
          IBQ_ARCHIV->Next();
       }

       IBQ_ARCHIV->Active = false;;
       if (IBT2->Active == true)
          IBT2->Commit();
   }
   catch (...)
   {
       if (IBT2->Active == true)
          IBT2->Rollback();
   }

Allerdings sieht dieses Codeschnippsel nach einer StoredProc direkt in der datenbank aus :

insert into OPERL (LfdNr,Kndnr,BelegNr,belegart,belegdat,belegtext,zusatz,gehoertzu,buchdat,konto,
                   ausgleichsbeleg, ausgleichsdatum,sh,waehrung,undo,
                   buchungsbetrag,soll,haben,skonto,basis1,basis2)
select  LfdNr,Kndnr,BelegNr,belegart,belegdat,belegtext,zusatz,gehoertzu,buchdat,konto,
                   ausgleichsbeleg, ausgleichsdatum,sh,waehrung,undo,
                   buchungsbetrag,soll,haben,skonto,basis1,basis2
  from OP
  where Ausgleichsbeleg > 0 and gehoertzu = :Wer;

[Harald Lietz]

Hallo Henri,

ich kann bei deinem C++ Beispiel keinen Unterschied erkennen. Was ist da anders, damit der Firebird-Server sich nicht hochschaukelt ?

MfG Harald

[Henri van de Velde]

Also ich mache das in meinen z.T. recht umfangreichen Programmen so, und bei mir schaukelt sich der Server eben nicht hoch. Wann immer es geht, benutze ich StoredProcs, die belasten das Netzwerk nicht.

Ausserdem benutze ich, soweit es geht, für jede Abfrage eigene Transactionen.

[Harald Lietz]

Hallo Henri, ich muss nochmal nerven. Selbstverständlich benutze ich, soweit es sinvoll und möglich ist, StoredProcs. Ausserdem packe ich alle Abfragen ebenfalls in eigene Transactionen. Der einzige Unterschied in deinem o.g. Beispiel ist, dass du keine Transaction explizit startest. Ansonsten sind die Beispiele identisch. Die Frage bleibt also.. Was verursacht bei meinem Beispiel die Speicherlast des Firebird ?

[Feinfinger]

Ich hatte vor einem Jahr mit dem Borland C++ Builder das gleiche Problem das sich der Firebird server ständig vergrößerte und immer träger wurde. Ich hatte mich in meiner Verzweiflung sogar an die Entwickler vom IB-Expert gewendet mit einem einzigen Ergebniss : Finger weg von den Borland Interbase Komponenten !!!!!!! Wenn dann würde ich es vielleicht mal mit den IB Object Komponenten versuchen.

[Markus Kinzler]

Oder CRlabs IBDAC, FIBplus, Zeos, ...
IBX sind für Interbase optimiert.