Unterschiedliche Ladezeiten

verwendetes Datenbanksystem: SQL-Server 2008 R2

Hallo zusammen,

wer kann mir bitte das Verhalten erklären?

Ich habe einen SQL-Befehl (nur zur Info)

Select 1 AS mandant, 'VR' as vg_art, d050056.pos_typ as vg_typ, d050056.vg_nr,
         d050056.pos_nr, d050055.vg_dat, d050055.verl_dat, d050055.lief_dat, 
         d050055.kdnr as adr_nr, d010011.suchname as adr_suchname, d050055.abw_re,
         d050056.artikel_nr, d010015.matchcode, d050056.pos_bez, d050056.vg_mge, 
         d050056.vg_krt, d050056.vg_epreis, d050056.vg_gpreis, d050056.endrabpos, 
         d050056.endrabzws, d050056.posrabproz, d050056.poswrtstlg, d050056.prov_satz, 
         d050055.vg_nr_53, d050055.vg_nr_57, d050055.vg_nr_59, d050051.vg_dat as auftr_dat, 
         '€' as waehrung 
         FROM [EasyFood-001].[dbo].d050056 AS d050056 
         LEFT OUTER JOIN [EasyFood-001].[dbo].d050055 AS d050055  ON d050056.vg_nr = d050055.vg_nr 
         LEFT OUTER JOIN [EasyFood].[dbo].d010015 AS d010015  ON d050056.artikel_nr = d010015.artikel_nr 
         LEFT OUTER JOIN [EasyFood-001].[dbo].d010011 AS d010011  ON d050055.kdnr = d010011.kdnr 
         LEFT OUTER JOIN [EasyFood-001].[dbo].d050051 AS d050051  ON d050055.vg_nr = d050051.vg_nr_55 
         LEFT OUTER JOIN [EasyFood-001].[dbo].d050053 AS d050053  ON d050055.vg_nr_53 = d050053.vg_nr 
         LEFT OUTER JOIN [EasyFood-001].[dbo].d050057 AS d050057  ON d050055.vg_nr_57 = d050057.vg_nr 
         LEFT OUTER JOIN [EasyFood-001].[dbo].d050059 AS d050059  ON d050055.vg_nr_59 = d050059.vg_nr 
         WHERE CASE WHEN d050056.posvertrnr = 0 THEN d050055.vertrnr ELSE d050056.posvertrnr END Between 0 AND 1  
         AND d050055.rg_datum Between '01.01.1753 00:00' AND '31.12.9999 00:00' 
         AND d050055.abw_re Between '0' AND '999999999' AND d050056.artikel_nr Between '' AND 'zzzzzzzzzzzzzzz' 
         AND d050056.pos_typ <> 'T' 
         AND d050056.pos_typ <> 'Z' 
         AND d050056.pos_typ <> 'R' 
         AND d050056.poswrtstlg <> 4 
         ORDER BY d050056.vg_nr, d050056.pos_nr OPTION (RECOMPILE)

der folgendes Verhalten aufweist:

• in MS SQL Sever Mangement Studio 10 braucht er lt. Anzeige ca. 5 Sekunden für etwas über 57000 Zeilen (sehr schnell)
• in VS2010 als SqlCommand in der GUI braucht er ca. 20 Sekunden (mit diesem Code)

select_SQL = <obiger Befehlsstring>
cmd_cKartei = new SqlCommand(selectSQL, connectionSQL_MD);
da_ar = new SqlDataAdapter(cmd_cKartei);
da_ar.Fill(cKartei); "

• in VS2010 als SqlCommand in einem BackgroundWorker braucht er ca. 4-5 Minuten !!!

Wie ihr seht habe ich auch schon die Ausführungen zu Parameter Sniffing gesehen u. deshalb "OPTION (RECOMPILE)"
oder

...WHERE CASE WHEN d050056.posvertrnr = 0 THEN d050055.vertrnr ELSE d050056.posvertrnr END Between @von_wert AND @bis_wert ...

cmd_cKartei.Parameters.Add("@von_wert", SqlDbType.Int).Value = 0;
cmd_cKartei.Parameters.Add("@bis_wert", SqlDbType.Int).Value = 1;  

als Parameter eingebaut; es brachte aber gar nichts.

Auch wenn hier mehrfach zu lesen war das man die Daten nicht im Backgroundworker holen sollte, frage ich mich generell woher diese großen Unterschiede zwischen den einzelnen Ladezeiten kommen.

Den Backgroundworker wollte ich verwenden, damit die Maske nicht währen des Ladens hängt.

Wäre schön, wenn das jemand ein bisschen Licht in das Dunkel bringen könnte.

MfG ChrisProg

Du vergleichst hier Äpfel mit Birnen.

Dass der reine Query im Management Studio schneller ist, also die Abfrage UND die Erstellung der GUI für die Anzeige der Daten - absolut logisch.
Du hast in der zweiten Variante eben den Overhead das Grid aufzubauen - das kostet Zeit; deswegen lädt man auch nicht alle Daten auf ein mal in ein Grid. Kann doch eh kein Mensch lesen.

