Freigeben über

MSSQLSERVER_1204

  • Artikel

Gilt für: SQL Server Azure SQL-Datenbank Azure 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 kann nicht mehr als 60 Prozent des für SQL Server verfügbaren Arbeitsspeichers verwenden, und der Schwellenwert wurde bereits erreicht.

  • Sie richten die Konfigurationsoptionssperren der gespeicherten Systemprozedur sp_configure (Transact-SQL) auf einen nicht standardmäßigen, nicht dynamischen Wert ein.

  • Sie haben Ablaufverfolgungskennzeichnungen 1211, 1224 oder beides auf Ihrem SQL Server aktiviert, um das Verhalten der Sperreskalation zu steuern, und Sie führen Abfragen aus, die viele Sperren erfordern.

Aktion des Benutzers

  • Wenn Sie vermuten, dass SQL Server nicht genügend Arbeitsspeicher zuweisen kann, probieren Sie die folgenden Optionen aus:

    • Ermitteln Sie, ob ein anderer Speicherbearbeiter in SQL Server einen großen Teil des sql Server konfigurierten 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 den maximalen Serverspeicher konfiguriert haben, erhöhen Sie die Einstellung für den maximalen Serverspeicher.

  • Wenn Sie vermuten, dass der Sperr-Manager die maximale Menge verfügbaren Arbeitsspeichers verwendet hat, identifizieren Sie die Transaktion, die die meisten Sperren enthä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 Sie sp_configure den Wert der locks 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.