Ausführungsgeschwindigkeit von einer Stored proc

[MyRealName]

Hallo,

ich habe eine Datenbank bei einem Kunden mit Firebird und einem Haufen Daten (DB ist so 3.5 GB gross). Der Kunde sagt, manchmal dauert das Ausführen von einer Stored proc um eine Rechnung zu bearbeiten so 20-25 Minuten. Wenn ich diese DB auf meinen Server (ähnliche Geschwidigkeit) kopiere und dort diese Proc ausführe, dann läuft das in unter 2 sekunden.
Der Unterscheid, den ich sehe ist das ich allein auf meinem Server arbeite, er hat so 40 Nutzer die Remote mit der DB über unsere Anwendung verbunden sind.

Gibt es Ideen, wie man das verbessern kann oder auf was man achten muss, damit es mit den 40 Nutzern schneller läuft ? SuperServer vs. Classic Server etc.

Danke schonmal
Helge

[haentschman]

Hallöle...:P

Zitat:

ich habe eine Datenbank bei einem Kunden mit Firebird und einem Haufen Daten (DB ist so 3.5 GB gross).

Zitat:

Der Kunde sagt, manchmal dauert das Ausführen von einer Stored proc um eine Rechnung zu bearbeiten so 20-25 Minuten.

...kann das sein das dir das Sweep einen Streich spielt? :gruebel:
Ich habe eine DB mit einem halben GB aber mit haufenweise Inserts üblicherweise 24/365 Laufzeit. Wenn alle Clienten von der DB getrennt sind und der erste sich wieder anmeldet, dann kann es durchaus dauern bis die DB wieder "reagiert". :?

[jsheyer]

Hallo,

selbst ein sweep würde das bei der Größe eigentlich erklären, ich habe Datenbank mit 300 GB, hier habe ich das sweep zwar auf 0 gesetzt und startet es zu einer Zeit wo weniger eingeloggt sind.
Hier kann es verschiedene Gründe geben, Transaktionen die die Ausführung blocken, wenn es Remote ist, zu große Rückgabe Mengen an Daten.
Nicht optimierte Queries innerhalb der SP.
Um mal ein paar zu nennen.
forced writes?
Schon mal ins firebird.log nachgesehen ob da war drin steht?

[hoika]

Hallo,

Zitat:

Der Kunde sagt, manchmal dauert das Ausführen von einer Stored proc um eine Rechnung zu bearbeiten so 20-25 Minuten.

Checkliste:
Wann passiert das (Datum/Uhrzeit) -> Abgleich mit eigenen Log und / oder den FB-Logs.
Was genau bedeutet "Bearbeiten"?

eigenes Log =
schreibe relevante Sachen in eine eigene Log-Datei mit Zeitstempel
ohne Bezüge zu realen Daten (Kundenname usw.)

Sweep auf 0 und manuell starten wurde ja bereits gesagt.

(Super)-Classic bei 40 Clients ist vielleicht besser als SuperServer -> Ausprobieren

Dann fällt mir auch noch ein, dem Server eine SSD zu verpassen, zumindestens als Datenplatte.

[MyRealName]

Der Kunde macht angeblich 1x pro Woche Backup/Restore, das sollte ja ein Sweep mit drin haben.

