MSSQLSERVER_1204
Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed Instance
Details
attribute | Wert |
---|---|
Produktname | SQL Server |
Ereignis-ID | 1204 |
Ereignisquelle | MSSQLSERVER |
Komponente | SQLEngine |
Symbolischer Name | LK_OUTOF |
Meldungstext | Die Instanz der SQL Server-Datenbank-Engine kann derzeit keine LOCK-Ressource erhalten. Führen Sie die Anweisung erneut aus, wenn die Zahl der aktiven Benutzer kleiner ist. Bitten Sie den Datenbankadministrator, die Konfiguration der Sperren und des Arbeitsspeichers für diese Instanz zu überprüfen oder nach lange andauernden Transaktionen zu suchen. |
Erklärung
Während der Ausführung rufen Abfragen häufig Sperrungen der Ressourcen, auf die sie zugreifen, ab und geben sie frei. Durch den Erwerb einer Sperre werden die Sperrstrukturen aus einem verfügbaren Pool von Sperrstrukturen verwendet. Wenn neue Sperren nicht abgerufen werden können, da im Pool keine weiteren Sperrstrukturen verfügbar sind, wird die Fehlermeldung 1204 zurückgegeben. Dieses Problem kann auf einen der folgenden Gründe zurückzuführen sein:
SQL Server kann nicht mehr Arbeitsspeicher zuordnen, entweder weil andere Prozesse es verwenden, oder weil SQL Server den gesamten Arbeitsspeicher verwendet und den mit der Konfigurationsoption konfigurierten Wert erreicht hat, maximaler Serverspeicher.
Der Sperr-Manager verwendet nicht mehr als 60 Prozent des für SQL Server verfügbaren Arbeitsspeichers, und der Schwellenwert wurde bereits erreicht.
Sie haben die Konfigurationsoptionssperren der gespeicherten Systemprozedur sp_configure auf einen nicht standardmäßigen, nicht dynamischen Wert eingerichtet.
Sie haben Ablaufverfolgungskennzeichnungen 1211, 1224 oder beides auf Ihrem SQL Server aktiviert, um das Eskalationsverhalten zu steuern, und Sie führen Abfragen aus, die viele Sperren erfordern.
Benutzeraktion
Wenn Sie vermuten, dass SQL Server nicht genügend Arbeitsspeicher zuweisen kann, versuchen Sie Folgendes:
Ermitteln Sie, ob ein anderer Arbeitsspeicherclerk innerhalb von SQL Server einen großen Teil des konfigurierten SQL Server-Arbeitsspeichers verwendet hat, indem Sie eine Abfrage wie die folgende verwenden:
SELECT pages_kb, type, name, virtual_memory_committed_kb, awe_allocated_kb FROM sys.dm_os_memory_clerks ORDER BY pages_kb DESC
Verringern Sie dann den Speicherverbrauch dieses Arbeitsspeicherclerks, um das Sperren von Speicher zu ermöglichen, um mehr Ressourcen zu verwenden. Weitere Informationen finden Sie unter Problembehandlung bei nicht genügend Arbeitsspeicher oder geringem Arbeitsspeicher in SQL Server.
Wenn andere Anwendungen als SQL Server Ressourcen verbrauchen, versuchen Sie, diese Anwendungen zu beenden, oder führen Sie sie auf einem separaten Server aus. Dadurch wird Speicher aus anderen Prozessen für SQL Server freigegeben.
Wenn Sie maximalen Serverspeicher konfiguriert haben, erhöhen Sie die Maximale Serverspeichereinstellung.
Wenn Sie vermuten, dass der Sperren-Manager die maximale Menge an verfügbarem Arbeitsspeicher verwendet hat, identifizieren Sie die Transaktion, die die meisten Sperren aufrechterhält, und beenden Sie sie. Das folgende Skript identifiziert die Transaktion mit den meisten Sperren:
SELECT request_session_id, COUNT (*) num_locks FROM sys.dm_tran_locks GROUP BY request_session_id ORDER BY count (*) DESC
Verwenden Sie die höchste Sitzungs-ID, und beenden Sie sie mithilfe des KILL-Befehls .
Wenn Sie einen nicht standardmäßigen Wert verwenden
locks
, können Siesp_configure
den Wert derlocks
Standardeinstellung mithilfe der folgenden Anweisung ändern:EXEC sp_configure 'locks', 0
Wenn bei Verwendung der SQL Server-Ablaufverfolgungskennzeichnungen 1211, 1224 oder beides die obige Fehlermeldung aufgetreten ist, überprüfen Sie die Verwendung und deaktivieren Sie sie beim Ausführen von Abfragen, die eine große Anzahl von Sperren erfordern. Weitere Informationen finden Sie unter DBCC TRACEON – Trace Flags (Transact-SQL) und Beheben von Blockierungsproblemen, die durch die Sperreskalation in SQL Server verursacht werden.
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für