Abfrage dauert zu lange unter Delphi

[Dumpfbacke]

Hallo Leite,
ich habe hier ein Problem mit der Laufzeit einer SQL Abfrage

Hier die Abfrage:

Delphi-Quellcode:

Select Refernz,Eingang,StatusRein ,StatusRaus
From Material
where Eingang IS NULL and MaterialTyp not in ('Rohre')
and StatusRaus <> 'Auftrag noch nicht erzeugt' and Refernz is not NULL

Ein Index ist jewals auf den Felden Refernz, Eingang, StatusRaus und Materialtyp
Die Tabelle hat ca. 3,8 Mio Datensätze und das Ergebnis sind ca. 1 - 20 Datersätze.

Nun aber zum Problem.
Ich benutze hier eine TIBQuery um die Daten abzufragen. Wenn ich die Query im Objektinspektor bei Active auf True gestzt so dauert es ca. 8 Sekunden was auch in Ordnung ist. Wenn ich es nun in meinen Programm mache dauert es 5-8 Minten bis die Daten vorliegen. Vor dem Aktivieren Starte ich eine neue Transaction.
Was mache ich den falsch ? So langsam weiß ich nicht mehr weitere. Ich haben schon UniDirectional und BufferChuks geändert. Die Version von Delphi ist 7
Es kann doch kein Unterschied sein ob die im Abjektinspektor die Eigenschalt Active auf True setzte oder im Programm ?

[Dejan Vu]

Und Du bist Dir ganz sicher, das es der gleiche Connection ist? Und andere Fallen gibt es auch nicht? Z.B. berechnete Felder oder irgendwelche Events?

[Nersgatt]

Zitat:

Zitat von Dumpfbacke (Beitrag 1285688)

ich habe hier ein Problem mit der Laufzeit einer SQL Abfrage
[...]
Ich benutze hier eine TIBQuery um die Daten abzufragen. Wenn ich die Query im Objektinspektor bei Active auf True gestzt so dauert es ca. 8 Sekunden was auch in Ordnung ist. Wenn ich es nun in meinen Programm mache dauert es 5-8 Minten bis die Daten vorliegen.

Hängt an der Query noch irgendwas an Ereignissen im AfterOpen, AfterScroll, oder Ähnliches? Oder sind da noch Dinge dran gebunden, wo Ereignisse dran hängen, die lange dauern?

[Jasocul]

Mach doch mal vor dem Open ein DisableControls und hinterher ein EnableControls.

[TRomano]

Es sind halt auch 3.8 Mio records und er macht Stringvergeliche ohne Ende (auch noch mit IN('',...)) ... das kann je nach DBMS und DB-Server (hardware) etwas dauern.
Ich würde einfach mal die zeit messen oder mit einem Admin-Tool die Abfrage laufen lassen und sehen, wie lange das alles ohne das eventuelles Client-Gedönse (Delphi, Events) dauert.
Dann würde ich wissen, wo ich ansetzen muss ...

[Uwe Raabe]

Zitat:

Zitat von TRomano (Beitrag 1285702)

wie lange das alles ohne das eventuelles Client-Gedönse (Delphi, Events) dauert.

Wir wissen bereits, daß es in der IDE ca. 8 Sekunden dauert:

Zitat:

Wenn ich die Query im Objektinspektor bei Active auf True gestzt so dauert es ca. 8 Sekunden was auch in Ordnung ist.

[mjustin]

Zitat:

Zitat von Dumpfbacke (Beitrag 1285688)

Ein Index ist jewals auf den Felden Refernz, Eingang, StatusRaus und Materialtyp
Die Tabelle hat ca. 3,8 Mio Datensätze und das Ergebnis sind ca. 1 - 20 Datersätze.

Wenn die Query innerhalb von 8 Sekunden geöffnet wird, so heisst das meistens, dass nur der erste Datensatz da ist.
Zur Laufzeit werden auch die folgenden bis zu 19 Datensätzen aus den 3,8 Millionen angefordert, und bis die eintreffen, dauert es länger.
Beweis: in einem SQL Client Tool die gleiche Abfrage ausführen und bis zum Ende des Resultsets scrollen.

[Dejan Vu]

