Laden...

[gelöst] Datenbank bei Remotezugriff sehr träge

Erstellt von Grumbler85 vor 13 Jahren Letzter Beitrag vor 13 Jahren 1.584 Views
G
Grumbler85 Themenstarter:in
538 Beiträge seit 2008
vor 13 Jahren
[gelöst] Datenbank bei Remotezugriff sehr träge

verwendetes Datenbanksystem: SQL EE 2008 auf Windows XP

Hallo allerseits,

ich habe folgendes Problem, wo ich grade etwas unschlüssig bin, wie ich es lösen kann:

Also - ich mache einige komplexere Anfragen an die Datenbank (live erzeugte Statistik in etwa) und diese benötigen, wenn ich sie direkt mit SSMS so zwischen 10 und 30 Sekunden (das ist aufgrund der Menge der Daten okay und die Benutzer werden darauf hingewiesen).
Das Problem ist nur, wenn ich nun von einem anderen Rechner aus per SQLConnection darauf zugreife und die Daten per TableAdapter in eine DataTable lade, so ist das ganze zum Teil so langsam, dass ein TimeOut auftritt (~60Sekunden). Die Daten werden per generiertem Fill aus einer StoredProcedure abgefragt und beinhalten ein Datum als Parameter, welches geändert werden kann.

Wenn jemand eine Idee oder Info für mich hat wie das zu beheben ist oder warum das auftritt, wäre ich sehr dankbar.

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

Gelöschter Account
vor 13 Jahren

nur um das richtig zu verstehen: die daten werden in der SP zusammengestellt und deine anwendung hat nichts anderes zu tun als die fertigen daten zu holen und anzuzeigen. und das alles dauert über die standard sqlconnection deutlich länger als aus dem management studio weshalb dann ein timeout entsteht?

dann ist der übertragungsweg der flaschenhals. evtl verwendet ja das management studio shared memory (auf selbem rechner?)

jedenfalls musst du dir hier was überlegen. entweder du legst das ergebniss in der datenbank ab und pollst, ob es schon fertig ist oder erhöhst den timeout oder oder oder... möglichkeiten gibt es einige.

G
Grumbler85 Themenstarter:in
538 Beiträge seit 2008
vor 13 Jahren

Richtig verstanden.. die SP führt im Endeffekt einen Select aus und diese Daten werden in ein DataSet übertragen.

SSMS nutzt TCP/IP und hat wie gesagt ne vernünftige Antwortzeit (meistens 12 oder 14 Sekunden)

Kann es vielleicht mit irgendwelchen eigenarten bei Datumsvergleichen zusammenhängen (mir hallt da was im Ohr, dass das zu Problemen führen kann)

Interessanterweise wird die Abfrage auch erst fies, nach der Änderung des Datums..

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

Gelöschter Account
vor 13 Jahren

Interessanterweise wird die Abfrage auch erst fies, nach der Änderung des Datums..

könnte auch mit caching zusammenhängen.

hat das management studion auch keine probleme damit, wenn du das datum immer änderst?

G
Grumbler85 Themenstarter:in
538 Beiträge seit 2008
vor 13 Jahren

Das Management Studio macht da gar keine Mucken es wird immer erst träge und langsam, wenn es von .NET ausgeführt wird...

Vielleicht muss ich auch in der DataTable noch was umkonfigurieren?
Ich such auf jeden Fall schon ne Weile und bin bisher nicht dahintergekommen..

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

Gelöschter Account
vor 13 Jahren

ok. zeig mal den .net code.

G
Grumbler85 Themenstarter:in
538 Beiträge seit 2008
vor 13 Jahren

Also normalerweise benutz ich tableAdapter.Fill()

Alternativ hab ich sowas hier:


SqlCommand Command = new SqlCommand("[dbo].[spInventoryByDate]", DB.getConnection());
            Command.CommandType = CommandType.StoredProcedure;
            Command.CommandTimeout = 120;
            Command.Parameters.AddWithValue("@LastDate", set.ToDate);
            SqlDataReader Reader = null;

            try
            {
                Command.Connection.Open();
                Reader = Command.ExecuteReader();
                ...
             }

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

G
Grumbler85 Themenstarter:in
538 Beiträge seit 2008
vor 13 Jahren

Okay ich habe eine bzw. mehrere Lösungen gefunden

"Parameter Sniffing" scheint das Problem zu sein und folgendes ein
OPTION (RECOMPILE)
in der StoredProcedure löst das Problem sauber.

Weitere Infos hab ich hier gefunden:
http://pratchev.blogspot.com/2007/08/parameter-sniffing.html

Vielen Dank für die Mühe!

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)