KB2926217 - FIX: Leistungsprobleme treten auf, wenn die Datenbanksperraktivität in SQL Server

Gilt für
SQL Server 2012 Enterprise SQL Server 2012 Developer SQL Server 2012 Standard SQL Server 2012 Express SQL Server 2012 Web SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use) SQL Server 2008 Service Pack 3 SQL Server 2008 Developer SQL Server 2008 Enterprise SQL Server 2008 Standard SQL Server 2008 R2 Service Pack 2 SQL Server 2008 R2 Developer SQL Server 2008 R2 Enterprise SQL Server 2008 R2 Standard

Service Pack 1 für SQL Server 2014 und Service Pack 3 für SQL Server 2012 enthalten standardmäßig diesen Fix, und Sie müssen keine Ablaufverfolgungsflags hinzufügen, um den Fix zu aktivieren. Um den Fix zu aktivieren, nachdem Sie eines der kumulativen Updates im Abschnitt "Lösung" installiert haben, müssen Sie Microsoft SQL Server starten, indem Sie das Ablaufverfolgungsflag 1236 zu den Startparametern hinzufügen.

Symptome

Angenommen, Sie führen eine Instance von Microsoft SQL Server 2014, SQL Server 2012, SQL Server 2008 oder SQL Server 2008 R2 auf einem Computer mit vielen Prozessoren aus. Wenn die Anzahl der Sperren (Ressourcentyp = DATABASE) für eine bestimmte Datenbank einen bestimmten Schwellenwert überschreitet, treten die folgenden Leistungsprobleme auf:

  • Erhöhte Werte treten für LOCK_HASH Spinlockanzahl auf.

    Hinweis Im Abschnitt "Weitere Informationen" finden Sie Informationen zum Überwachen dieses Spinlocks.

  • Abfragen oder Vorgänge, die Datenbanksperren erfordern, dauern lange, um abgeschlossen zu werden. Beispielsweise können Sie die folgenden Leistungsverzögerungen feststellen:

    • SQL Server Anmeldungen
    • Abfragen von Verbindungsservern
    • sp_reset_connection
    • Transactions

Hinweis Informationen zum Auffinden der Liste der Sperren (Ressourcentyp = DATABASE) für eine bestimmte Datenbank finden Sie im Abschnitt "Weitere Informationen". Der Schwellenwert variiert je nach Umgebung.

Lösung

Informationen zum kumulativen Update

Das Problem wurde erstmals im folgenden kumulativen Update von SQL Server behoben.

Kumulatives Update 13 für SQL Server 2008 R2 SP2 /en-us/help/2967540

Kumulatives Update 17 für SQL Server 2008 SP3 /en-us/help/2958696

Kumulatives Update 1 für SQL Server 2014 /de-de/help/2931693

Kumulatives Update 9 für SQL Server 2012 SP1 /en-us/help/2931078

Informationen zu kumulativen Updates für SQL Server

Jedes neue kumulative Update für SQL Server enthält alle Hotfixes und Sicherheitsfixes, die im vorherigen kumulativen Update enthalten waren. Sehen Sie sich die neuesten kumulativen Updates für SQL Server an:

      

Hotfixinformationen
 Ein Hotfix zur Behebung des Problems ist von Microsoft erhältlich. Der Hotfix ist jedoch nur zur Behebung des in diesem Artikel beschriebenen Problems vorgesehen. Deshalb sollten Sie nur Systeme aktualisieren, bei denen dieses spezifische Problem auftritt.

Wenn der Hotfix zum Download zur Verfügung steht, finden Sie einen Abschnitt "Hotfixdownload verfügbar" oben in diesem Knowledge Base-Artikel. Wenn dieser Abschnitt nicht angezeigt wird, senden Sie eine Anfrage an den Microsoft-Kundendienst und -Support, um den Hotfix zu erhalten.

Hinweis Falls weitere Probleme auftreten oder andere Schritte zur Problembehandlung erforderlich sind, müssen Sie unter Umständen eine separate Serviceanfrage erstellen. Für zusätzliche Supportanfragen und -probleme, die sich nicht auf diesen speziellen Hotfix beziehen, fallen die üblichen Supportgebühren an. Besuchen Sie die folgende Microsoft-Website, um eine vollständige Liste der Telefonnummern von Microsoft-Kundendienst und -Support (CSS) anzuzeigen oder eine separate Serviceanfrage zu erstellen:

