Firebird schließt Verbindungen nicht... 100% CPU last

[Sascha-L]

Guten Tag,

Ich habe folgendes Problem:

Ich habe mehrere Datenbanken auf einem Server liegen, auf diesen Server greifen mehrere PC´s mit jeweils meherern Programmen zu.
Ich benutze Firebird 1.5 und das System läuft auch schon seit mehreren Jahren Stabil, jedoch habe ich seit neustem das Problem, dass Firebird einfach nicht mehr reagiert und kein client mehr auf die Datenbanken zugreifen kann. Auffällig ist hierbei dass der Firebird zu viele offene Verbindungen hat und teilweise eine CPU last von 100% verursacht. Die Programme, die auf die Datenbanken zugreifen wurden mit Delphi 4 Programmiert und verwenden die BDE.

Wenn Probleme während des Zugriffs auf die Datenbank auftreten sollten, werden diese mit einem 'Try - Except' Block abgefangen um Fehler zu vermeiden. Ist es Sinnvoll, den Datenbank aufruf nocheinmal zu versuchen, wenn Fehler aufgetreten sind oder eher nicht ?

Hier ist mal ein Auszug des Delphicodes, der für den Datenbankzugriff zustaändig ist:

Delphi-Quellcode:

Begin
  //H_UnWert := StrToIntDef(Edit1.text,0);
  H_UnWert := StrToIntDef(Edit1.Text,0);
  H_ObWert := StrToIntDef(Edit2.Text,0);
  Query1.DisableControls;
  If DataBase1.InTransaction = False Then DataBase1.StartTransaction;
  Try
   With Query1 Do
    Begin
      Close;
      SQL.Clear;
      HlpStr := 'Select * From ReadAuftragsHeaderIntervall(';
      HlpStr := Concat(HlpStr,IntToStr(H_UnWert),',',IntToStr(H_ObWert),')');
      SQL.Add(HlpStr);
      Active := True;
      DataBase1.Commit;
    End;
  Except
    DataBase1.RollBack;
  End;
  Query1.EnableControls;
End;

Meine Fragen sind nun:

1. Woran könnte es liegen, dass aufeinmal diese Probleme auftreten ?
2. Gibt es ein Tool oder ein Programm mit dem ich herausfinden kann welche(s) Programm(e) die Probleme verursacht ?

Ich hoffe, ihr könnt mir weiterhelfen

MfG Sascha

[Jelly]

Zu 1.
Ich tippe mal auf die BDE...
Prüfe mal, wenn du nicht von der BDE weg kannst/willst, ob du bei Programmende immer schön brav deine Connections schliesst. Vielleicht hilft das (temporär)!

[Sascha-L]

Vielen Dank,

Ich weiß, dass die BDE überholt ist, jedoch bleibt (zumindest im Moment) keine andere Möglichkeit für mich als die BDE zu verwenden.
Bezüglich der nicht geschlossenen Verbindungen, ist dass so eine Sache mit dem kontrollieren, wie gesagt es sind mehrere Programme, dessen Umfang auch nicht gerade gering ist, desswegen fragte ich ja nach einem Tool, dass mir anzeigt welche Clients bzw. Programme die Probleme verursacht. Es würde auch schon reichen, wenn ich wie bei MS SQL (einen Profiler) einfach mitlaufen lassen könnte, was mir jede Aktion mitlogt. Jedoch ist mir soetwas für Firebird nicht bekannt

MfG Sascha

[mkinzler]

Solche tools gibt es schon, z.B. von CRlabs als Teil der IBDAC-Komponenten oder anderen Logmanagern. Die IBDAC-Kompos bieten auch einen Experten welche dir Helfen die BDE abzulösen.

[Sascha-L]

Danke, könnte mir jemand sagen was genau dass für Tools sind, bzw wo ich diese herbekomme, ich möchte hier nochmal ausdrücklich sagen, dass es für mich im Moment keinerlei Möglichkeiten gibt von der BDE wegzukommen, es wäre sehr Hilfreich, wenn Ihr ein paar Links posten könntet.

MfG Sascha

[mkinzler]

