Re: Geschwindigkeit optimieren ADO


Hallo Christopher,

Christopher Schlüter schrieb:
ich habe ein VB6 Programm, das per ADO auf einen SQL Server 2005 zugreift.
Da müssen nun einige Queries optimiert werden.
Die Frage ist nur, wie ich die höchste Geschwindigkeit erreiche.

Die Abfrage wird sehr oft aufgerufen, wobei sich mind. 1 Parameter ändert.
Was ist mit ADO die schnellste?

-Recordset dim, öffnen mit jeweils anderem SQL String
-Private Recordset einmal dim, dann immer öffnen und schließen mit anderem SQL String
-dasselbe nur über das Connection Objekt
-SQL Server Stored Procedure mit Command Objekt aufrufen-> Recordset
-SQL Server Stored Procedure über Connection Objekt ausführen und alle Parameter appenden

Steht nirgendwo in der Hilfe was schneller ist.

Weil exakte Werte mehr von der Abfrage abhängen.

Grundsätzlich ist es für wiederholte Abfragen besser ein Command-Objekt
mit Parametern zu verwenden.
Ob der Einsatz einer Prozedur was bringt hängt mehr vom Typ der
Abfrage selbst ab - nämlich ob der Abfrageplan im wesentlichen
gleich bleiben kann.

Aber auch ohne Prozedur nutzt ein parameterisiertes Command Objekt
sp_executesql, das auf den Prozedurcache des SQL Servers zurückgreift.

Bei Inline-Parametern (d.h. verketten der Parameterwerte zu einer
SQL Anweisung) können unterschiedlichste Abfragepläne generiert werden.
Das kostet zum einen Kompilierzeit auf dem Server, zum anderen kann
es u. U. den Cache des SQL Server aufblähen.
Detaillierter geht darauf ein: <URL:http://www.sommarskog.se/dynamic_sql.html>

Auf ADO Seite selbst ist das schnellste ein Recordset mit
adOpenForwardOnly, adLockReadOnly, auch mal Firehose Cursor genannt.
(Und bei ADO.NET z. B. gibt es nur noch den).

Den erhältst Du bei einem serverseitigen Cursor (adUseServer)
über die Execute Methoden des Command wie des Connection Objektes
oder in dem Du es selbst deklarierst und Open verwendest.

Es spielt keine Rolle wie du es erzeugst, implizit oder explizit.
Die mehrfache Nutzung eines ADODB.RecordSet Objektes spart kaum,
denn die damit verknüpften internen (OleDb) Objekte nehmen,
wechseln ohnehin.

Bei der Clientseitigen Bibliothek (adUseClient) wird der
ForwardOnly/ReadOnly Cursor immer verwendet, die Daten werden
aber durch die Client-Bibliothek gepuffert, was etwas
(client)seitigen Overhead wie Speicherverbrauch bedeutet.
Für den SQL Server ist das aber ohne Belang.

Der Vorteil wiederum ist, dass die Daten üblicherweise
(ohne Spielchen mit FetchSize) komplett abgerufen werden.

Bei einem serverseitigen Cursor solltest Du das Recordset
so schnell wie möglich bis zum Ende durchlaufen, damit
die Ressourcen freigegeben werden können und die Verbindung
frei wird. Denn ansonsten werden ggf. intern weitere
Verbindungen eröffnet, mit unangenehmen Nebeneffekten wie:
<URL:http://support.microsoft.com/kb/271128>

Gruß Elmar
.

Relevant Pages
Loading