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 :(