Firebird - Temporärer Index

[lxo]

Hallo zusammen,

weiß jemand ob es in Firebird die Möglichkeit gibt einen temporären Index zu verwenden.
Also nur innerhalb einer stored procedure oder execute block?

Ich habe eine stored procedure die deutlich schneller wäre wenn ich einen bestimmten Index hätte für ein paar Tabellen.
Grundsätzlich ist dieser Index jedoch nicht wirklich nötig.

[peterbelow]

Hast Du mal versucht einen View auf die Tabelle zu erzeugen und den benötigten Index auf diesen View zu setzen? Die stored procedure müßte dann auf den View zugreifen und nicht auf die Tabelle dahinter...

[lxo]

Wie kann man denn für eine View einen Index erstellen?

[Delphi.Narium]

Wüsste nicht, dass das unter FireBird möglich ist.

[jobo]

Zitat:

Zitat von lxo (Beitrag 1523547)

Hallo zusammen,

weiß jemand ob es in Firebird die Möglichkeit gibt einen temporären Index zu verwenden.
Also nur innerhalb einer stored procedure oder execute block?

Ich habe eine stored procedure die deutlich schneller wäre wenn ich einen bestimmten Index hätte für ein paar Tabellen.
Grundsätzlich ist dieser Index jedoch nicht wirklich nötig.

Ich denke auch, sowas gibt es nicht.

Wenn Du eine SP ausführst, könntest Du dort:
a) eine (temporäre) Tabelle anlegen, die
b) bereits Daten zusammenführt / minimiert und dort
c) anschließend selbst einen Index für erstellen.
dann
d) die eigentlichen Abfrage fahren
e) die Tabelle aus a) und damit automatisch auch den Index löschen.

In jedem Fall gilt, ein "temporärer" Index muss jedes Mal erstellt werden. Das kostet Zeit, die sich nur für sehr aufwändige Abfragen lohnen würde.

[lxo]

Wie sieht es denn aus mit Index generell auf INACTIVE setzen und nur innerhalb der Procedure auf ACTIVE.
Kann das zu Problemen führen?

[mytbo]

Zitat:

Zitat von lxo (Beitrag 1523556)

Wie sieht es denn aus mit Index generell auf INACTIVE setzen und nur innerhalb der Procedure auf ACTIVE.

Steht in der Dokumentation:

Zitat:

With the INACTIVE option, the index is switched from the active to inactive state. The effect is similar to the DROP INDEX statement except that the index definition remains in the database. ...An active index can be deactivated if there are no queries prepared using that index. ...Activating an inactive index is also safe. ...With the ACTIVE option, if the index is in the inactive state, it will be switched to active state and the system rebuilds the index.

Interessant wäre zu erfahren, wie viele Datensätze die betroffenen Tabellen haben. Wie die aktuelle Laufzeit ist und welche Verbesserung du dir erhoffst. Wenn die Anzahl der Datensätze überschaubar ist, kann eine andere (als unkonventionell angesehene) Technik hilfreich sein. Lade die betroffenen Datensätze aus der Datenbank, erstelle deine Verknüpfungen mit Hilfe von Maps und erledige alle Berechnungen lokal. Ob dieses Vorgehen in Betracht kommen könnte, dazu müssten wir mehr wissen. Die Erwähnung einer Stored Procedure lässt etwas Raum zur Spekulation.

Bis bald...
Thomas

[lxo]

Die Tabelle in der die stored Procedure immer wieder sucht ist schon sehr groß ca. 1 Million Datensätze.
Problem ist nur das ich nicht den Primärschlüssel zum suchen verwenden kann.
Die Procedure sucht im Schnitt so grob 100 Einträge in dieser großen Tabelle und das ist sehr langsam nicht indiziert.
Ohne Index ca. 6 Sekunden
Mit Index 32 ms
Das Ding ist einfach nur das ich die Indices eigentlich nur für den Fall brauche und sonst eigentlich nicht.


Die Infos zum Index aktivieren und deaktivieren habe ich bereits gelesen. Ich würde das aber gerne nur für die Connection oder Transaction machen.
Nicht das ich den Index aktiviere und am Ende nicht wieder deaktivieren kann weil eine andere Connection den Index verwendet. Da weiß ich nicht wie sich das verhält und wollte wissen ob da evtl. jemand Erfahrung mit hat.

[mytbo]

Zitat:

Zitat von lxo (Beitrag 1523558)

Die Tabelle in der die stored Procedure immer wieder sucht ist schon sehr groß ca. 1 Million Datensätze.

Welchen Typ hat das Feld, in dem du suchen musst? 1M Datensätze sind nicht viel, damit bringst du keine Datenbank ins Schwitzen. Wenn es keine anderen Gründe gibt, erstelle einfach einen Index oder warte bis Holger vorbeikommt.

Bis bald...
Thomas