Zitat:

Zitat von mjustin (Beitrag 1285720)

Wenn die Query innerhalb von 8 Sekunden geöffnet wird, so heisst das meistens, dass nur der erste Datensatz da ist.
Zur Laufzeit werden auch die folgenden bis zu 19 Datensätzen aus den 3,8 Millionen angefordert, und bis die eintreffen, dauert es länger.
Beweis: in einem SQL Client Tool die gleiche Abfrage ausführen und bis zum Ende des Resultsets scrollen.

Er spricht vom Objektinspektor. Ist das dann da auch so? Im OI dauert das Öffnen 8 Sekunden, im Programm wesentlich länger.

Trotzdem gute Idee. Hat mich schon manchen Haarbüschel gekostet...

[TRomano]

Okay, dann hatte ich etwas überlesen. Ich wollte auch nur die grundlegende Herangehensweise bei solchen Problemen benennen.
Trotzdem sollte man immer alles betrachten (DB-Design, Protokolle, clientseitige Events).

[Dumpfbacke]

Zitat:

Zitat von Dejan Vu (Beitrag 1285689)

Und Du bist Dir ganz sicher, das es der gleiche Connection ist? Und andere Fallen gibt es auch nicht? Z.B. berechnete Felder oder irgendwelche Events?

Ja so ist es. Es sind keine Events und keine berechnetet Felder vorhande.

[Dumpfbacke]

Zitat:

Zitat von Nersgatt (Beitrag 1285690)

Hängt an der Query noch irgendwas an Ereignissen im AfterOpen, AfterScroll, oder Ähnliches? Oder sind da noch Dinge dran gebunden, wo Ereignisse dran hängen, die lange dauern?

Nein es hängt da nichts dran

[Dumpfbacke]

Zitat:

Zitat von Jasocul (Beitrag 1285695)

Mach doch mal vor dem Open ein DisableControls und hinterher ein EnableControls.

Hat leider nichts gebracht

[Blup]

Wie bereits gesagt, in der Entwicklungsumgebung wird beim Öffnen der Datenmenge nur der erste Datensatz geholt.
Dann unterbricht die Datenbankabfrage.
Um die Gesamtlaufzeit zu ermitteln, muss man zum letzten Datensatz springen.

Zur Laufzeit hängt vermutlich auch ein Grid an der DataSource.
Das fordert nach dem Öffnen mit Standardeinstellungen automatisch so viele Datensätze an, wie derzeit darstellbar sind.

Die lange Laufzeit ist bei der Datenmenge in Kombination mit dieser Abfrage nicht verwunderlich.
Poste uns doch mal den berechneten Ausführungsplan.

[mkinzler]

Bei IN kann auch kein Index greifen. Wenn die Werte mit 'Röhre" beginnen könnte man STARTING WITH statt IN verwenden, dann mit Indexunterstützung.

[p80286]

Ich gehe davon aus, daß das IN hinterher mit mehreren Werten gefüllt ist. Niemand wird ein = durch ein IN ersetzen! (oder doch?)

Gruß
K-H

[tsteinmaurer]

Jegliche Ungleichheitsoperatoren (<>, IS NOT, NOT IN etc.) können in der Regel nicht durch einen Index bedient werden, d.h. der einzige Index der ev. greift ist auf dem Feld "Eingang".

Mich würde primär mal der Ausführungsplan interessieren.

[sx2008]

Und etwas Klarheit zu bekommen würde in Delphi mal folgende Abfrage testen:

SQL-Code:

Select COUNT(*) AS Anzahl
From Material
where Eingang IS NULL and MaterialTyp not in ('Rohre')
and StatusRaus <> 'Auftrag noch nicht erzeugt' and Refernz is not NULL

Diese Abfrage erzeugt auf dem Server annähernd die gleiche Last; allerdings wird nur ein einziger Datensatz an den Client übertragen.
Somit lässt sich erkennen wo der Flaschenhals ist.
Und dann würde ich dir DRINGEND empfehlen das Feld "StatusRaus" als Integerfeld anzulegen.
Überlege dir welche Statuswerte es gibt und welche es in Zukunft noch geben könnte.

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1285784)

Bei IN kann auch kein Index greifen.

