Hantera transaktioner samtidigt med lås i SQL Server

I en miljö med flera användare är det viktigt att bibehålla trunkering samtidigt. Dessa lås är strukturer i minnet med en storlek på 96 byte. Deras roll är att upprätthålla dataintegritet, konsistens, samtidighetskontroll för varje transaktion. SQL Server följer ACID-testet för varje transaktion.

A tomicity:Den här egenskapen säkerställer att en transaktion som involverar två eller flera processer genomförs fullt ut, eller att ingen av processerna är genomförd.
C onsistency:Det ger dig en garanti om det engagerade transaktionsläget. En transaktion bör antingen skapa ett nytt datatillstånd eller återgå till det befintliga (före transaktionen) tillstånd.
Jag solation:Det indikerar att transaktioner är isolerade från varandra. Om en transaktion körs och den inte överförde data, är den isolerad från andra transaktioner.
D urability:Hållbarheten säkerställer att dina engagerade data aldrig går förlorade. Det förhindrar ström- och operativsystemfel, eller andra programvaruinducerade fel.

För att säkerställa ACID-egenskaper lägger SQL Server olika typer av lås på objekten. I det här fallet måste andra transaktioner vänta tills låset släpps.

Låslägen

SQL Server använder följande låsningslägen för varje transaktion.

Delade lås:
- I det här låset gör SQL Server att andra sessioner kan utföra de valda operationerna för att läsa data. Det förhindrar dock uppdateringar tills låset är aktivt.
- Flera transaktioner kan införa ett delat lås samtidigt på en rad eller sida.
- Det är ett vanligt lås som du ser på dina databasobjekt.

I följande T-SQL hämtar vi kundposten för ett specifikt kund-ID. Vidare använder vi dynamisk hanteringsvy sys.dm_tran_locks för att kontrollera befintliga lås.

BEGIN TRAN
SELECT * FROM [SalesLT].[Customer] WITH (HOLDLOCK)
WHERE CustomerID=1
    
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type <> 'DATABASE'

ROLLBACK

Som visas nedan har den ett delat lås på det givna resurs-id:t (8194443284a0):

Exklusiva (X) lås:
- SQL Server använder exklusivt lås (X) för DML-operationer (radera, infoga eller uppdatera), vilket kräver ändring av en rad- eller siddata.
- Det förhindrar andra användningsområden från att komma åt resursen tills ett lås har placerats.
- SQL Server kan bara ha ett exklusivt lås på en sida eller rad för en transaktion.

I det här exemplet vill vi uppdatera poster för kund-id 1. Därför kräver SQL Server ett exklusivt lås på resursen. Ingen annan transaktion kan få det exklusiva låset på denna resurs förrän transaktionen är slutförd.

BEGIN TRAN
UPDATE [SalesLT].[Customer] 
SET Suffix='Mr.'  
WHERE CustomerID=1
    
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type <> 'DATABASE'

ROLLBACK

Uppdatera (U) lås:
- Uppdateringslåset liknar ett exklusivt lås. Den kan placeras på en post som har ett delat lås.
- Uppdateringslåset placerar ett annat delat lås på en specifik rad. När den kan modifiera posterna konverterar SQL Server uppdateringslåset till ett exklusivt lås.
- SQL Server kan inte placera ett delat lås på en resurs med ett uppdateringslås.
- Du kan också använda MED UPDLOCK för att tvinga fram ett uppdateringslås.

Följande exempel visar ett uppdateringslås på resurs-id:t (8194443284a0):

BEGIN TRAN
SELECT * FROM [SalesLT].[Customer] WITH (UPDLOCK)
WHERE CustomerID=1
    
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type <> 'DATABASE'

ROLLBACK

