Planangaben

[Frank Reim]

Hallo,

ich will eine Abfrage optimieren, welche FB 2.0 beherrscht.
Den Paln, den FB 2 ausgibt, wollte ich nun bei FB 1.54 benutzen:

select * from rechnung where zu_perskonto_id = 30569 and mandant_id = 510
PLAN (RECHNUNG ORDER RECHNUNG_IDX3 INDEX (RECHNUNG_ZUOK, RDB$FOREIGN51))
order by beldat

Jetz streikt aber IBExpert: Token unknown: INDEX
RECHNUNG_IDX3 ist der Index auf beldat, die anderen auf die ID's.
Wie muss ich den Plan richtig angeben?

Danke, Frank

[Markus Kinzler]

Ich würde den Plan von FB erzeugen lassen.

[Frank Reim]

Ich würde den Plan von FB erzeugen lassen.

Ich würde nicht fragen, wenn der Plan von FB brauchbar wäre.
Es gibt halt, wenn auch selten, die Notwendigkeit, dem Optimizer den richtigen Weg zu weisen.

Ich habe aber den Verdacht, dass die Planangabe unter 1.5 nicht geht. Denn FB 2 akzeptiert obigen Select ohne Fehlermeldung.


Frank

[Thomas Steinmaurer]

Hallo Frank,

ich würde auch noch einmal einen Schritt zurück gehen und mir mal in der FB 1.54 Datenbank folgendes ansehen:

- Wie sieht der PLAN aus?
- Sind Indizes drauf?
- Sind diese Indizes aktiv?
- Sind die Statistiken dieser Indizes aktuell?

Bei Deinen Tests mit FB 2.0: Hast Du da ein Backup/Restore der Datenbank gemacht? Wenn ja, hierbei werden ja die Indizes neu erstellt, d.h. der Indexbaum ist ausbalanciert und die Statistiken sind aktuell.

Thomas

[Frank Reim]

Hallo Thomas

Danke für deine Antwort.

Ich habe beide DB's mit Restore erzeugt, somit sind alle Indexe mit Statistiken aktuell. Es ist wirklich ein Unterschied zwischen den Serverversionen.
Der Plan unter 1.54 ist:
PLAN (RECHNUNG INDEX (RECHNUNG_IDX3))
Das ist der Index auf das Feld beldat (Typ DATE).
Ich habe jetzt einen Index über die 3 Felder erzeugt und diesen benutzt er jetzt auch. Aber - wie gesagt - FB2 beherrscht die Optimierung tatsächlich erheblich besser. Und ich merke mal wieder, dass ich die Umstellung doch zeitnah durchführen sollte.

Frank

[Thomas Steinmaurer]

Hallo Frank,

rein aus Interesse. Auch wenn der PLAN unterschiedlich ist:

- Um welche Performancesteigerung sprechen wir hier?
- Wieviele Datensätze sind in der Tabelle?
- Wie schnell wird die Anweisung FB 1.54 vs. FB 2.0 ausgeführt?

Bei Performancetests ist es wichtig, dass etwaige Zeitmessungen immer in Kombination mit einem Fetchen aller Datensätze gemacht wird.

Thomas

[Frank Reim]

Hallo Thomas,

ich habe die Tests mal durchgeführt und bin etwas verwirrt.

select min(beldat) from rechnung where perskonto_id = 30569 and mandant_id = 510

Tabelle Rechnung enthält ca. 300.000 Datensätze und 174 davon enthalten die angegebene mandant_id und perskonto_id.

FB2:
PLAN (RECHNUNG ORDER RECHNUNG_I4 INDEX (FK_RECHNUNG_PERSKONTO, RDB$FOREIGN51))
Geschwindigkeitsanalyse IBExpert: 3 Reads.

FB 1.54:
PLAN (RECHNUNG INDEX (RECHNUNG_I4))
Geschwindigkeitsanalyse IBExpert: 1360 Reads.

RECHNUNG_I4 ist der Index auf beldat

Die Benutzung obigen des obigen Selects als Subselect der Tabelle perskonto (ca. 15.000 DS) ist unter FB 1.54 nicht machbar.
Ich habe den Fetch nach 20 min. abgebrochen (IBExpert Task gekillt).