/contactus/?ws=support Hinweis: Das Formular "Hotfix-Download verfügbar" zeigt die Sprachen an, für die der Hotfix verfügbar ist. Wenn Ihre Sprache nicht angezeigt wird, steht der betreffende Hotfix in Ihrer Sprache nicht zur Verfügung.

Status

Microsoft hat bestätigt, dass dies ein Problem bei den Microsoft-Produkten ist, die im Abschnitt „Gilt für“ aufgeführt sind.

Weitere Informationen

Wenn eine Anwendung eine Verbindung mit SQL Server herstellt, stellt sie zuerst einen Datenbankkontext her. Standardmäßig versucht die Verbindung, eine DATABASE-Sperre im SH-Modus zu erhalten. Die SH-DATABASE-Sperre wird aufgehoben, wenn die Verbindung beendet oder der Datenbankkontext während der Lebensdauer der Verbindung geändert wird. Wenn Sie über viele aktive Verbindungen verfügen, die denselben Datenbankkontext verwenden, können Sie viele Sperren des Ressourcentyps DATABASE für diese bestimmte Datenbank haben.

Auf einem Computer mit 16 oder mehr CPUs verwenden nur Tabellenobjekte ein partitioniertes Sperrschema. Die Datenbanksperren sind jedoch nicht partitioniert. Je größer die Anzahl von Datenbanksperren ist, desto länger dauert es daher, bis SQL Server eine Sperre für die Datenbank erhält. Bei den meisten Anwendungen treten keine Probleme auf, die durch dieses Design verursacht werden. Sobald die Anzahl jedoch einen bestimmten Schwellenwert überschreitet, ist zusätzlicher Aufwand und Zeit erforderlich, um die Sperre zu erhalten. Obwohl die Kosten für jede zusätzliche Sperre nur Mikrosekunden betragen, kann sich die Gesamtzeit schnell erhöhen, da die Sperrhashbuckets durch einen Spinlock geschützt sind. Dies führt zu zusätzlichen CPU-Zyklen und Wartezeiten für zusätzliche Worker, um die Sperre zu erhalten.

Mit diesem Hotfix wird die Partitionierung von DATENBANK-Sperren eingeführt, wenn das Ablaufverfolgungsflag T1236 beim Start aktiviert ist. Durch die Partitionierung der DATABASE-Sperre bleibt die Tiefe der Sperrliste in jeder lokalen Partition überschaubar. Dadurch wird der Zugriffspfad, der zum Abrufen einer DATABASE-Sperre verwendet wird, erheblich optimiert.

Um den Spinlock der LOCK_HASH zu überwachen, können Sie die folgende Abfrage verwenden. SET NOCOUNT ON
CREATE TABLE #spinlock_stats([CaptureTime] datetime,[name] nvarchar(512),[collisions] bigint,
[spins] bigint,[spins_per_collision] real,[sleep_time] bigint,[backoffs] int)
DECLARE @counter int = 1
WÄHREND @counter< 100
      BEGIN
            EINFÜGEN IN #spinlock_stats SELECT GETDATE() as "CaptureTime" , * FROM sys.dm_os_spinlock_stats WHERE [name] = 'LOCK_HASH'
            WAITFOR DELAY '00:00:05'
            SET @counter +=1
      ENDE
SELECT * FROM #spinlock_stats ORDER BY [CaptureTime]
DROP TABLE #spinlock_stats Weitere Informationen zum Diagnostizieren und Auflösen von Spinlockkonflikten in SQL Server finden Sie im folgenden Dokument:

Diagnostizieren und Auflösen von Spinlockkonflikten auf SQL Server Hinweis Obwohl dieses Dokument für SQL Server 2008 R2 geschrieben wurde, gelten die Informationen weiterhin für SQL Server 2012.

Referenzmaterial

Weitere Informationen zu Ablaufverfolgungsflags in SQL Server 2012 finden Sie auf der folgenden TechNet-Website:

Informationen zu Ablaufverfolgungsflags in SQL Server 2012
Weitere Informationen dazu, wie Sie die Anzahl der Datenbanksperren in Benutzer pro Datenbank ermitteln, erhalten Sie mit der folgenden Abfrage, um diesen Wert zu berechnen:select Resource_database_id, resource_type, request_mode, request_status,
count (*) 'LockCount' von sys.dm_tran_locks
Gruppieren nach Resource_database_id, resource_type, request_mode request_status