Avsiktslås:
- Dess syfte är att informera en transaktion om dess avsikt att skaffa ett lås. Det inträffar när en transaktion kräver ett delat eller exklusivt lås på resurserna lägre i hierarkin.
- Transaktionen tillåter inte att andra transaktioner får ett exklusivt lås på bordet med ett avsiktslås.
- Typer av avsiktslås finns nedan.
  - Intent Shared (IS)-lås:Det indikerar SQL Server-avsikt att läsa lägre hierarkiresurser genom att skaffa delat lås individuellt på dessa lägre hierarkiresurser.
  - Intent Exclusive (IX)-lås:Det indikerar SQL Server-avsikt att modifiera lägre hierarkiresurser genom att erhålla ett exklusivt lås på dessa lägre hierarkiresurser.
  - Ett avsiktsuppdateringslås (IU):Det kan endast erhållas på sidnivå för lägre hierarkiska resurser, och när uppdateringen är klar konverteras den till IX-lås.

Som visas nedan har transaktionen ett exklusivt lås på en nyckel, och det har ett exklusivt Intent-lås på sidnivå.

Konverteringslås

SQL Server konverterar låstyper för att stödja flera frågor i en transaktion. Dessa lås är kända som konverteringslås.

SIX – Delat med avsikt Exklusivt lås:SQL Server-transaktionen har ett delat lås på flera sidor och har ett exklusivt lås på flera rader.
SIU – SQL Server-transaktionen har ett delat lås på flera sidor och har en uppdatering lås på flera rader.
UIX- Uppdatering med Exklusivt Avsiktslås:SQL Server-transaktionen har ett Uppdateringslås på flera sidor och har ett Exklusivt lås på flera rader.

Schemalås

SQL Server skaffar två typer av schemalås.

Schemastabilitetslås (Sch-S):Detta lås används när schemaberoende fråga kompileras och dess exekveringsplan genereras. Sch-S-låset blockerar inte någon åtkomst till objektdata.
Schema modification lock (Sch-M):Det här låset är resultatet av en DDL (Data Definition Language)-förfrågan. SQL Server kan bara ha ett schemamodifieringslås på ett objekt. Du kan inte ändra ett objekt med detta schemalås.

I exemplet nedan får vi både Sch-S- och Sch-M-lås när vi ändrar en objektdefinition.

BEGIN TRAN
Alter TABLE DemoTable ADD new bit
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type <> 'DATABASE'
ROLLBACK

Låskompatibilitet

Låskompatibiliteten är användbar för att kontrollera tillåtna lås i händelse av flera transaktioner i samma resurs samtidigt. Om en transaktion placerar ett lås, bör det nya låset som placerats av en annan transaktion vara kompatibelt med det. Därför kan du gå igenom följande låskompatibilitetslista och hitta lås som stöds under flera transaktioner.

Lås upptrappningar

SQL Server introducerade en låseskaleringsfunktion för att förhindra för mycket låsning som kan orsaka minnestryck. SQL Server överväger antalet lås som hålls på en viss genomsökning och antalet lås som hålls av hela transaktionen och minnet dynamiskt. SQL Server konverterar lågnivålås till högnivålås vid låseskalering. Till exempel konverterar den radlås till lås på sidnivå.

Den använder följande tröskel för låseskalering.

Minneströskel: Låsminnets tröskel är satt till 40 procent av låsminnet.
Låströskel: Om antalet låsningar som förvärvats i den aktuella tabellen eller indexet är större än 5 000 kan låseskaleringar utlösas.

Användare kan kontrollera låseskaleringar med hjälp av alter table-satsen. Du kan helt inaktivera låseskaleringen för den tabellen med ett parametervärde DISABLE.

ALTER TABLE Table_name SET (LOCK_ESCALATION = < TABLE | AUTO | DISABLE > –One of those options) GO

Du kan hänvisa till Microsoft-dokumentationen för att förstå låseskalationer i detalj.

Obs! Du bör inte inaktivera låseskalering förrän den är noggrant testad i en lägre miljö, och den rekommenderas endast att använda av erfarna DBA:er.

Slutsats

Den här artikeln ger en detaljerad översikt över SQL Server-lås och DMV för att övervaka låset och dess eskaleringsprocess. Låsning är ganska normalt beteende i SQL Server, och du bör vara bekant med det för att förstå hur flera transaktioner fungerar, simulerar och tillhandahåller konsekventa data.