Wieso nicht? ein 'X IN (A,B)' ist identisch mit 'X=A or X=B' und dann kann sehr wohl ein Index greifen. Vielleicht bei FB nicht, aber nur dann, weil FB an der Stelle schlampt.

Zitat:

Zitat von Blup (Beitrag 1285782)

Wie bereits gesagt, in der Entwicklungsumgebung ...

Zitat:

Zitat von Dumpfbacke (Beitrag 1285688)

...Wenn ich die Query im Objektinspektor ...

Meinst Du mit 'Entwicklungsumgebung' Dinge, wie IBExpert, oder wirklich die Delphi-IDE?

[tsteinmaurer]

Zitat:

Wieso nicht? ein 'X IN (A,B)' ist identisch mit 'X=A or X=B' und dann kann sehr wohl ein Index greifen. Vielleicht bei FB nicht, aber nur dann, weil FB an der Stelle schlampt.

Ne, Firebird schlampt hier nicht und kann bei einem IN Operator (ohne Negation) natürlich einen Index verwenden sofern der Optimizer anhand der Indexstatistiken der Meinung ist, dass der Zugriff über den Index sinnvoll ist.

[Dejan Vu]

Wäre ja wohl auch noch schöner.

[Dumpfbacke]

Zitat:

Zitat von tsteinmaurer (Beitrag 1285790)

Jegliche Ungleichheitsoperatoren (<>, IS NOT, NOT IN etc.) können in der Regel nicht durch einen Index bedient werden, d.h. der einzige Index der ev. greift ist auf dem Feld "Eingang".

Mich würde primär mal der Ausführungsplan interessieren.

Also das in ist hier natürlich falsch und unlogisch. Es muss hier nur eine Wert ausgeschlossen werden und deshalb wird hier auch ein <>. Ich hatte es mal geändert im zu sehen ob sich was ändert und dann ganz vergessen es hier zu ändern.
Also : and MaterialTyp <> 'Rohre'

Nun zum Ausführungsplan. Leider ist es richtig das hier wirklich nur ein Index greift und zwar der vom Feld Eingang. Mir war nicht bewusst das beim negieren der Index nicht mehr greift. Man lernt immer dazu.
Also Dauert es nun wirklich so lange bis die wenigen Datensätze ausgelesen sind ? Gibt es noch eine Möglichkeit für mich wo ich etwas ändern kömnnte ?

Schon einmal Danke alle hier Ihr seit einfach die Experten.

[mkinzler]

Zitat:

Also Dauert es nun wirklich so lange bis die wenigen Datensätze ausgelesen sind ?

Das hat nichts mit der Anzahl der zurückgegebenen Datensätze zu tun, sondern mit der Tatsache, dass kein Index greift.

Zitat:

Gibt es noch eine Möglichkeit für mich wo ich etwas ändern kömnnte ?

Ja, Normalisierung ( Materialtyp, Statusraus, usw.)

[jobo]

Wenn Du von 3,8 mio auf 20 Datensätze kommst, muss irgendetwas in den Parametern ja diese Einschränkung bringen.
Das Kriterium, das die größte Einschränkung bringt, sollte idealerweise per Index laufen.
Neben den genannten Vorschlägen, würde ich mal probieren, wieviel die eine Spalte mit Index bringt, also wie groß /klein das Ergebnis bereits ist und das in einer Kapselung weiter einschränken, wenn es bereits klein genug ist.
Also bspw. im ersten Schritt per Kriterium 1 von 3,8 Mio auf 10 T und im 2. die restlichen Kriterien anwenden, ist dann quasi nur noch etwas Kopfrechnen.
Im Grunde ist das Spielerei mit dem Optimizer, geht vermutlich auch per Hints, weiß nicht genau wie das bei Firebird ist.
Konkret wäre noch der Vorschlag, das schwache
Referenz is not null gegen ein kräftiges
Referenz> ' '
oder anderes auszutauschen, je genauer, desto besser. Dann könnte hier auch der Index greifen. Muss natürlich sichergestellt sein, dass das Kriterum auch die gleiche Menge ergibt.

[hoika]

Hallo,
ich warte immer noch auf den Query-Plan ...