Und die Info mit Backgroundworker ist auch nicht wirklich glaubhaft.
Du kannst ja mit einem Hintergrundthread eh keine GUI-Elemente bauen - ergo bringt Dir das in Sachen Aufbau der Controls eh nichts. Damit verhindert man nur, dass die GUI nicht hängen bleibt.

Hallo Abt,

ich habe vergessen zu erwähnen, das ich auch bei C# die reine Ladezeit meine.
Ich habe mir entsprechende Haltepunkte (da_ar.Fill(cKartei);) erstellt und mit F11 gesteppt, so kamen die Zeiten zu stande.

Die Zeit für den Backgroundworker sind aber nicht so genau.

Also habe ich doch auch hier die reine Query-Zeit, oder?

Ich sehe da nicht, wo ich Äpfel mit Birnen vergleiche.

MfG ChrisProg

Hallo ChrisProg,

nur als mehr oder minder allgemeiner Hinweis. Wenn du eine Anwendung mit dem Debugger untersuchst, so dauern viele Arbeitsschritte nur wegen dem angehängte Debugger schon deutlich länger. Für belastbare Performanceuntersuchungen sollte man nach Möglichkeit optimierten Code ohne Debugger laufen lassen und ggf. geeignete Messinstrumente (z.B. Programme zur Performancemessung) heranziehen.

Grüße, HiGHteK

Hi,

ich könnte mir vorstellen dass der SQL-Optimierer verschiedene Anfragestrategien wählt. Die Anfrage scheint auch wirklich prädestiniert für solche Instabilität zu sein. Ist das SQL wirklich genau dasselbe? Hast Du mal mit dem Profiler überprüft? Du hast merkwürdige oder überflüssige Bedingungen im SQL-Stmt:

d050055.rg_datum Between '01.01.1753 00:00' AND '31.12.9999 00:00' 
         AND d050055.abw_re Between '0' AND '999999999' AND d050056.artikel_nr Between '' AND 'zzzzzzzzzzzzzzz' 

Das sieht so aus als sollte hier nicht wirklich gefiltert werden sondern alles einbezogen werden. Möglicherweise kommt der Optimierer durcheinander. Das können wir aber schlecht aus der Ferne beurteilen. Ich würde das Stmt mal analysieren lassen, optimieren und prüfen ob es immer dieselbe Anfragestrategie ist.
SInd das eigentlich zwei verschiedene Datenbanken? Liegen die auf verschiedenen Maschinen?

Hi,

kann es sein, dass das MS SQL Sever Mangement Studio 10 zur Anzeige sich lediglich die Anzahl der Sätze der Ergebnismenge und dann die ersten paar Datensätze holt? Wenn Du zum Ende der Ergnismenge springst, dauert das dann lange? Wenn dem so wäre liegt es dann einfach am fetchen und übertragen der Datensätze.

p.s.: wie mein Vorschreiber finde ich das SQL im Übrigen reichlich merkwürdig. Ist das selbstgehäkelt oder stammt es aus einem Genreator?

Gruß
f_igy

Als ich das erste Mal mit ADO.NET zutun hatte, habe ich mich auch gewundert, warum das so grottenlangsam im Vergleich zu anderen Programmiersprachen war...

Schuld war -wie HiGHteK bereits schrieb- der Debugger... Lasse ich meine Programme ohne Debugger laufen, sind sie genau so schnell wie z.B. bei nativen Sprachen...

Hallo zusammen,

@ Witte,

nein, es sind keine verschiedenen Datenbanken u. ich mache die Tests auch von der selben Maschine aus.

Zum String: wie Du schon richtig bemerkt hast, grenzen im Moment nicht alle Bedingungen ein,
das wird sich aber im Echtbetrieb durch Usereingaben ändern;
für den Test reichs mir, wenn sie da sind.

@f_igy,

Ich hab das mit dem Management Studio 10 gerade überprüft:

• nein er zeigt mir sofort nach den 5 Sekunden die Daten an, auch das scrollen geht verzugsfrei, ebenso Pageup, Pagedown oder ziehen mit der Maus.

Der SQL-Code ist selbstgestrickt, da ich es irgendwie nicht hinbekomme im Designer mehrer DB´s einzubeziehen - hab mich aber auch nicht intensiv drum gekümmert, um ehrlich zu sein.

@MorhieX u. HiGHteK,

leider dauert es auch so lange (gefühlt vielleicht ein bisschen schneller - ich hab gerade kein Tiimerprogramm) wenn ich die kompilierte Exe starte. Ich weiss allerdings (noch) nicht,
wie es auf einer Maschine ohne Entwicklungsumgebung ist.

MfG ChrisProg

Hast du vielleicht dummerweise dein cKartei bereits an irgendwas gebunden?

Hallo FZelle,

X( wie war das doch gleich mit dem Wald u. den Bäumen ??? :evil:

Danke, für den Tip, das war´s.

MfG ChrisProg