[himitsu]

Klar, könnte man zu Beginn in der SP einen INDEX erstellen und am Ende wieder löschen.
Wenn es knallt, wird es auch automatisch wieder zurückgerollt. (denk ich mal)

Man könnte auch eine TempTable in der SP erstellen und füllen.

Aber
* ist das Erstellen des Index dann wirklich schneller, als der langsame Zugriff?
* wäre es wirklich so schlimm, wenn der "nötige" Index immer bestehen bleibt?

[MyRealName]

Du kannst es vllt in eine temporäre Tabelle (deren Inhalt nur für eine Transaction oder Connection sichtbar ist) reinschrieben, die den Index hat, den Du brauchst

[peterbelow]

Zitat:

Zitat von lxo (Beitrag 1523551)

Wie kann man denn für eine View einen Index erstellen?

Ich muss gestehen dass ich nur mit Oracle Erfahrung habe und das ist auch schon etliche Jahr her. Oracle hat sog. "materialized views" auf denen man auch Indizes anlegen kann wenn mich mein Vergessnis nicht täuscht.

[lxo]

Ich mach den Index jetzt einfach generell rein und fertig.
Andere Statements leiden darunter nicht und auch Massen-Inserts sind nicht langsamer. Also schadet der nicht und für meine Procedure hilft er ungemein. :thumb:

[MyRealName]

Zitat:

Zitat von peterbelow (Beitrag 1523572)

Zitat:

Zitat von lxo (Beitrag 1523551)

Wie kann man denn für eine View einen Index erstellen?

Ich muss gestehen dass ich nur mit Oracle Erfahrung habe und das ist auch schon etliche Jahr her. Oracle hat sog. "materialized views" auf denen man auch Indizes anlegen kann wenn mich mein Vergessnis nicht täuscht.

Eine View in Firebird hat keine Indizes.

[TBx]

Zitat:

Zitat von lxo (Beitrag 1523576)

Ich mach den Index jetzt einfach generell rein und fertig.
Andere Statements leiden darunter nicht und auch Massen-Inserts sind nicht langsamer. Also schadet der nicht und für meine Procedure hilft er ungemein. :thumb:

Das ist nach meiner Meinung nach auch die einzig sinnvolle Lösung.

[Blup]

Normalerweise kostet ein Index nicht so viel, dass sich weitere Optimierung lohnen würde.
Aber wenn wenige bestimmte Datensätze eine besonderer Bedeutung haben, kann man sich z.B. als Ersatz für ein Boolean-Feld auch eine Hilfstabelle anlegen, die nur die ID dieser Datensätze enthält.
Die kann z.B. einfach durch einen Trigger gefüllt werden, wenn Datensätze eingefügt oder geändert werden.
Eine View stellt das Ergebnis einer Abfrage auf die Hilfstabelle mit Left-Join zur Haupttabelle dar.

[IBExpert]

kosten vom zusätzlichen index entstehen nur beim schreiben der datensätze via insert/update/delete, wenn da also nicht endlos drauf geschrieben wird, ist der mehraufwand vernachlässigbar. soll aber nicht heissen, das man bei einer tabelle mit 100 feldern einfach mal auf verdacht 100 einzelfeld indizes ascending und zur sicherheit noch 100 einzelfeld indizes descending anlegt. das wird man auf jeden fall merken und ist offensichtlicher mumpitz.

Index auf views gibt es nicht, wurde hier aber ja auch schon korrekt erkannt.

wenn es sinnvoll ist, kann man sich in der ibexpert demo db mal anschauen, wie man eine materialized view nachbilden kann (ist in der datenbank als V_TOP100SALES eingebaut), dessen daten zB großen datenmenge zusammenfassen, der aber schreibend nur on demand maximal ein mal pro minute neu berechnet wird, hatte ich auch in unseren ibexpertise youtube stammtisch videos mal erklärt.

Das oracle konzept des materialized views hatte einen kunden schon mal wegen der einstellung on commit statt on demand in extreme probleme gebracht (die hatte den view deklariert, wir haben da nur jede nacht ca 10000 inserts/updates/deletes gemacht die von einer firebird db kamen und aufgrund der langen leitung zum oracle server sehr oft committed werden mussten, war mit odbc und ibescript zwischen firebird und oracle ganz einfach, bis irgendjemand von denen da ein halbes jahr später den view angelegt hatte, der dann parallel 10000 neuberechnungen ausgelöst hatte und morgens stundenlang keiner mehr arbeiten konnte. da wir nur nachts daten senden, hatte der damit tagsüber noch kein problem ....

Index aktivieren/deaktivieren geht zwar, frisst während dieser zeit zum aktivieren aber sehr viel I/O Last und je nach fb version und hardware kann das eine doofe idee sein

meine tip wie schon von dir gewählt weg: leg den index an und lass den an, wen störts ...