Warum kannst du nicht weg von der BDE?
http://crlab.com/ibdac/

http://crlab.com/dbmonitor/download.html
http://www.hk-software.net/h-k.de/Produkte/IBMonitor
http://www.upscene.com/products/audit/iblm_main.htm
...

[Sascha-L]

Ich Arbeite in einem Team an diesem Projekt, denn alleine wäre es unmöglich alle Clients up to date zu halten, also ist der eigendliche Grund nur ein Zeitfaktor, der es mir nicht erlaubt, alle Programme BDEfrei zu machen, aber danke für die Links, ich werde bescheit sagen, sobald ich mehr weiß.


MfG Sascha L.

[mkinzler]

Wie gesagt besitzt IBDAC einen Experten, der dir hilft das Programm von BDE auf IBDAC umzusetzen.

[PaulJr]

Hallo Sascha, :???:

eine Bemerkung zu Deiner Source-Code: :idea:

Eine Transaction hat an dieser Stelle überhaupt kein Sinn. Das Gleiche gilt für Commit.

Ich würde das z.B. so programmieren (einen von sehr vielen Varianten die man an dieser Stelle programmieren könnte):

Delphi-Quellcode:

Begin
   //H_UnWert := StrToIntDef(Edit1.text,0);
   H_UnWert := StrToIntDef(Edit1.Text,0);
   H_ObWert := StrToIntDef(Edit2.Text,0);
   Try
    With Query1 Do
      Begin
         DisableControls;
         if Active then
            Close;
         SQL.Clear;
         HlpStr := 'Select * From ReadAuftragsHeaderIntervall(';
         HlpStr := Concat(HlpStr,IntToStr(H_UnWert),',',IntToStr(H_ObWert),')');
         SQL.Add(HlpStr);
         try
            Open;
         finally
            EnableControls;
         end;
      End;
   Except
      ON E:Exception do
      begin
         EnableControls;
         MessageDlg(E.Message , mtError, [mbOk], 0);
         Sysutils.Abort;
      end;
   End;
End;

Viele Grüße

PaulJr

[hoika]

Halo,

wieso hat eine Transaktion hier keinen Sinn ??

Ohne diese Transaktiomn erzeugt die BDE selbst eine.
Gerade durch diese "manuellen" Transaktionen
erzeugt die BDE nicht bei jeder Aktion selbst eine Transaktion.
OK, hier ist es mal nicht notwendig, schadet aber auch nicht.

Was mich eher stört ist das hier.

Delphi-Quellcode:

If DataBase1.InTransaction = False Then DataBase1.StartTransaction;

Warum ist kann eine Transaktion offen sein ?
Das darf (naja sollte) nicht sein.

Das sieht wie Code aus, wo der Programmierer
manchmal an einer offenen Transaktion vorbeicoden muss.

Und genau diese offenen Transaktionen erzeuge auf dem SQL-Server
immer mehr Last (OAT, OIT).

Ich schreibe das immer so.

Delphi-Quellcode:

DataBase1.StartTransaction;
try
  // query bla
  // ev. auch eine DataBase1.RollBack;
finally
  if DataBase1.InTransaction then DataBase1.Commit;
end;

Heiko

[PaulJr]

Hallo Hoika, :-D
Du muss es wissen… :idea:

Kannst mir bestimmt erklären, wann eine Transaction ein Sinn macht…

Teilweise hast Du schon die Frage beantwortet:

1.) Zum einem immer dort wo Du diese anwendest…, bzw. Dort wo 50 Leute auf einmal auf eine Datenbank zugreifen… mit z.B. 200 SQL-Tabellen und x-Millionen Datensätze…

Na ja, aber dann kommt, hab natürlich vergessen, dass was Du immer programmierst:

Ein RollBack ! :shock:

Denn mache ich jetzt auch :mrgreen:

Viele Grüße

Paul Jr.

[hoika]

Hm... ;)

also da hast du was missverstanden.

1.
Unter IB/FB (und in jedem vernünftigen DBMS) wird jede
DB-Aktion (Insert/Update/Delete)
im Rahmen einer Transaktion bearbeitet.

