Abfrage dauert zu lange unter Delphi

[tsteinmaurer]

@Dumpfbacke:

Zitat:

Was ist ein Ausführungsplan ?

Hmm, wenn du fragst was ein Ausführungsplan ist, dann stellt sich für mich die frage, ab welchem KnowHow-Level sollen wir jetzt Firebird-seitig ansetzen? Der Ausführungsplan ist quasi das Navi für den Optimizer wie die Abfrage zu den angeforderten Daten kommt. Du hast sicher irgendein Tool zur DB-Entwicklung im Einsatz. Mach in einem SQL Editor einfach mal ein Prepare deiner Abfrage da sollte das Tool dann in der Regel irgendwo den PLAN auspucken.

Wenn du die Abfrage auch tatsächlich ausführst, dann sollte auch die Information wieviele Indexed/Non-Indexed Reads etc. durchgeführt wurden.

Zitat:

Page buffers 0 in gstat

D.h. bei (Super)Classic default 75 pages fürn Cache, sofern in firebird.conf der Defaultwert nicht erhöht wurde, von dem ich mal nicht ausgehe. Ich würd sonst mal Tests für dieses Setting mit 1024 bzw. 2048 machen. Gesetzt kann das mit dem Tool deiner Wahl oder gfix werden. Wieviele max. Connections hast du auf die DB und wieviel RAM die Maschine mit dem Firebird Server?

Zitat:

Anazhl > 3,7 Millionen und Rurückgeliefert werden zwischen 0 und 50

Eigentlich ein perfektes Szenario für einen Index, da die Ergebnismenge nur einen Bruchteil der Ausgangsmenge darstellt.

@Sir Rufo:
Grundsätzlich ja, aber hier meiner Meinung totaler Overkill. Da ist dann die Frage der Aktualität des Caches, der Invalidierung etc. Der Firebird Page Cache + OS File Cache reicht hier in der Regel aus.

[Dumpfbacke]

Zitat:

Hmm, wenn du fragst was ein Ausführungsplan ist, dann stellt sich für mich die frage, ab welchem KnowHow-Level sollen wir jetzt Firebird-seitig ansetzen? Der Ausführungsplan ist quasi das Navi für den Optimizer wie die Abfrage zu den angeforderten Daten kommt. Du hast sicher irgendein Tool zur DB-Entwicklung im Einsatz. Mach in einem SQL Editor einfach mal ein Prepare deiner Abfrage da sollte das Tool dann in der Regel irgendwo den PLAN auspucken.

Wenn du die Abfrage auch tatsächlich ausführst, dann sollte auch die Information wieviele Indexed/Non-Indexed Reads etc. durchgeführt wurden.

Nein alles klar ich habe nur den Begriff nicht gekannt.

Es sieht jetzt anders aus da ich ja ein Index auf ein neues Feld gesetzt habe damit ich die Auswahl schon mal sehr weit veringern konnte.

Plan
PLAN (Material INDEX (IDX_Material_STANDARDARBEITSAUFT))

------ Performance info ------
Prepare time = 21ms
Execute time = 2s 553ms
Avg fetch time = 150,18 ms
Current memory = 173.919.496
Max memory = 181.610.688
Memory buffers = 10.240
Reads from disk to cache = 26.893
Writes from cache to disk = 0
Fetches from cache = 146.993

Zitat:

D.h. bei (Super)Classic default 75 pages fürn Cache, sofern in firebird.conf der Defaultwert nicht erhöht wurde, von dem ich mal nicht ausgehe. Ich würd sonst mal Tests für dieses Setting mit 1024 bzw. 2048 machen. Gesetzt kann das mit dem Tool deiner Wahl oder gfix werden. Wieviele max. Connections hast du auf die DB und wieviel RAM die Maschine mit dem Firebird Server?

Sollte eigentlich gesetzt sein.

Daten aus der Conf
# Number of cached database pages
#
# This sets the number of pages from any one database that can be held
# in cache at once. If you increase this value, the engine will
# allocate more pages to the cache for every database. By default, the
# SuperServer allocates 2048 pages for each database and the classic
# allocates 75 pages per client connection per database.
#
# Type: integer
#

DefaultDbCachePages = 1024

Auf diese DB greifen nicht viele zu. Es sind 3 Stück und Ram hat die Kiste so 6 GB

[tsteinmaurer]

Naja, eigentlich wäre der PLAN von deinem Originalstatement interessant gewesen. Das Statement unten dauert jetzt < 3 Sekunden d.h. was passiert jetzt mit dem Rest der von dir zuletzt genannten 10 Minuten?

[Dumpfbacke]

Zitat von tsteinmaurer:

Naja, eigentlich wäre der PLAN von deinem Originalstatement interessant gewesen. Das Statement unten dauert jetzt < 3 Sekunden d.h. was passiert jetzt mit dem Rest der von dir zuletzt genannten 10 Minuten?

Kein Problem habe ich schnell mal erzeugt.

Plan
PLAN (Material INDEX (IDX_Material_Eingang))

------ Performance info ------
Prepare time = 10ms
Execute time = 6m 26s 316ms
Current memory = 174.484.452
Max memory = 181.610.688
Memory buffers = 10.240
Reads from disk to cache = 104.184
Writes from cache to disk = 0
Fetches from cache = 1.544.588

Das Programm steuert ein anderes Programm da ich handarbeit nicht mag. Hierzu wird die Zeit benötigt.

[tsteinmaurer]

Puh, ja, die Ausführungszeit und I/O zeigt eigentlich schön den Unterschied. Indexed vs. Non-Indexed Reads für beide Fälle sollte das nochmal verdeutlichen, aber ich denke die Performance ist jetzt Ok oder brauchst du noch Hilfe?

[Dumpfbacke]

Zitat von tsteinmaurer:

Puh, ja, die Ausführungszeit und I/O zeigt eigentlich schön den Unterschied. Indexed vs. Non-Indexed Reads für beide Fälle sollte das nochmal verdeutlichen, aber ich denke die Performance ist jetzt Ok oder brauchst du noch Hilfe?

Für diesen Fall nicht mehr. Das Problem lag hier das mir nicht bewusste was das der Index bei <> oder not nicht benutzt wird. Ich wäre niemals auf die Idee gekommen das nachzusehen da ich mir sicher war das einer Vorhanden ist. Nun schnurt es wie ein Kätzchen

Eine Kleine Frage noch zum Cache. Hat der Eintrag in der Conf nicht funktioniert oder muss der Wert vor dem erstellen der Datenbank schon eingetragen werden ? Soll ich es mit Gfix ändern.

Danke für Deine Super hilfe hier.

[tsteinmaurer]

Zitat:

Eine Kleine Frage noch zum Cache. Hat der Eintrag in der Conf nicht funktioniert oder muss der Wert vor dem erstellen der Datenbank schon eingetragen werden ? Soll ich es mit Gfix ändern.

Der Eintrag in firebird.conf greift in deinem Fall, weil auf Datenbankebene in der HeaderPage (gstat -h) bei Page Buffers 0 steht. Hier wird dann die Einstellung aus firebird.conf genommen. Ist der Wert in der HeaderPage > 0 für die Datenbank, dann wird der Wert in firebird.conf ignoriert.

LG