Ich muss für mehr als 12’000 Nummern eine zusätzliche, eindeutige Ext_Referenz ziehen. Diese zwei Values befinden sich zwar in der gleichen View/Tabelle, aber mit meinem SELECT kann ich nur max. 2000 Nummern abfragen und eine Abfrage dauert rund 1 Stunde.
SELECT Ext_Ref, Nummer
FROM Extract_BBCS
WHERE Nummer in (
11111111,
11111112,
…
);
Daher habe ich nun gedacht, alle Nummern in eine temp. Tabelle (mig_temp zu laden und anschliessend mit einem SELECT von der neuen Tabelle die WHERE Funktion definieren
SELECT Ext_Ref, Nummer
FROM Extract_BBCS
WHERE Nummer in (mig_temp)
Funktioniert so was überhaupt? Wenn nicht, kann mir jemand die Lösung sagen?
wenn die Abfrage über 12.000 Datensätze 1h dauert, stimmen die Indizes nicht, sowas sollte in deutlich unter 1s laufen. Leg für deine Abfrage mal einen Index auf Nummer.
Und dann kannst du auch mit Unterabfragen arbeiten
SELECT Ext\_Ref, Nummer
FROM Extract\_BBCS
WHERE Nummer in
(
SELECT Nummer From...
)
Probier mal und dann schauen wir weiter. Wäre gut, wenn du mal deine Tabelle im pre-Tag hinschreiben würdest mit drei Beispielzeilen, dann kann man dir viel besser helfen.
Und natürlich wäre es schön zu wissen, welche Datenbank das ist.
eine View braucht kein bisschen länger als der Select auf die
Tabelle. Ein passender Index wirkt wahre Wunder.
Leider hat der UP noch immer kein DB-System rausgerückt (oder hab ich was überlesen?), jedenfalls würde einerseits eine Materialized View (Oracle-Sprech) das Ganze noch mal schneller machen, andrerseits behauptet er, dass es um 12000 Datensätze geht.
Was ich mich frage: Umfassen diese 12.000 Rows die gesamte Tabelle? (Kommt auch irgendwie nicht raus) Oder ist das nur ein kleines Rowset? (Und die Tabelle hat 120.000.000 Datensätze)
Ein Index sollte natürlich hier helfen (wohlgemerkt: „sollte“), könnte aber genauso nach hinten losgehen; ob nun ein Full-Index- oder ein Full-Table-Scan gemacht wird, ist meist auch schon egal, aber wenn es dann schon existierenden Indizes gibt, ist die Frage, wie sich ein neuer Index auf das bestehende System auswirkt (was sich natürlich mit Optimizer Hints optimieren läßt).
Was auch noch sein könnte: Das DBMS ist komplett verkonfiguriert, zuwenig Speicher zugewiesen, Datenfiles zu klein mit zu vielen „verstreuten“ Extents, etc.
Und dann wäre da noch der Zustand der Festplatte - eine langsame DB hat mir schon des öfteren eine sterbende HD offenbart.
Kurz und gut: Ein Index ist gut und schön, die Gefahr aber, ohne entsprechende DB-Kenntnisse sehr hoch, dass nach einer gewissen Zeit 80-90% unnütze Indizies „herumliegen“, die selber die DB lahmlegen können.
Grüße,
Tomh
PS: Index auf die Table legen (ich hoffe, es war auch so gemeint , auf eine View wirst Du Dich schwer tun.
, auf eine View wirst Du Dich schwer tun.