Heiko

[tsteinmaurer]

Wir alle warten auf den Ausführungsplan :-D, aber im Wesentlichen hat der Thread-Ersteller die Indexverwendung schon bestätigt. Ich würde jetzt sogar noch etwas weiter ausholen, nämlich:

• Welche Firebird Version wird genau eingesetzt?
• Welche Firebird Architektur?
• Was ergibt gstat -h, da ich mal stark davon ausgehe, dass bzgl. Page Cache die Default-Einstellungen verwendet werden
• Wie oft wird diese Abfrage ausgeführt, sprich welches Optimierungspotential hat man hier eigentlich?
• Wie viele Datensätze befinden sich in der Tabelle und wieviele Datensätze werden ca. von der Abfrage zurückgeliefert?

Wie gesagt, jegliche Negation unterbindet die Verwendung eines Index. D.h. man könnte den Spieß umdrehen und z.b. zusätzlich eine Art "Status-Schattenfeld" via Trigger mitwarten, um darüber mit einem nicht-negierten indexierten Zugriff einen Großteil der Datenmenge auszufiltern. Hängt halt stark davon ab wieviele Kombinationsstati es gibt. Ob sich dieses Vorgehen lohnt ist halt sehr spezifisch (bzgl. Datenvolumen, Selektivität der neuen Schattenstati etc.), aber durchaus in der Praxis anzutreffen.

LG

[Dejan Vu]

Zitat:

Zitat von tsteinmaurer (Beitrag 1285845)

Wie gesagt, jegliche Negation unterbindet die Verwendung eines Index.

Das verstehe ich nicht. Wenn das so implementiert ist, geht reichlich Potential flöten. Meistens ist es zu teuer, einen Index zu verwenden, aber möglich wäre es schon.
Beispiel: 'Field <> 'b'
Der Index sieht so aus: 'AAAbbbbbbbbCCC', d.h. wir haben 14 records, 3 mit 'A' und 8 mit 'b' und 3 mit 'C'.
Ohne Verwendung des Index müssen wir einen Scan durchführen, mit Verwendung können wir die Sequenz (darum geht es doch beim Abarbeiten der Query) für diese Bedingung einfach durch Konkatenation der beiden Teilindexe 'AAA' und 'CCC' bilden. Das ist (hier) wesentlich schneller als der Scan.

Die Verwendung des Index ist aber teuer, sodaß er selten dieser Fall seltener Einsatz kommt, aber in Extremfällen (z.B. 90% der Records haben im Feld 'b' zu stehen), bringt das durchaus etwas, einen Index zu verwenden.

[tsteinmaurer]

Ist technisch erst möglich wenn zum Zeitpunkt der Planerstellung der Optimizer Kenntnis über die Verteilung der Daten hat. Aktuell gibt es diese Information nicht, sondern es wird banal gesagt derzeit alles über den Selektivitäts-Kamm eines Index geschert. Mit der Einführung der Speicherung von Histogrammdaten für Indizes schauts dann anders aus. Hier hat dann der Optimizer zur Prepare-Time viel mehr Möglichkeiten.

Ein extremeres Beispiel ist mit einem Boolean-Feld. Angenommen wir haben eine große Tabelle (> 1 Mio Datensätze) wo nur ein Datensatz den Wert FALSE beinhaltet. Die Verwendung eines Index für die Suche nach TRUE wird in der Regel immer langsamer sein als ein Full-Table Scan, weil für den Zugriff zum eigentlichen Datensatz immer doppelt gemoppelt wird, sprich Index Page laden, Lookup des Datensatzes = Data Page laden. Abfrage des einen Datensatzes mit FALSE siehts natürlich ganz anders aus. Bei der Mitführung eines Histogramms würde der Optimizer wissen, dass 999999 Einträge TRUE speichern und 1er FALSE. Dieses Wissen kann sich dann der Optimizer zu nutze machen, dass je nach Abfrageprofil ein Index verwendet wird oder auch nicht.

Siehe auch: http://tracker.firebirdsql.org/browse/CORE-1686

Ursprünglich für Firebird 3 geplant, aber aktuell für V3 rausgenommen.

[Dejan Vu]

