Firebird Monitoring System

[chros]

Hi,

Wir haben ein Datenbank System entwickelt wo eine Application lokal auf die Firebird Datenbank zugreift und clients über das Netzwerk.

Nun ist es so das wir scheinbar performance probleme haben. Bei mehr als 100 Clients die über einen Zeitraum von mehreren Tagen laufen und permanent in die Datenbank schreiben wird das System immer langsamer, da sich dadurch die Datenbank anfüllt (nur um eine Vorstellung zu haben 5 Tage ca. 700.000 Records pro Table) und die Applikation mit selects (nehmen wir mal an) die Datenbank bremst.

Die Application die auf dem Server Lokal läuft kommuniziert mit Firebird direkt über eine Pipe um die Geschwindigkeit zu erhöhen.

Jetzt suchen wir ein Monitoring system welches sich in diese Pipe reinhängen kann um alle aktionen (select, insert, delete, update) mit zu protokollieren, es reichen auch counter, um aussagekräftige Tests zu machen.

Leider habe ich nach tagelangem suchen kein Programm gefunden welches sowas kann. Es gibt zwar von IBExpert ein tool namens "IBExpert Network Monitor" aber das kann leider nur über die Netzwerk ports mit loggen. Die Application auf das Netzwerk umlegen kommt nicht in Frage da wir das System unter realen Umständen testen müssen.

Ich kann verständlicherweise leider nicht mehr Informationen über das System bereitstellen.

Im Endeffekt benötige ich ein Monitoring System welches die Kommunikation zwischen einer Applikation und einer lokalen Datenbank aufzeichnen/analysieren kann um die Probleme herrauszufinden und die Performance zu optimieren.

Vielleicht hat ja wer von Euch auch schon mal mit so einem Problem zu kämpfen gehabt und weis unter umständen ein solches Tool.

Danke, chros.

[TBx]

Hallo chros!

Über welche Komponenten greift Ihr auf den Firebird zu?

Bei den IBObjects z. B. ist eine Monitoring-Komponente mit dabei, die Du einfach mit der IB_Connection verbinden kannst.

Für die Verlangsamung des Datenbankzugriffs würde ich nicht unbeding die Datenmenge verantwortlich machen.
Ich gehe eher davon aus, daß die Application irgend eine Transaktion nicht wieder schließt.
Guck doch mal über IBExpert nach, wie groß der Unterschied zwischen der nächsten Transaktion und der ältesten aktiven ist.


Hope it helps

onlinekater

[negaH]

Vielleicht das hier http://www.devrace.com/en/sqlhammer/ ?

Gruß Hagen

[sakura]

Dein Problem ist sehr wahrscheinlich nicht die Datenbank an und für sich, sondern Eure Software.

Ich denke mal, dass Ihr offene Transaktionen über einen längeren Zeitraum haltet (z.B. oft in Eingabemasken o.ä.) und die Anwender diese nicht schließen, z.B. Kaffee trinken, Rechner und Software über Nacht laufen lassen, etc.. Dadurch muss die Datenbank alle folgenden Änderungen, neue und gelöschte Records versionieren und mit jeder Abfrage durch alle Versionen "lesen" etc. Das macht jede DB unweigerlich irgendwann langsam. Und das ist in über 98% der Performanzprobleme auch die Ursache. Einfach mal über diesen Ansatz schauen. Wenn ein einfache DB-Neustart das Problem behebt (nicht committete Transaktionen werden verworfen, die Versionen aufgeräumt, etc.), dann ist die Wahrscheinlichkeit noch größer, dass das die Ursache ist.

Das imho beste Tool zum Monitoren ist IB Monitor. Einfache mal die älteste, noch offene Transaktions-ID mit der aktuellsten vergleichen. Entfernen sich diese immer weiter voneinander, dann ist oben genanntes Problem zu 100% die Ursache

......

[negaH]

Wir nutzen beides, IB Monitor und SQLHammer. SQLHammer hat den Vorteil das es mit den FIBPlus Komponenten direkt zusammenarbeitet. Man sieht also im Log auch die Komponetennamen, SQL Parameter usw. vom FIBPlus.
Desweiteren kann man im SQLHammer dieses Log auf einfache Weise durchsuchen und der Log-Text ist farblich, per Syntaxhighlighting hervorgehoben.

Gruß Hagen

[sakura]

Zitat von negaH:

SQLHammer hat den Vorteil das es mit den FIBPlus Komponenten direkt zusammenarbeitet.

Dann muss ich mir den wohl mal anschauen, wenigstens um den kennenzulernen. Danke

......

[chros]

Hi,
danke für die sehr schnellen Antworten.

@ onlinekater:

Zugegriffen wird über die Interbase header files. Das komplette System ist in C++ programmiert.

Die Monitoring Komponente ist meines Wissens nach nur möglich wenn man sie in die Anwendung integriert. Das können wir nachträglich nicht mehr machen, das das System schon draußen ist und wir aus behördlichen Gründen keine geänderten Versionen ausliefern dürfen. Darum brauch ich ein externes tool.

@ negaH:

Danke, ich werde mir das Programm mal ansehen.

@ sakura:
Nein offene Transaktionen können es nicht sein. Die Anwendung welche lokal auf dem DB Server läuft schließt einmal täglich zu einem definierten Zeitpunkt ausnahmslos alle Transaktionen. Außerdem greifen keine "Menschen" auf die Datenbank zu. Es gibt keine Eingabemasken etc. auf den clients, keine ein loggen usw. Im Prinzip sind die clients eigenständige Rechner die gesammelte Daten (Delta Daten) auf die Datenbank absichern, und das mehrmals in der Minute.

Wenn sonst noch jemand Tipps hat ich bin für alles offen und leicht verzeifelt.

Danke, allen Helfern.

Gruß chros

[negaH]

Mit 100 Clients und 700.000 Datensätze in 5 Tagen PRO Tabelle (bei wieviel Tabellen ?) ist schon eine Größenordnung in der ein einzigster SQL Server an seine Grenzen kommen kann (je nach zeitlichem Traffic). Es wäre also interessant für dich über die Scalierbarkeit des Servers nachzudenken, sprich die Last auf mehere Server zu verteilen.
Ein zweiter Tipp wäre die Überprüfung WIE deine SQLs aussehen, sprich habt ihr bewusst die SQL Server Features wie Stored Procedures ausgenutzt oder nutzt ihr über eure SQLs den Server quasi nur als Fileserver ? Sprich: habt ihr Datenbank Intelligenz auf den Server ausgelagert oder machen das immer noch die Clients.

Gruß Hagen

[chros]

Hmm Tables die die Größenordnung erreichen sind ca. 3.

Es werden keine Files gespeichert sondern überwiegend Zahlen und Text.

Ja wir verwenden Stored Procedures, es wird allerdings auch viel von der Lokalen Applikation übernommen.

Im übrigen habe ich dein empfohlenes Programm (SQLHammer) ausprobiert. Leider kann das nur mit IBX oder über FIBPlus arbeiten. Da wir allerdings eine eigene DLL für die Kommunikation verwenden funktioniert das Programm nicht. Eine Änderung der Dll zu einer Debug Version würde lt. den Programmierern zuviel Zeit in Anspruch nehmen. Schade, ist eigentlich ein sehr schönes Programm.

[negaH]

Ihr benutzt eine eigene DLL ? Hm, dann würde ich exakt dort das Problem vermuten. Aus kommerzieller Sicht ist dies aber ziemlich unüblich.

Gruß Hagen