Som standard innehåller Service Pack 1 för SQL Server 2014 och Service Pack 3 för SQL Server 2012 den här korrigeringen och du behöver inte lägga till några spårningsflaggor för att aktivera korrigeringen. Om du vill aktivera korrigeringen efter att du har installerat en av de kumulativa uppdateringarna i avsnittet Upplösning måste du starta Microsoft SQL Server genom att lägga till spårningsflagga 1236 till startparametrarna.
Symptom
Anta att du kör en instans av Microsoft SQL Server 2014, SQL Server 2012, SQL Server 2008 eller SQL Server 2008 R2 på en dator som innehåller många processorer. När antalet lås (resurstyp = DATABASE) för en viss databas överskrider ett visst tröskelvärde uppstår följande prestandaproblem:
Förhöjda värden uppstår för LOCK_HASH antal spinlocks.
Se avsnittet "Mer information" för information om hur du övervakar detta spinlock.
Det tar lång tid att slutföra frågor eller åtgärder som kräver databaslås. Du kanske till exempel märker följande prestandafördröjningar:
- Inloggningar på SQL Server
- Länkade serverfrågor
- sp_reset_connection
- Transaktioner
Anteckning Information om hur du hittar listan över lås (resurstyp = DATABASE) på en viss databas finns i avsnittet "Mer information". Tröskelvärdet varierar beroende på miljö.
Lösning
Information om kumulativ uppdatering
Problemet åtgärdades först i följande kumulativa uppdatering av SQL Server.
Kumulativ uppdatering 13 för SQL Server 2008 R2 SP2 /en-us/help/2967540
Kumulativ uppdatering 17 för SQL Server 2008 SP3 /en-us/help/2958696
Kumulativ uppdatering 1 för SQL Server 2014 /en-us/help/2931693
Kumulativ uppdatering 9 för SQL Server 2012 SP1 /en-us/help/2931078
Om kumulativa uppdateringar för SQL Server
Varje ny kumulativ uppdatering för SQL Server innehåller alla snabbkorrigeringar och alla säkerhetskorrigeringar som ingick i den tidigare kumulativa uppdateringen. Kolla in de senaste kumulativa uppdateringarna för SQL Server:
- Senaste kumulativa uppdateringen för SQL Server 2008 R2 SP2
- Senaste kumulativa uppdateringen för SQL Server 2008 SP3
- Senaste kumulativa uppdateringen för SQL Server 2014
- Senaste kumulativa uppdateringen för SQL Server 2012 SP1
Information om snabbkorrigeringar
En snabbkorrigering som stöds är tillgänglig från Microsoft. Den här snabbkorrigeringen är dock endast avsedd att åtgärda det problem som beskrivs i den här artikeln. Använd endast den här snabbkorrigeringen på system som har det här specifika problemet.
Om snabbkorrigeringen kan laddas ned finns avsnittet "Nedladdning av snabbkorrigering" längst upp i den här kunskapsbasartikeln. Om det här avsnittet inte visas skickar du en förfrågan till Microsofts kundtjänst och support för att hämta snabbkorrigeringen.
Om ytterligare problem uppstår eller om någon felsökning krävs kan du behöva skapa en separat servicebegäran. Normala supportkostnader tas ut för ytterligare supportfrågor och problem som inte kvalificerar sig för den här specifika snabbkorrigeringen. En fullständig lista över telefonnummer till Microsofts kundtjänst och support eller om du vill skapa en separat servicebegäran finns på följande Microsoft-webbplats:
/contactus/?ws=support Obs! Formuläret "Nedladdning av snabbkorrigering tillgänglig" visar de språk som snabbkorrigeringen är tillgänglig för. Om ditt språk inte visas beror det på att det inte finns någon snabbkorrigering för det språket.
Status
Microsoft har bekräftat att detta är ett problem i de Microsoft-produkter som anges i avsnittet "Gäller".
Mer information
När ett program ansluter till SQL Server upprättas först en databaskontext. Som standard kommer anslutningen att försöka få ett DATABASE-lås i SH-läge. SH-DATABASE-låset frigörs när anslutningen stoppas eller databaskontexten ändras under anslutningens livslängd. Om du har många aktiva anslutningar som använder samma databaskontext kan du ha många lås av resurstypen DATABASE för den specifika databasen.
På en dator med minst 16 CPU:er använder endast tabellobjekt ett partitionerat låsschema. Databaslåsen partitioneras dock inte. Ju större antal databaslås, desto längre tid tar det därför för SQL Server att få ett lås på databasen. De flesta program upplever inga problem som orsakas av denna design. Men så snart antalet överstiger ett visst tröskelvärde krävs ytterligare arbete och tid för att få låset. Även om kostnaden bara är mikrosekunder för varje ytterligare lås kan den totala tiden snabbt öka eftersom låshash-bucketarna skyddas med hjälp av ett spinlock. Detta orsakar ytterligare CPU-cykler och väntar på att ytterligare arbetare ska få låset.
Den här snabbkorrigeringen introducerar partitionering av DATABASLÅS när spårningsflagga T1236 är aktiverad vid start. Genom att partitionera DATABASE-låset kan låslistans djup hanteras i varje lokal partition. Detta optimerar avsevärt åtkomstsökvägen som används för att hämta ett DATABASE-lås.
Om du vill övervaka LOCK_HASH spinlock kan du använda följande fråga. STÄLL IN 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
MEDAN @counter< 100
BEGIN
INSERT I #spinlock_stats SELECT GETDATE() as "CaptureTime", * FROM sys.dm_os_spinlock_stats WHERE [name] = 'LOCK_HASH'
VÄNTA PÅ DELAY '00:00:05'
SÄTT @counter +=1
END
SELECT * FROM #spinlock_stats ORDER BY [CaptureTime]
SLÄPPTABELL #spinlock_stats Mer information om hur du diagnostiserar och löser spinlock-konkurrens på SQL Server finns i följande dokument:
Diagnostisera och lösa spinlock-konkurrens på SQL Server Anteckning Även om det här dokumentet är skrivet för SQL Server 2008 R2, gäller informationen fortfarande för SQL Server 2012.
Referenser
Mer information om spårningsflaggor i SQL Server 2012 finns på följande TechNet-webbplats:
Information om spårningsflaggor i SQL Server 2012
Om du vill ha mer information om hur du hittar antalet databaslås i användare per databas använder du följande fråga för att beräkna det här värdet:select Resource_database_id, resource_type, request_mode, request_status,
count (*) 'LockCount' från sys.dm_tran_locks
Gruppera efter Resource_database_id, resource_type, request_mode request_status