2.
Die Bde kennt einen Mechanismus namens "AutoCommit!
Jede DB-Aktion wird in ein StartTransaktion/Commit gepackt,
ob man das will oder nicht.
Ausnahme siehe 3.

3.
Stösst man eine Transaktion manuell (DataBase.StartTransaction)
kann man mehrere DB-Aktionen durchführen ohne das Commit.
Erst durch das manuelle Anstossen sind überhaupt Sachen wie

2 DB-Aktionen müssen klappen, wenn eine der Aktionen fehlschlägt, vergiss alle Aktionen

mit der BDE überhaupt möglich.

Positiver Nebeneffekt ist eine höhere Geschwindigkeit ...


Alle bisherigen Angaben haben erst mal nichts damit zu tun,
wie viele Clients (sagen wir mal Rechner) auf die DB zugreifen,
wir reden erst mal nur von einem Client.


Was dein Satz 50 Benutzer und Transaktion gemein haben,
verstehe ich gerade nicht ;)
Ist ja auch schon spät...


Nun du dem "was du immer programmierst ;)"
Ich versuche, keine Transaktion auf dem Server offen zu haben,
wenn der Client nichts zu tun hat.

Delphi-Quellcode:

if not DataBase.InTransaction then DataBase.StartTransaction

heisst für mich, der Programmierer weiss nicht, ob ein Transaktion offen ist oder nicht.
Und genau da ist das Problem.

Eine offene Transaktion, vielleicht noch in einem Form, was auf Nutzereingaben wartet,
heisst für IB/FB einen Riesenaufwand betreiben (MGA).

Das beste wäre ja, für verschiedene Arbeiten (Tabellen oder Funktionsgruppen) eigene Transaktionen
zu verwenden, aber das und BDE ;( geht nicht.


Es hilft also nur,

1. BDE wech ;) (bin gerade dabei)


2. Mit der BDE noch ein bissel leben (argzzz)
dann keine Transaktionen offen halten

Man müsste dazu sogar mal nen

Delphi-Quellcode:

   Assert(DataBase1.InTransaction=False)

vor dem StartTransaction-Code setzen,
um die Stellen zu finden, wo die Transaktion noch offen ist.



Heiko

[PaulJr]

Hallo Hoika, :???:

ja, dass ist eine klare, korrekte Antwort die ich auch akzeptiere. :hello:

Aber diese Aussage von Dir:
(…)
OK, hier ist es mal nicht notwendig, schadet aber auch nicht. :shock:
(…)

kann wirklich einen zukünftigen Programmier in die Ire führen, da was bedeutet schon „schadet aber auch nicht.“
Natürlich so was schadet und zwar gewaltig, da schlechte Angewohnheiten sind später nur schwer bekämpfbar.
Darüber hinaus, man sieht das schon auf den ersten Blick, dass hier, was das Ablauf-Verständnis betrifft noch Nachholbedarf herrscht.

Bewirb sich also ein Programmierer um eine Arbeitsstelle und liefert so etwas an Source-Code
hat er bei 90% Software-Firmen gar keine Chance.

Also, ein guter Programmierer (und Du gehörst mit Sicherheit auch dazu :coder: ) sollte hier nicht nur bei Problemen helfen sondern auch, was nicht zu unterschätzen ist: zum gutem Programmierstil verhelfen.


Viele Grüße

Paul Jr.

[hoika]

Hallo,

nun, auf das Posting bekommst du von mir mal 100%, aaach 101 % ;)


Heiko

[Sascha-L]

Vielen Dank an euch, ich werde mich in nächster Zeit mal mit meinem Kollegen zusammensetzen und ihm eure Vorschläge vorstellen, finde Nett, dass ihr euch um meinen Programmierstil kümmert, bin halt noch relativ neu, und auch dieses Projekt ist ziemlich neu für mich.

Falls euch noch andere Sachen einfallen würden, wodurch dieses Problem entstehen kann, wäre ich euch sehr Dankbar für eure Posts und Lösungsvorschläge.

Also :thumb: vielen Dank


MfG

Sascha