Stimmt. Ohne Statistiken ist hier nichts zu holen. Danke für die Aufklärung.

[Dumpfbacke]

Zitat:

Zitat von tsteinmaurer (Beitrag 1285845)

Wir alle warten auf den Ausführungsplan :-D, aber im Wesentlichen hat der Thread-Ersteller die Indexverwendung schon bestätigt. Ich würde jetzt sogar noch etwas weiter ausholen, nämlich:

• Welche Firebird Version wird genau eingesetzt?
• Welche Firebird Architektur?
• Was ergibt gstat -h, da ich mal stark davon ausgehe, dass bzgl. Page Cache die Default-Einstellungen verwendet werden
• Wie oft wird diese Abfrage ausgeführt, sprich welches Optimierungspotential hat man hier eigentlich?
• Wie viele Datensätze befinden sich in der Tabelle und wieviele Datensätze werden ca. von der Abfrage zurückgeliefert?

Wie gesagt, jegliche Negation unterbindet die Verwendung eines Index. D.h. man könnte den Spieß umdrehen und z.b. zusätzlich eine Art "Status-Schattenfeld" via Trigger mitwarten, um darüber mit einem nicht-negierten indexierten Zugriff einen Großteil der Datenmenge auszufiltern. Hängt halt stark davon ab wieviele Kombinationsstati es gibt. Ob sich dieses Vorgehen lohnt ist halt sehr spezifisch (bzgl. Datenvolumen, Selektivität der neuen Schattenstati etc.), aber durchaus in der Praxis anzutreffen.

LG

Hier nun meine Antworten.
Das Probelm liegt hier eindeutig am Index. Ich habe es wie hier Geschrieben mit einen Zusätzlichen Feld gelöst. Für weitere Anregungen bin ich immer offen. Wenn mir geholfen wird und ich vor allen noch etwas lernen kann bin ich immer dabei.

• Welche Firebird Version wird genau eingesetzt? Antwort :2.5
• Welche Firebird Architektur? Antwort Classic oder Super Classic
• Was ergibt gstat -h, da ich mal stark davon ausgehe, dass bzgl. Page Cache die Default-Einstellungen verwendet werden Siehe Unten
• Wie oft wird diese Abfrage ausgeführt, sprich welches Optimierungspotential hat man hier eigentlich? alle 15 Minuten. Das Problem war da es mehrer Abfragen / Aufgaben gab und es so in Summe länger als 15 Minten dauerte. Dorch die Optimierung bin ich nun unter 10 Minuten in Summe für alles
• Wie viele Datensätze befinden sich in der Tabelle und wieviele Datensätze werden ca. von der Abfrage zurückgeliefert?Anazhl > 3,7 Millionen und Rurückgeliefert werden zwischen 0 und 50

Inhalt von gstat

Database header page information:
Flags 0
Checksum 12345
Generation 299054
Page size 16384
ODS version 11.2
Oldest transaction 288592
Oldest active 295032
Oldest snapshot 295032
Next transaction 295513
Bumped transaction 1
Sequence number 0
Next attachment ID 3538
Implementation ID 26
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Feb 11, 2012 13:40:10
Attributes force write

Variable header data:
*END*


Ups hier wirde eine alte Transaction anscheinend nicht geschlossen. Muss ich doch mal im Code prüfen wo der Fehler liegt.

Was ist ein Ausführungsplan ?

[Sir Rufo]

Ich werfe es mal in die Runde:

Eine zusätzliche Zugriffs-Schicht zwischen der Anwendung und der Datenbank kann dieses Problem sehr elegant lösen, denn Änderungen laufen durch diese Schicht, und ohne Änderungen ändert sich das angeforderte Ergebnis auch nicht und kann also aus dem Cache beantwortet werden. Erst nach einer Änderung wird die Abfrage wirklich erneut ausgeführt.

Das bedingt natürlich, dass man sich in der Anwendung vom SQL-Gedanken trennt und dort mehr auf den echten Kontext konzentriert.

[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? :-D

[Dumpfbacke]

Zitat:

Zitat von tsteinmaurer (Beitrag 1285912)

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? :-D

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. :-D 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:

Zitat von tsteinmaurer (Beitrag 1285919)

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

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