Wir alle warten auf den Ausführungsplan
, 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 ?