Bearbeiten heisst, dass Waren-Bewegungen in das Invetar eingetragen werden, verbundene Dokumente aktualisiert (Zum Beispiel die Bestellung wird von der Rechnung darüber informiert, wieviel von der Bestellung wurde schon abgerechnet. Dann cartera (da steht drin für welche Rechnung der Kunde mir noch was schuldet und welche Rechnung er mit welchem Geldeingang bezahlt hat) und Buchhaltung (wo Steuer etc registriert wird).

Wie gesagt, die gleiche DB macht das bei mir in unter 2 Sekunden, was annehmbar ist.

Die Verbindung ist übrigends NO_WAIT, soltle also sofort ein Fehler bei einem Lock conflict bringen und es sollte keine Wartezeit geben

[nahpets]

Hatte vor kurzem mal eine extrem langsame FireBird-Datenbank, kaum ein GB groß.

Habe dann mal geschaut und musste feststellen, dass der Virenscanner auch die Datenbankdatei dauernd überprüfte.
Nachdem ich dem dann beigebracht habe, dass er das Verzeichnis, in dem die Datenbankdatei liegt, doch bitte ungeprüft lassen möge, wurden die Geschwindigkeiten wieder akzeptabel.

Bei Windowsrechner kann es (nach wie vor) zuweilen hilfreich sein, die Festplatten mal zu defragmentieren. Dazu nutze ich MyDefrag, da man es recht umfangreich konfigurieren kann.

Es scheint hilfreich zu sein, wenn die Datenbankdatei "am Stück" vorliegt. Ist sie zu stark fragmentiert, scheint das doch die Zugriffszeiten der Festplatten zu erhöhen.

Ob aber in einem so extemen Maße, wie im Eingangspost beschrieben, wage ich zu bezweifeln.

[hoika]

Hallo,

Ein Lock conflict würde sofort zum Abbruch, und nicht zur Verlangsamung führen.

Zitat:

Der Kunde macht angeblich 1x pro Woche Backup/Restore, das sollte ja ein Sweep mit drin haben.

Die ist schon bewusst, dass der Sweep alle 10.000 (?) Transaktionen trotz Backup/Restore durchgeführt wirdm, von dem Client, der "gerade dran ist", also die 10.0000 Transaktion erwischt hat.
Dass läßt sich nur ändern, wenn der (wie oben beschrieben) Sweep-Intervall auf 0 gesetzt wird.

Es kann sein, dass es daran liegt, OK, ausprobieren,
ich glaube es eher nicht (Wahrscheinlichkeit 1/10.000).

SSD ist auf jeden Fall nicht verkehrt.

[hoika]

Hallo,

Zitat:

Es scheint hilfreich zu sein, wenn die Datenbankdatei "am Stück" vorliegt. Ist sie zu stark fragmentiert, scheint das doch die Zugriffszeiten der Festplatten zu erhöhen.

Die DB ist intern immer fragmentiert, hier hilft nur ein Backup/Restore.

Aber ein Virenscanner, der ständig die Zugriffe auf die DB-Datei "kontrolliert", ist doof

[p80286]

Zitat:

Zitat von MyRealName (Beitrag 1365508)

Der Kunde sagt, manchmal dauert das Ausführen von einer Stored proc um eine Rechnung zu bearbeiten so 20-25 Minuten. Wenn ich diese DB auf meinen Server (ähnliche Geschwidigkeit) kopiere und dort diese Proc ausführe, dann läuft das in unter 2 sekunden.

Da ist irgendetwas nicht "as designed". Macht er gleichzeitig einen Videoschnitt auf dem Server?
Abgesehen von solchen unwahrscheinlichen(?) Umständen, könnte es sein, daß die Daten morsch sind? 20 Minuten spricht doch eher für konstrukte ala

SQL-Code:

select * 
from tabl11,table2,table3..
where substr(fielda||fieldb,67,3)>'abc'

Falls da mal nicht das Erwartete in den Daten auftaucht könnte es dauern.

Gruß
K-H

[MyRealName]

Zitat:

Zitat von p80286 (Beitrag 1365538)

Zitat:

Zitat von MyRealName (Beitrag 1365508)

Der Kunde sagt, manchmal dauert das Ausführen von einer Stored proc um eine Rechnung zu bearbeiten so 20-25 Minuten. Wenn ich diese DB auf meinen Server (ähnliche Geschwidigkeit) kopiere und dort diese Proc ausführe, dann läuft das in unter 2 sekunden.

Da ist irgendetwas nicht "as designed". Macht er gleichzeitig einen Videoschnitt auf dem Server?
Abgesehen von solchen unwahrscheinlichen(?) Umständen, könnte es sein, daß die Daten morsch sind? 20 Minuten spricht doch eher für konstrukte ala

SQL-Code:

select * 
from tabl11,table2,table3..
where substr(fielda||fieldb,67,3)>'abc'

Falls da mal nicht das Erwartete in den Daten auftaucht könnte es dauern.

Gruß
K-H

Dann würde es doch aber auch auf meinem Server solange dauern, tut es aber nicht :(

[p80286]

Habt ihr denn die selbe Datenbasis?
(wirklich identisch?)

Gruß
K-H

[jobo]

Zitat:

Zitat von MyRealName (Beitrag 1365549)

Dann würde es doch aber auch auf meinem Server solange dauern, tut es aber nicht :(

Äh, die Antwort klingt einerseits gut, andererseits erschreckend.
Bedeutet diese Antwort, dass Du solche (oder vergleichbare) Select Statements in Deiner SP ausführst?

[Ghostwalker]

Zitat:

Zitat von MyRealName (Beitrag 1365549)

Zitat:

Zitat von p80286 (Beitrag 1365538)

Zitat:

Zitat von MyRealName (Beitrag 1365508)

Der Kunde sagt, manchmal dauert das Ausführen von einer Stored proc um eine Rechnung zu bearbeiten so 20-25 Minuten. Wenn ich diese DB auf meinen Server (ähnliche Geschwidigkeit) kopiere und dort diese Proc ausführe, dann läuft das in unter 2 sekunden.

Da ist irgendetwas nicht "as designed". Macht er gleichzeitig einen Videoschnitt auf dem Server?
Abgesehen von solchen unwahrscheinlichen(?) Umständen, könnte es sein, daß die Daten morsch sind? 20 Minuten spricht doch eher für konstrukte ala

SQL-Code:

select * 
from tabl11,table2,table3..
where substr(fielda||fieldb,67,3)>'abc'

Falls da mal nicht das Erwartete in den Daten auftaucht könnte es dauern.

Gruß
K-H

Dann würde es doch aber auch auf meinem Server solange dauern, tut es aber nicht :(

Doch, denn auf deinen Server greifen keine 40 Leute gleichzeitig zu. Mal abgesehen davon, das solche
Statements richtig heftig für die DB sind (und tunlichst vermieden werden sollten !)

[MyRealName]

Mit der Antwort wollte ich nicht sagen, dass wir solche oder ähnliche Statements ausführen, sondern dass es auf unserem Server in derselben DB (direkte Kopie) so schnell geht. Es würde bei 40 Leuten (die andre Sachen machen, diese SP wird nur in einem bestimmten Server-Prozess ausgeführt) ja auch nicht schlimm sein, wenn es statt dessen 10 sekunden oder gar 30 dauert. Aber 20 Minuten ?

Ich habe dem Admin dort Eure bisherigen Hinweise (Antivirus, SuperServer Installtion) übermittelt und mal schaun, ob das die Lage verbessert.

Das mit dem Sweep sollte es nicht sein, da es nachvollziehbar ist mit bestimmten Dokumenten. Nächste Woche macht mein Db-Programmierer mal Timing Tests direkt auf dem Server des Kunden. Mal sehen, was da rauskommt.

[IBExpert]

Auch wenn das schon ein paar Tage her ist:

falls du eine IBExpert Vollversion hast, dann hilft ein blick in services-database monitoring
und eine Trace Session auf dem Server, das ganze aber nur, wenn es bei dem Kunden auch wirklich gerade auftaucht.
Mit einem Blick in die Mon$* Tabellen geht das ggf auch ohne IBExpert, aber die meisten Kunden von uns nutzen dafür Tageslizenzen
direkt auf dem Kundenserver, wenn der gerade meckert.

Wichtig wäre auch die generelle Funktion vom Firebird Server zu checken, du glaubts gar nicht wie lahm manche
Kisten sind, die Kunden da als Server einsetzen (kann man in IBExpert mit dem Benchmark messen, Dateien
schnell kopieren können ist kein Maßstab für Firebird Speed).

Und wenn der Server gleichzeitig Domaincontroller ist, kann das auch daran liegen

Ebenso auch wenn Firebird auf einer VM läuft

Hilfreich sind dafür ggf. simple Infos wie eine Datenbankstatistik, die aber auf dem Kundenrechner
erzeugt werden muss, am besten dann, wenn da ganz normal die Mitarbeiter drauf arbeiten.

Wenn man das ernsthaft auch im Sinne der eigenen Kunden verstehen will, so das Kunden nicht mehr meckern müssen, dann empfehle
ich mal bei uns an einem Bootcamp teilzunehmen. Das sind genau solche Themen ein großer Bestandteil. Morgen in USA, und
im Mai in Wardenburg (deutsch) und Frankfurt (englisch).

gruß

Holger

[hoika]

Hallo,
Backup/Restore kann auch nicht schaden,
das erklärt aber nicht das "ab und zu langsam"

[jobo]

Spannend ist bei solchen Problemen natürlich grundsätzlich, die Ecken zu finden wo die 25 Minuten überhaupt auflaufen.
Ich gehe davon aus, dass die SP, die die Rechnung erstellt, etwas umfangreicher ist und mglw. mehrere Dutzend Abfragen und DML beinhaltet.
Mein Ansatz wäre Logging (generell), administrativ zuschaltbar, ggF. auch in der Tiefe variabel.
Bin mir nicht mehr sicher, aber ist individuelles File Logging aus SP mit FB machbar? Das wäre meine erste Wahl. Ansonsten halt eine Log Tabelle (Das kann seine Tücken haben).
Dann kennst Du wenigstens die exakte Stelle.

Ggf ist dach auch per Monitoring- / Tracetools erreichbar, dazu kenne ich FB viel zu wenig.

[Blup]

Zitat:

Zitat von MyRealName (Beitrag 1365508)

ich habe eine Datenbank bei einem Kunden mit Firebird und einem Haufen Daten (DB ist so 3.5 GB gross). Der Kunde sagt, manchmal dauert das Ausführen von einer "Stored proc" um eine Rechnung zu bearbeiten so 20-25 Minuten. Wenn ich diese DB auf meinen Server (ähnliche Geschwidigkeit) kopiere und dort diese Proc ausführe, dann läuft das in unter 2 sekunden.

Selbst 2 Sekunden erscheinen mir sehr lang um eine Rechnung per "Stored proc" zu erstellen. Wir haben ähnlich große Datenbanken mit bis zu 40 Anwendern teilweise auch auf VMs und beim Rechnungslauf werden per "Stored proc" hunderte oder tausende Rechnungen in wenigen Sekunden erstellt. Hier müsste man mal genauer schaun, welche Pläne bei den einzelnen Selects und Updates verwendet werden und ob es da Schwachstellen gibt. Die Anzahl der Updates, Inserts und Deletes ist auch interessant.

Die andere mögliche Problemstelle sind lange offene Transaktionen und wie viel Speicher durch die anderen Anwender serverseitig dadurch belegt ist. Eine ungünstige Auswertung, die mehrere Tabellen miteinander verknüpft, kann temporär den gesamten Arbeitsspeicher blockieren und damit alle anderen Anwender ausbremsen.

Dann wäre auch noch zu prüfen, ob eventuell andere DB-Server auf der selben Maschine laufen. Der MS-SQL-Server nimmt z.B. schnell mal den ganzen Speicher in Beschlag.

[MyRealName]

Eines der Probleme generell ist auch die Aktualisierung aller verknüpften Tabellen. Zum Bsp Bestellungen, die weiderum Mengenreservierungen haben etc. da lässt es sich nicht umgehen, komplexere Auswertungen zu machen.
Dazu habe ich ja extra eine queue gebaut, wo immer nur ein Dokument bearbeitet wird, da es auch ohne Probleme 5-10 sekunden dauern ohne dass es zu Lock-Konflikten kommt.
Und selbige Stored proc habe ich ja in derselben DB auf meinem Rechner und meinem Server probiert und sie läuft nur 2 Sekunden. Ich kann mir da auch nur vorstellen, dass es Antivirus, Sweeps oder ähnliches ist.

[MyRealName]

Zitat:

Zitat von IBExpert (Beitrag 1365920)

Auch wenn das schon ein paar Tage her ist:

falls du eine IBExpert Vollversion hast, dann hilft ein blick in services-database monitoring
und eine Trace Session auf dem Server, das ganze aber nur, wenn es bei dem Kunden auch wirklich gerade auftaucht.
Mit einem Blick in die Mon$* Tabellen geht das ggf auch ohne IBExpert, aber die meisten Kunden von uns nutzen dafür Tageslizenzen
direkt auf dem Kundenserver, wenn der gerade meckert.

Wichtig wäre auch die generelle Funktion vom Firebird Server zu checken, du glaubts gar nicht wie lahm manche
Kisten sind, die Kunden da als Server einsetzen (kann man in IBExpert mit dem Benchmark messen, Dateien
schnell kopieren können ist kein Maßstab für Firebird Speed).

Und wenn der Server gleichzeitig Domaincontroller ist, kann das auch daran liegen

Ebenso auch wenn Firebird auf einer VM läuft

Hilfreich sind dafür ggf. simple Infos wie eine Datenbankstatistik, die aber auf dem Kundenrechner
erzeugt werden muss, am besten dann, wenn da ganz normal die Mitarbeiter drauf arbeiten.

Wenn man das ernsthaft auch im Sinne der eigenen Kunden verstehen will, so das Kunden nicht mehr meckern müssen, dann empfehle
ich mal bei uns an einem Bootcamp teilzunehmen. Das sind genau solche Themen ein großer Bestandteil. Morgen in USA, und
im Mai in Wardenburg (deutsch) und Frankfurt (englisch).

gruß

Holger

Vielen Dank, aber leider sind die Ibexpert Preise hier in Südamerika leider etwas zu hoch. Ich hab teilweise schon drüber nachgedacht, mir persönlich eine Lizenz zu kaufen, aber mein Súdamerikanischer Lohn gibt das nicht soo einfach her.