TADOQuery.Open dauert manchmal 30sec..??

[kaju74]

Hallo Ihr Lieben.

Ich habe hier ein großes Problem, dem ich nicht auf die Schliche komme. Spreche über Delphi 2010 eine MS-Access Datenbank (etwa 31MB) an. Dort setze ich ein Query ab, das ~400 Datensätze aus einer Tabelle mit ~50.000 Datensätze liest. Der Query wird in etwa so gesetzt:

Code:

dbqAllocations.SQL.Text := BuildAllocSQL('Allocations', ID, TempAccount.StartDate, EndOfAYear(ComputationYear - 1), [btVacation]);
dbqAllocations.Prepared := True;
dbqAllocations.Open;

Jetzt ist es in der Regel so, dass die Zeit zum Öffnen (also der Open-Befehl) so um die 120msec benötigt. Hin und wieder benötigt der Open-Befehl aber geschlagene 10-30 Sekunden???

Warum???

Ich bin hier echt am verzweifeln....

LG,
Marc

[arnof]

wie sieht denn der SQL Befehl aus der da gemacht wird ?

Die Fehler, die mit WHERE abgefragt werden sollten entsprechenden INDEX haben, dann wird es i.D.R. schneller

[kaju74]

Hi.

Der Befehl sieht so aus:

SELECT * FROM Allocations WHERE UserID IN (80006, 80015, 80082, 80092, 80025, 80026, 80135, 80043, 80133, 80080, 80059, 80061, 80064, 80066, 80131, 80138, 80013, 80002, 80139, 80140, 80148, 80031, 80030, 80147, 80034, 80145, 80111, 80125, 80046, 80124, 80048, 80053, 80120, 80142, 80132, 80146, 80149, 80141, 80123, 80038, 80040, 80054, 80143, 80101) AND (StartDate <= "201212312359") AND (EndDate >= "200901010000") AND (Type = 0) AND (BarType in (2)) ORDER BY UserID, StartDate

Auf UserID und StartDate liegen jeweils ein Index. Bei StartDate/EndDate nicht wundern, dass die ein String sind. Leider historisch bedingt...

Selbst wenn kein Index drauf liegen würden, erklärt das doch nicht die Differenz von ~150msec -> 30sek bei immer dem gleichen SQL-Befehl...?!?

Gruß,
Marc

[sx2008]

Liegt die Datenbankdatei auf der lokalen Festplatte?
Ist Property CursorLocation = clUseServer?

[kaju74]

Ja, liegt lokal und der Cursor auf Server....

Anbei mal ein Performance-Auszug.

LG,
Marc

[rweinzierl]

Ist Access ein richtiger Server? , vielleicht irgend eine Deadlock situation wo ein anderer die Datenbank exklusiv öffnet ?


mfg

Reinhold

[kaju74]

Nein, nutze Access über ADODB/MDAC lokal als einziger...kein Parallel-Zugriff, oder so...

Marc

[arnof]

Zitat:

Zitat von kaju74 (Beitrag 1227221)

Hi.

Der Befehl sieht so aus:

SELECT * FROM Allocations WHERE UserID IN (80006, 80015, 80082, 80092, 80025, 80026, 80135, 80043, 80133, 80080, 80059, 80061, 80064, 80066, 80131, 80138, 80013, 80002, 80139, 80140, 80148, 80031, 80030, 80147, 80034, 80145, 80111, 80125, 80046, 80124, 80048, 80053, 80120, 80142, 80132, 80146, 80149, 80141, 80123, 80038, 80040, 80054, 80143, 80101) AND (StartDate <= "201212312359") AND (EndDate >= "200901010000") AND (Type = 0) AND (BarType in (2)) ORDER BY UserID, StartDate

Auf UserID und StartDate liegen jeweils ein Index. Bei StartDate/EndDate nicht wundern, dass die ein String sind. Leider historisch bedingt...

Selbst wenn kein Index drauf liegen würden, erklärt das doch nicht die Differenz von ~150msec -> 30sek bei immer dem gleichen SQL-Befehl...?!?

Gruß,
Marc

Also Optiomiert ist was anderes .....

der Unterschied zwischen 30 sec und 150 msec ist der Cache ..... Bei erstenmal dauerts lange, wenn er das schon kennt und hat das im Cache dauert es nur die 150 msec :wink:

[mjustin]

Kann man ausschliessen, dass es der Verbindungsaufbau zur Datenbank ist? Wird die Verbindung nur einmal bei Programmstart hergestellt und beim Beenden getrennt, oder ist wird die Verbindung erst kurz vor Ausführung der Query geöffnet?

Ein ähnliches, unregelmäßiges Problem mit um einen drei Minuten verzögerten Connect habe ich bei InterBase 7.5.1 seit mindestens 2012 im Logfile.

Kann man Kosmische Strahlung ausschliessen? ;)

[kaju74]

Hi.

Bin offen für Optimierungen...aber:

Das Laden dauert mitnichten immer beim ersten Mal so lange...sondern teilweise kommt der
Hänger erst beim 3-5 Mal und das erste Mal ist < 300msec...

Gruß,
Marc