Administrer transaktionssammenfald ved hjælp af låse i SQL Server

I et flerbrugermiljø er det vigtigt at opretholde trunkeringssamtidig. Disse låse er strukturer i hukommelsen på 96 bytes i størrelse. Deres rolle er at opretholde dataintegritet, konsistens og samtidighedskontrol for hver transaktion. SQL Server følger ACID-testen for hver transaktion.

• A tomicity:Denne egenskab sikrer, at en transaktion, der involverer to eller flere processer, er forpligtet fuldt ud, eller ingen af ​​processerne er forpligtet.
• C onsistency:Det giver dig en garanti om den forpligtede transaktionstilstand. En transaktion skal enten oprette en ny datatilstand eller vende tilbage til den eksisterende (før transaktionen) tilstand.
• I solation:Det indikerer, at transaktioner er isoleret fra hinanden. Hvis en transaktion kører, og den ikke har overført data, er den isoleret fra andre transaktioner.
• D urability:Holdbarheden sikrer, at dine forpligtede data aldrig går tabt. Det forhindrer strøm- og operativsystemfejl eller andre software-inducerede fejl.

For at sikre ACID-egenskaber pålægger SQL Server forskellige slags låse på objekterne. I dette tilfælde skal andre transaktioner vente, indtil låsen udløses.

Låsetilstande

SQL Server bruger følgende låsetilstande for hver transaktion.

• Delte låse:
  • I denne lås giver SQL Server andre sessioner mulighed for at udføre de valgte handlinger til læsning af data. Det forhindrer dog opdateringer, indtil låsen er aktiv.
  • Flere transaktioner kan pålægge en delt lås på samme tid på en række eller side.
  • Det er en almindelig lås, som du ser på dine databaseobjekter.

I den følgende T-SQL henter vi kunderegistreringen for et specifikt kunde-id. Yderligere bruger vi dynamisk administrationsvisning sys.dm_tran_locks til at kontrollere de eksisterende låse.

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 vist nedenfor har den en delt lås på det givne ressource-id (8194443284a0):

• Eksklusive (X) låse:
  • SQL Server bruger eksklusiv lås (X) til DML-handlinger (Slet, Indsæt eller Opdater), hvilket kræver ændring af en række- eller sidedata.
  • Det forhindrer andre anvendelser i at få adgang til ressourcen, indtil en lås er placeret.
  • SQL Server kan kun have én eksklusiv lås på en side eller række for en transaktion.

I dette eksempel ønsker vi at opdatere poster for kunde-id 1. Derfor kræver SQL Server en eksklusiv lås på ressourcen. Ingen anden transaktion kan erhverve den eksklusive lås på denne ressource, før transaktionen er gennemført.

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

• Opdatering (U) låse:
  • Opdateringslåsen ligner en eksklusiv lås. Det kan placeres på en post med en delt lås.
  • Opdateringslåsen placerer en anden delt lås på en bestemt række. Når den kan ændre posterne, konverterer SQL Server opdateringslåsen til en eksklusiv lås.
  • SQL-serveren kan ikke placere en delt lås på en ressource med en opdateringslås.
  • Du kan også bruge MED UPDLOCK til at tvinge en opdateringslås.

Følgende eksempel viser en opdateringslås på ressource-id'et (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

• Formålslåse:
  • Dets formål er at informere en transaktion om dens hensigt om at erhverve en lås. Det opstår, når en transaktion kræver en delt eller eksklusiv lås på ressourcerne nederst i hierarkiet.
  • Transaktionen tillader ikke, at andre transaktioner får en eksklusiv lås på bordet ved hjælp af en hensigtslås.
  • Typer af hensigtslåse er nedenfor.
    • Intent Shared (IS)-lås:Det angiver SQL Server-hensigt om at læse lavere hierarki-ressourcer ved at erhverve delt lås individuelt på disse lavere hierarki-ressourcer.
    • Intent Exclusive (IX) lås:Det angiver SQL Servers hensigt om at ændre lavere hierarki-ressourcer ved at opnå en eksklusiv lås på disse lavere hierarki-ressourcer.
    • En hensigtsopdateringslås (IU):Den kan kun erhverves på sideniveau for lavere hierarkiske ressourcer, og når opdateringen er fuldført, konverteres den til IX-lås.

Som vist nedenfor har transaktionen en eksklusiv lås på en nøgle, og den har en Intent-eksklusiv lås på sideniveau.

Konverteringslåse

SQL Server konverterer låsetyper til at understøtte flere forespørgsler i en transaktion. Disse låse er kendt som konverteringslåse.

• SIX – Delt med hensigt Eksklusiv lås:SQL Server-transaktionen har en delt lås på flere sider og har en eksklusiv lås på flere rækker.
• SIU – SQL Server-transaktionen har en delt lås på flere sider og har en opdatering lås på flere rækker.
• UIX- Opdatering med Intent Exclusive Lock:SQL Server-transaktionen har en Update-lås på flere sider og har en Eksklusiv lås på flere rækker.

Skemalåse

SQL Server anskaffer to slags skemalåse.

• Skemastabilitetslås (Sch-S):Denne lås bruges, når skemaafhængig forespørgsel kompileres, og dens eksekveringsplan genereres. Sch-S-låsen blokerer ikke nogen adgang til objektdataene.
• Skemamodifikationslås (Sch-M):Denne lås er et resultat af en DDL (Data Definition Language)-forespørgselsudførelse. SQL Server kan kun have én skemaændringslås på et objekt. Du kan ikke ændre et objekt med denne skemalås.

I eksemplet nedenfor får vi både Sch-S og Sch-M låse, mens vi ændrer 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åsekompatibilitet

Låsekompatibiliteten er nyttig til at kontrollere tilladte låse i tilfælde af flere transaktioner i den samme ressource samtidigt. Hvis en transaktion placerer en lås, skal den nye lås, der er placeret af en anden transaktion, være kompatibel med den. Derfor kan du gå gennem følgende låsekompatibilitetsliste og finde understøttede låse under flere transaktioner.

Lås eskaleringer

SQL Server introducerede en låseskaleringsfunktion for at forhindre for meget låsning, der kunne forårsage hukommelsestryk. SQL Server vurderer antallet af låse, der holdes på en bestemt scanning, og antallet af låse, der holdes af hele transaktionen og hukommelsen, dynamisk. SQL Server konverterer låse på lavt niveau til låse på højt niveau i låseeskalering. For eksempel konverterer den rækkelåse til låse på sideniveau.

Den bruger følgende tærskel for låseeskaleringer.

• Hukommelsesgrænse: Låsehukommelsestærsklen er sat til 40 procent af låsehukommelsen.
• Låsegrænse: Hvis antallet af opnåede låse på den aktuelle tabel eller indeks er større end 5000, kan låseeskaleringer udløses.

Brugere kan kontrollere låseeskaleringer ved hjælp af alter table-sætningen. Du kan fuldstændigt deaktivere låseeskaleringen for den tabel ved hjælp af en parameterværdi DISABLE.

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

Du kan henvise til Microsoft-dokumentationen for at forstå låseeskaleringer i detaljer.

Bemærk:Du bør ikke deaktivere låseeskalering, før den er grundigt testet i et lavere miljø, og det anbefales kun at bruge af erfarne DBA'er.

Konklusion

Denne artikel giver et detaljeret overblik over SQL Server-låse og DMV til at overvåge låsen og dens eskaleringsproces. Låsning er ganske normal adfærd i SQL Server, og du bør være bekendt med det for at forstå, hvordan flere transaktioner fungerer, simulerer og leverer ensartede data.