Ausführung einer StoredProcedure sehr langsam

[Gor1]

Hallo,

ich habe in meiner Firebird-Datenbank eine StoredProcedure, die für die Ausführung z.B. in FlameRobin knapp zwei Sekunden benötigt. Wenn ich diese StoredProcedure aber aus Delphi heraus über DBExpress aufrufe, dann benötigt das ExecSQL 16 Sekunden (wenn ich Firebird Embedded benutze sogar 27 Sekunden).
Ich habe auch versucht, das nicht mit einer StoredProcedure sondern direkt als SQL-Befehl zu machen, aber mit dem gleichen Ergebnis.
Die StoredProcedure führt folgenden SQL-Befehl aus:
DELETE FROM TABELLE1 WHERE PARAM1 NOT IN (SELECT DISTINCT PARAM1 FROM TABELLE2)
Ich habe auch schon versucht, das DISTINCT durch ein GROUP BY zu ersetzen, aber das hat auch nichts gebracht.

Hat einer eine Idee, was ich da noch probieren könnte?

Schöne Grüße,
Georg

[Iwo Asnet]

Sind die 2 Sekunden in Flamerobin mit oder ohne Commit?

Dessenungeachtet ist eine der Schwächen von Firebird das Löschen von Datensätzen (DELETE).
Das ist leider langsam.

[Blup]

Ohne Kenntnis der Tabellenstruktur (insbesondere welchen Index es gibt) und ohne Kenntnis über die Daten ist es schwierig, Hinweise zur Optimierung zu geben.
Ich gehe davon aus, es existiert zumindest für Param1 in beiden Tabellen ein Index, aber Param1 ist in beiden Tabellen nicht eindeutig.

Code:

/* Liste aller Param1 in Tabelle1 durchgehen */
for select distinct param1
from       tabelle1
into       :param1
do begin
  /* ist dieser Param1 mindestens einmal in Tabelle2 enthalten */
  p = null;
  select param1 from tabelle2 where param1 = :param1 rows 1 into :p;
  if (p is null) then
  begin
    delete from tabelle1 where param1 = :param1;
  end
end

Falls Rows in deinem SQL-Dialekt nicht existiert, gibt es zumindest ein gleichwertiges Schlüsselwort.

[DeddyH]

Ginge es nicht auch so?

SQL-Code:

DELETE FROM 
  TABELLE1 
WHERE 
  NOT EXISTS(
    SELECT 
      * 
    FROM 
      TABELLE2
    WHERE
      TABELLE2.PARAM1 = TABELLE1.PARAM1
  )

[Gor1]

Zitat von Iwo Asnet:

Sind die 2 Sekunden in Flamerobin mit oder ohne Commit?

Dessenungeachtet ist eine der Schwächen von Firebird das Löschen von Datensätzen (DELETE).
Das ist leider langsam.

Die 2 Sekunden sind ohne Commit, allerdings braucht der Commit auch nur einen Bruchteil einer Sekunde.

Ich habe auch mal versucht, das DELETE durch ein SELECT PARAM1 zu ersetzen (so dass ich nur die zu löschenden Zeilen bekomme), auch diese SQL-Abfrage ist praktisch genauso langsam wie das ursprüngliche DELETE.

Deshalb habe ich die gesamte Abfrage in einzelne Teile zerlegt und den Vergleich ob der Parameter in der anderen Tabelle vorhanden ist in Delphi gemacht. Damit komme ich dann auf eine Ausführungszeit ähnlich wie beim Ausführen über Flamerobin, allerdings ist das natürlich keine sehr elegante Lösung.

Danke an alle für eure Vorschläge, ich werde sie mal ausprobieren.

[Gor1]

Zitat von DeddyH:

Ginge es nicht auch so?

SQL-Code:

DELETE FROM 
  TABELLE1 
WHERE 
  NOT EXISTS(
    SELECT 
      * 
    FROM 
      TABELLE2
    WHERE
      TABELLE2.PARAM1 = TABELLE1.PARAM1
  )

Danke für diesen Tip. Ich denke, dass das auch das gewünschte Ergebnis liefern würde. Diese Variante ist auch schon mal doppelt so schnell wie meine ursprüngliche, allerdings halt immer noch deutlich langsamer als mit Flamerobin.

[Gor1]

Zitat von Blup:

Ohne Kenntnis der Tabellenstruktur (insbesondere welchen Index es gibt) und ohne Kenntnis über die Daten ist es schwierig, Hinweise zur Optimierung zu geben.
Ich gehe davon aus, es existiert zumindest für Param1 in beiden Tabellen ein Index, aber Param1 ist in beiden Tabellen nicht eindeutig.

Code:

/* Liste aller Param1 in Tabelle1 durchgehen */
...

Falls Rows in deinem SQL-Dialekt nicht existiert, gibt es zumindest ein gleichwertiges Schlüsselwort.

Ich habe deinen Code mal in einer StoredProcedure ausprobiert, damit geht es deutlich schneller. Allerdings gibt es Fälle, in denen grosse Teile der Tabelle1 gelöscht werden und dabei ist diese Variante nicht so schnell (ich nehme an, weil für jede zu löschende Zeile ein DELETE aufgerufen wird).

[tsteinmaurer]

Und du bist dir sicher, dass du in allen Fällen dich zur selben Datenbank verbindest, d.h. für alle Fälle das Datengerüst identisch ist.

[Gor1]

Zitat von tsteinmaurer:

Und du bist dir sicher, dass du in allen Fällen dich zur selben Datenbank verbindest, d.h. für alle Fälle das Datengerüst identisch ist.

Ja, bin ich. Ich habe die Ausführungszeit für die verschiedenen Möglichkeiten auch mehrmals gemessen (in meinem Delphi-Programm). Da die Ausführung nur im Delphi-Programm so langsam ist (aber nicht in Flamerobin) vermute ich, dass das Problem irgendwo in Delphi bzw. den DBExpress-Treibern liegt und nicht in der Firebird-Datenbank. Momentan verwende ich Delphi 2009 mit dem dbxFirebird-Treiber.
Ich werde bei Gelegenheit auch mal andere Zugriffskomponenten ausprobieren oder auch DBExpress mit einer neueren Delphi-Version. Ich bin mal gespannt, ob sich da das gleiche Verhalten zeigt.

[FredlFesl]

Das kann doch aber nicht sein, das ein Treiber 14 Sekunden benötigt.

Nachdem ich schon ein paar dämliche Fragen gestellt habe, hier noch eine:

Du bist dir sicher, das das Ergebnis reproduzierbar ist? Ich frag deshalb, weil ja theoretisch erst in Delphi gemessen wurde und danach in Flamerobin, wo dann aber die DB-Engine schon ihren Cache gefüllt hat und so die Zugriffe viel schneller gehen...

Also ich hab sonst keine Erklärung für diesen Quark.

Ich hatte das mal mit MSSQL, aber da war es die Namensauflösung, die 30 Sek gedauert hat, weil irgendwas im Netz im Eimer war, irgend eine Einstellung. Vielleicht geht Flamerobin ja nicht über TCP, aber dbExpress...