Ich habe eine Konsole Batchanwendung, die einen Prozess enthält, der SqlDataAdapter.Fill (DataTable) verwendet, um eine einfache SELECT für eine Tabelle durchzuführen.Füllen (DataTable) ist erfolgreich zu testen, hängt in Produktion
private DataTable getMyTable(string conStr)
{
DataTable tb = new DataTable();
StringBuilder bSql = new StringBuilder();
bSql.AppendLine("SELECT * FROM MyDB.dbo.MyTable");
bSql.AppendLine("WHERE LEN(IdString) > 0");
try
{
string connStr = ConfigurationManager.ConnectionStrings[conStr].ConnectionString;
using (SqlConnection conn = new SqlConnection(connStr))
{
conn.Open();
using (SqlDataAdapter adpt = new SqlDataAdapter(bSql.ToString(), conn))
{
adpt.Fill(tb);
}
}
return tb;
}
catch (SqlException sx)
{
throw sx;
}
catch (Exception ex)
{
throw ex;
}
}
Diese Methode wird synchron ausgeführt, und wurde erfolgreich in mehreren Testumgebungen über viele Monate des Testens laufen - sowohl, wenn sie von der Kommandozeile oder gestartet unter der Kontrolle eines AutoSys Job gestartet.
Bei der Produktion wurde der Prozess jedoch aufgehängt - bei der Fill-Methode so gut wie möglich. Schlimmer noch: Statt Zeitlimits auszulösen, hat es anscheinend neue Anfrage-Threads erzeugt und nach ein paar Stunden mehr als 5 GB Arbeitsspeicher auf dem Anwendungsserver verbraucht. Dies wirkte sich auf andere aktive Anwendungen aus und machte mich sehr unpopulär. Es wurde keine Ausnahme ausgelöst.
Die Connection String ist ungefähr so schlicht wie sie kommen.
"data source=SERVER\INSTANCE;initial catalog=MyDB;integrated security=True;"
Entschuldigt, wenn ich die falschen Begriffe verwenden in Bezug auf was die SQL DBA unten angegeben, aber wenn wir setzen auf dem SQL Server eine Spur hatte, zeigte er die ID-Anwendung (unter denen der AutoSys Job ausgeführt wurde) akzeptiert als gültiges Login. Der Server schien dann die SELECT-Abfrage zu verarbeiten. Es gab jedoch keine Antwort zurück. Stattdessen ging es in einen Status "Warten auf Befehl". Der Anfrage-Thread schien einige Minuten geöffnet zu sein und verschwand dann.
Der DBA sagte, dass es keine Anzeichen für einen Deadlock gäbe, aber dass er in Echtzeit überwachen müsste, um festzustellen, ob eine Blockierung vorliegt.
Dies tritt nur in der Produktionsumgebung auf; In Testumgebungen reagierten die SQL Server immer in weniger als einer Sekunde.
Die AutoSys Application ID ist keine neue - es wurde seit mehreren Jahren mit anderen SQL-Servern verwendet und hatte keine Probleme. Der DBA führte sogar die SELECT-Abfrage manuell auf dem Produktions-SQL-Server aus, der als diese ID angemeldet war, und er reagierte normal.
Wir konnten das Problem nicht in einer nicht produktiven Umgebung reproduzieren und zögern, es in der Produktion auszuführen, ohne dass ein Serveradministrator bereitsteht, um den Prozess zu beenden. Unsere Sicherheitsanforderungen beschränken den Zugriff auf die Protokolle und Prozesse des View Servers, und normalerweise muss ich einen anderen Spezialisten hinzuziehen, um sie für mich zu betrachten.
Wir müssen dieses Problem früher oder später lösen. Die Menge an Daten, die wir uns ansehen, ist derzeit nur ein paar Zeilen, wird aber in den nächsten Monaten zunehmen. Von dem, was passiert, ist meine beste Schätzung, dass es Kommunikation und/oder Sicherheit zwischen dem Anwendungsserver und dem SQL-Server beinhaltet.
Alle zusätzlichen Ideen oder Gegenstände zu untersuchen sind willkommen. Danke an alle.
Bei großen Datenbanken kann die Abfrage in VS lange dauern. Verhindere das Hängen Ich benutze einen BackGroundWorker, um zu arbeiten. Anstatt die Datenbank direkt abzufragen, benutze ich cmd.exe, welches eine ausführbare Befehlszeile ist (kommt mit SQL Server), um eine Abfrage durchzuführen und eine CSV-Datei mit Ergebnissen zu erzeugen. Lesen Sie dann die Ergebnisse in der VS-Anwendung. Ich benutze cmd.exe von C# mit einer Prozessklasse aus einem backgrounderworker. – jdweng
@jdweng: Ich denke, das sind einige gute Punkte. Wenn es eine einfache select-Anweisung ist, führen Sie es aus dem sql-Befehlszeilentool aus und schließen Sie die Möglichkeit aus, dass in der Anwendung etwas nicht stimmt. Wie groß ist der Tisch? Sie können die Auswahl mit TOP 1000 ausführen, um sicherzustellen, dass die Ergebnisdaten wie erwartet sind. Das Schreiben von Daten in CSV klingt für mich zum ersten Mal seltsam, aber mit wirklich großen Daten kann es ein Weg sein. –
Mit meiner Anwendung dauerte die sqlcmd.exe 30 Minuten oder länger auf einer 10 GB-Datenbank. Es dauerte Stunden als eine Abfrage in C#. Und meine Fenster für die Anwendung hängen, während die Abfrage ausgeführt wurde. Die einzige Methode, die ich fand, um die Ergebnisse von sqlcmd.exe in C# zu bekommen, war mit einer CSV-Datei. – jdweng