Ausführungsgeschwindigkeit von einer Stored proc

[p80286]

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

Gruß
K-H

[jobo]

Zitat von MyRealName:

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 von MyRealName:

Zitat von p80286:

Zitat von MyRealName:

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 von MyRealName:

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 von 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

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.