Unter FB 2 ist es machbar, aber die Performance ist komischerweise auch schlecht.
Das Fetcher aller DS dauert auch hier ca. 5 min.

Und jetzt das Lustige:
Ich lege ich einen neuen Index auf alle 3 Felder an (perskonto_id, mandant_id, beldat)
Diese Index wird verwendet, IBExpert meldet mir 174 Reads und der komplette Fetch (obigen Select als Subselect) dauert nur 4 sec.
Das hab ich erst mal nur unter 1.54 getestet.
Er benötigt also hier den Index über alle Felder.


Aber ich hatte noch einen zweiten Fall:

            select sum(soll), sum(haben)
                   from sachkonto_monat where
                        jahr = :jahr and
                        monat <= :monat and
                        mandant_nr = :mandant_nr and
                        konto = :konto
                   /*
                   plan (sachkonto_monat index (sachkonto_monat_idx5,
                                                sachkonto_monat_idx4,
                                                sachkonto_monat_idx3))
                   */

Das ist ein Teil einer select procedure. Unter FB2 kann ich den Plan herausnehmen. Unter FB 1.5 muss ich ihn angeben!
Unterschied zu FB 1.54 (ohne Angebe von PLAN) ist ca. 5 min zu 5 sec.
In diesem Fall also hat FB2 klar die Nase vorn.

Cu, Frank

[Thomas Steinmaurer]

Hallo Frank,

sollte das im Fall von FB 1.54 nicht der folgende Plan sein?

PLAN (RECHNUNG ORDER (RECHNUNG_I4))

ORDER statt INDEX?

Ich hatte bzgl. Deinem Test eine interessante Diskussion via ICQ mit dem Optimizer Guru im Firebird Projekt.

Es könnte sich auch um einen Bug in Firebird 1.5 and kleiner handeln, was die Ausgabe des PLANs betrifft. D.h., die Verwendung der Indizes wird nicht angezeigt, obwohl welche verwendet werden. Dies kann dann auftreten, falls ein ORDER <index_name> im PLAN vorkommt, dann wird die Verwendung anderer Indizes durch INDEX nicht ausgegeben.

Kannst Du mal folgendes versuchen?

- Nimm die unter Fb 1.54 restorte Datenbank her (d.h. die hat eine ODS 10.x)
- Verbinde Dich mit Fb 2.0 zu dieser FB 1.5 Datenbank. FB 2.0 kann ODS 10.x Datenbank lesen und es wird dann hier so ziemlich der Optimizer von FB 1.5 verwendet, obwohl man mit Fb 2.0 verbunden ist

Wie sieht dann der PLAN aus?


Thomas

[Frank Reim]

Hallo Thomas,

Ich habe also jetzt die mit 1.54 restored DB auf den Server kopiert, mit IBExpert geöffnet und folgenden select ausgeführt:

select min(beldat) from rechnung where perskonto_id = 1173 and mandant_id = 510


Planangaben:
FB2 PLAN (RECHNUNG ORDER RECHNUNG_I4 INDEX (RDB$FOREIGN52))
FB15 PLAN (RECHNUNG ORDER RECHNUNG_I4)

Der Plan auf einer mit 2.0 restored DB

PLAN (RECHNUNG ORDER RECHNUNG_I4 INDEX (RDB$FOREIGN52, RDB$FOREIGN51))

Indexe
RDB$FOREIGN52 = perskonto_id
RDB$FOREIGN51 = mandant_id
RECHNUNG_I4 = beldat

Damit hast du natürlich recht (ORDER statt INDEX).
Ich hätte schwören können, den Plan per Copy and Paste eingefügt zu haben, aber das kann ja wohl nicht sein...

Wenn es ein Bug in der 1.5 er Version ist, dann ist dieser wohl auch verantwortlich dafür, dass ich bei der Angabe des Planes (erster Post) eine Fehlermeldung erhalte?

Und noch mal ... sorry... für die Fehlangabe...


Danke, Frank

[EDIT]
Die Indexnamen können zu den anderen Beiträgen abweichen, da ich nach meinem ersten Post bereits für die Recherche mit den Indexen experimentiert habe, also gelöscht und neu erstellt.
[/EDIT