Einfache SQL-Abfragen werden nicht beendet [geschlossen]

Ich weiß nicht genau, wie ich die Frage formulieren soll, weil wir noch nicht viel wissen, aber ich möchte früher als später fragen, weil dies wie etwas aussieht, das nicht vernachlässigt werden sollte.

Diese Woche hatten wir Probleme mit unserem Datenbankserver. Es scheint sich um ein Datenkonsistenzproblem zu handeln, das sich auch bei sehr einfachen Abfragen und kleinen Tabellen in Zeitüberschreitungen äußert. Wir haben das Problem "behoben", indem wir den Server Anfang dieser Woche neu gestartet haben und er ist verschwunden, aber jetzt scheint es, dass er zurückkommt und diesmal auf wichtigeren Tabellen. Zum Beispiel habe ich gerade Nachforschungen angestellt und sehe mir eine Abfrage wie diese an:

SELECT * FROM table WHERE id = 1234

für eine bestimmte ID. Die Tabelle enthält mehr als 30 Millionen Zeilen. Aber es scheint, dass es nur für einen kleinen Bruchteil der Aufzeichnungen passiert. Ich wette, wenn ich den Server neu starte oder die Datenbank auf einem anderen Server sichere und wiederherstelle, ist alles in Ordnung. Aber ich werde es versuchen.

An diesem Punkt renne ich:

DBCC CHECKTABLE ('table', NOINDEX)

aber es scheint, dass es für immer laufen wird. Als wir das erste Mal auf die Probleme stießen, überprüfte ich die beleidigende Tabelle und es war in Ordnung. Dieser neue Tisch ist viel größer.

Einige technische Hintergrundinformationen:

• SQL Server 2008 R2, Windows Server 2008 R2
• AWS / EC2, m2.2xlarge, 32 GB RAM, 4 x 1 TB RAID 0
• Fast keine Festplatten-E / A, es scheint, dass sich der größte Teil der Datenbank im Speicher befindet
• Gesamtgröße der Datenbank: 100 GB

Die ELB-Volumes sind "brandneu". Wir haben sie diese Woche erstellt.

Bearbeiten: Ich habe gerade den folgenden Befehl verwendet:

SELECT
    sqltext.TEXT,
    req.session_id,
    req.blocking_session_id,
    req.wait_type,
    req.wait_time,
    req.last_wait_type,
    req.wait_resource,
    req.open_transaction_count,
    req.transaction_id,
    req.total_elapsed_time
FROM
    sys.dm_exec_requests req
CROSS APPLY
    sys.dm_exec_sql_text(req.sql_handle) AS sqltext

und stellte fest, dass meine Abfrage auf eine gemeinsam genutzte Sperre (LCK_M_S) wartet, wobei die Blockierungssitzung auf eine andere gemeinsam genutzte Sperre wartet, die von einer nicht vorhandenen Sitzung blockiert wird.

Bearbeiten 2: OK, die Sitzung existiert (ich habe sie mit gefunden sys.dm_exec_sessions), aber sie scheint jetzt nichts zu tun.

Edit 3: Ich kann nichts Interessantes an der Sitzung finden. Ich sehe, von welchem ​​Webserver es kommt, aber sonst nicht viel.

Bearbeiten 4: Bearbeiten 4: Wir haben einen möglichen Fehler in unserem Code gefunden: eine Funktion, die nicht sicherstellte, dass eine Datenbankverbindung geschlossen ist. Auf der anderen Seite sah es so aus, als ob die Transaktion, die die Funktion verwendete, korrekt entsorgt wurde. In diesem Fall hätten alle Sperren gelöscht werden müssen. Es ist mir immer noch nicht sehr klar, aber es scheint der wahrscheinliche Grund zu sein. Wir werden den Fehler beheben und ihn im Auge behalten.

Für mich wurde dieses Problem durch eine von Visual Studio geöffnete Datenbankverbindung verursacht, die im Debug-Modus angehalten wurde. Durch das Stoppen des Debug-Prozesses konnte die Abfrage sofort abgeschlossen werden.

Was ist der Wartetyp für die Abfrage, wenn sie aufgehängt ist? Hier erfahren Sie genau, worauf Sie warten. Suchen und installieren Sie sp_whoisactive auf dem Server und führen Sie die gespeicherte Prozedur aus, wenn Sie das Problem haben. Dies zeigt Ihnen die Spid und gibt Ihnen den Wartetyp.

Wahrscheinlich werden Sie von jemandem blockiert, der in diese Zeile oder eine andere Zeile auf dieser Seite schreibt, oder Sie warten darauf, dass die Festplatte antwortet.

Versuchen Sie, DBCC CHECKDBdie Problemdatenbank auszuführen, und warten Sie, bis sie abgeschlossen ist. Wenn es eine physische Dateninkonsistenz gibt, die zu einem so seltsamen Verhalten führt, ist es zu gefährlich, mit dieser Datenbank zu arbeiten, da Sie möglicherweise alle Ihre Daten verlieren.

1. Führen Sie die Sicherung so schnell wie möglich durch.
2. Überprüfen Sie die DB.

ABER

Wenn die Tabelle BLOB-Spalten mit relativ großen Datenmengen enthält, ist es absolut normal, dass die Überprüfung dieser Tabelle lange dauern sollte.

Ich bin mir nicht sicher, was Sie als Antwort erwarten, aber wenn die Tabelle mehr als 30 Millionen Zeilen enthält, wird erwartet, dass der DBCC-Befehl für eine lange Zeit ausgeführt wird.

Wenn du sagst:

Aber es scheint, dass es nur für einen kleinen Bruchteil der Aufzeichnungen passiert

Sie meinen, Sie befürchten, dass der gesamte Tisch nicht gescannt wird? Das ist normal, wenn Sie einen Index für die ID haben. Der Index wird gescannt, was zu weniger Lesevorgängen führen würde.