|
|
Opslået på 20/07/2016 12.37.53
|
|
|
Oversigt over sluser
1. Hvorfor indføre låse
Når flere brugere udfører samtidige operationer på databasen samtidig, opstår følgende datainkonsistenser:
Manglende opdateringer
To brugere, A og B, læser de samme data og ændrer dem, og resultatet af den ene brugers ændring ødelægger resultatet af den anden ændring, såsom billetbookingssystemet
Snavset læsning
Bruger A ændrer dataene, og derefter læser bruger B dataene op, men bruger A annullerer ændringen af dataene af en eller anden grund, og dataene vender tilbage til deres oprindelige værdi
Læs ikke gentagne gange
Bruger A læser dataene, og derefter læser bruger B dataene og ændrer dem
Den vigtigste metode til samtidighedskontrol er blokering, som er at forbyde brugere at udføre bestemte operationer i en periode for at undgå datainkonsistenser
2. Klassificering af sluser
Der er to opdelinger i kategorier af sluser:
1 . Set fra databasesystemets perspektiv: det er opdelt i eksklusive låse (dvs. eksklusive låse), delte låse og opdateringslåse
MS - SQL Server bruger følgende ressourcelåsemønstre.
Beskrivelse af låsetilstand
Share(s) bruges til operationer, der ikke ændrer eller opdaterer data (skrivebeskyttede operationer), såsom SELECT-sætninger.
Update (U) bruges i opdaterbare ressourcer. Forhindrer almindelige former for deadlocks, når flere sessioner læses, låses og eventuelt en ressourceopdatering, der kan ske.
Eksklusiv (X) bruges til dataændringsoperationer, såsom INSERT, UPDATE eller DELETE. Sørg for, at flere opdateringer ikke udføres på den samme ressource på samme tid.
Intent Locks bruges til at etablere et hierarki af låse. Typerne af hensigtslåse er: Intention Shared (IS), Intent Exclusive (IX) og Intent Exclusive (SIX).
Skema-låse bruges, når operationer udføres af tabellens skema. Typerne af skemalåse er: skemamodifikation (Sch -M) og skemastabilitet (Sch -S).
Masseopdateringer (BUs) bruges, når store datamængder kopieres til en tabel, og et TABLOCK-hint angives.
Delte låse
En delt lås tillader samtidige transaktioner at læse (SELECTERE) en ressource. Når der findes en delt (S) lås på en ressource, kan ingen anden transaktion ændre dataene. Frigiv den delte (S) lås på ressourcen, så snart dataene er læst, medmindre transaktionsisolationsniveauet sættes til gentagelig eller højere, eller den delte (S) lås bevares med et låsehint i hele transaktionens levetid.
Opdateringslås
Opdateringslåse (U) forhindrer deadlocks i deres sædvanlige form. Et typisk opdateringsmønster består af en transaktion, der læser en post, får en delt (S) lås for en ressource (side eller række), og derefter ændrer en række, hvilket kræver, at låsen konverteres til en eksklusiv (X) lås. Hvis to transaktioner får en delt tilstandslås på en ressource og derefter forsøger at opdatere dataene samtidig, forsøger den ene transaktion at konvertere låsen til en eksklusiv (X) lås. Overgangen fra delt tilstand til eksklusiv lås må vente et stykke tid, fordi den eksklusive lås for én transaktion ikke er kompatibel med den delte tilstandslås for en anden transaktion; Der opstår en ventetid på sluse. Den anden transaktion forsøger at opnå en eksklusiv (X) lås til en opdatering. En deadlock opstår, fordi begge transaktioner konverteres til eksklusive (X) låse, og hver transaktion venter på, at den anden transaktion frigiver den delte tilstandslås.
For at undgå dette potentielle deadlock-problem, brug en opdateret (U)-lås. Kun én transaktion ad gangen kan få en opdateret (U) lås for en ressource. Hvis transaktionen ændrer ressourcen, konverteres opdateringslåsen (U) til en eksklusiv (X) lås. Ellers konverteres låsen til en delt lås.
Eksklusive låse
Eksklusive (X) låse forhindrer samtidige transaktioner i at få adgang til ressourcer. Andre transaktioner kan ikke læse eller ændre de data, der er låst af den eksklusive (X) lås.
Intentionslås
En intent lock angiver, at SQL Server skal erhverve en delt (S) lås eller en eksklusiv (X) lås på nogle af de underliggende ressourcer i hierarkiet. For eksempel indikerer en share-intent-lås placeret på tabelniveau, at transaktionen har til hensigt at placere en share(s)-lås på en side eller række i tabellen. At sætte en intent-lås på tabelniveau forhindrer en anden transaktion i efterfølgende at få en eksklusiv (X) lås på tabellen, der indeholder den side. Intent locks kan forbedre ydeevnen, fordi SQL Server kun tjekker intent lock på tabelniveau for at afgøre, om en transaktion sikkert kan opnå en lock på den tabel. I stedet for at tjekke låsene på hver række eller side i tabellen for at afgøre, om en transaktion kan låse hele tabellen.
Intent-låse inkluderer Intent Sharing (IS), Intent Exclusive (IX) og Intent Exclusive Sharing (SIX).
Beskrivelse af låsetilstand
Intent Sharing (IS) angiver, at transaktionens hensigt er nogle, ikke alle, af de underliggende ressourcer i læsehierarkiet ved at placere S-låse på hver ressource.
Intent Exclusive (IX) angiver, at transaktionens hensigt er at ændre nogle, men ikke alle, af de underliggende ressourcer i hierarkiet ved at placere en X-lock på hver ressource. IX er et superset af IS.
Eksklusiv deling med intention (SIX) angiver, at transaktionens hensigt er at læse alle de underliggende ressourcer i hierarkiet og ændre nogle, men ikke alle, af de underliggende ressourcer ved at placere IX-låse på hver ressource. Tillad samtidige IS-låse på topniveau-ressourcer. For eksempel placerer en tabels SIX-lås en SIX-lås på tabellen (som tillader samtidige IS-låse) og en IX-lås på den aktuelt ændrede side (en X-lås på den modificerede række). Selvom hver ressource kun kan have én SIX-lås i en periode for at forhindre andre transaktioner i at opdatere ressourcen, kan andre transaktioner læse de underliggende ressourcer i hierarkiet ved at anskaffe tabelniveau IS-låse.
Eksklusiv lås: Kun det program, der udfører låseoperationen, må bruge den, og andre operationer på den vil ikke blive accepteret. Når du udfører en dataopdateringskommando, bruger SQL Server automatisk en eksklusiv lås. Når der findes andre låse på et objekt, kan du ikke tilføje en eksklusiv lås til det.
Delt lås: Ressourcen, der er låst af den delte lås, kan læses af andre brugere, men andre brugere kan ikke ændre den.
Opdateringslås: Når SQL Server er klar til at opdatere data, låser den først dataobjektet, så dataene ikke kan ændres, men kan læses. Når SQL Server vurderer, at den vil opdatere data, vil den automatisk erstatte opdateringslåsen med en eksklusiv lås og kan ikke tilføje en opdateringslås, når der findes andre låse på objektet.
2 . Set fra programmørens synspunkt: det er opdelt i optimistisk lås og pessimistisk lås.
Optimism Lock: Er fuldstændig afhængig af databasen til at styre låsens arbejde.
Pessimistiske låse: Programmører håndterer låshåndtering på data eller objekter selv.
MS - SQLSERVER bruger låse til at implementere pessimistisk samtidighedskontrol mellem flere brugere, der foretager ændringer i databasen samtidig
3. Partikelstørrelsen af låsen
Låsegranulariteten er størrelsen på det blokerede mål, den lille blokeringsgranularitet er høj samtidighed, men overheaden er stor, og den store blokeringsgranularitet er lav samtidighed, men overheaden er lille
SQL Server understøtter låsegranularitet for rækker, sider, nøgler, nøgleområder, indekser, tabeller eller databaser
Ressourcebeskrivelse
RID-rækkeidentifikator. Plejede at låse en række i et bord enkeltvis.
Nøglerækkelås i indekset. Bruges til at beskytte nøgleområdet i serialiserbare transaktioner.
8 kilobyte (KB) datasider eller indekssider.
Udvidet disk Et sæt af otte tilstødende datasider eller indekssider.
Tabel Hele tabellen inklusive alle data og indekser.
DB-database.
4. Længden af indespærringstiden
Den tid, en lås holdes inde, er den tid, der kræves for at beskytte ressourcen på det ønskede niveau.
Holdetiden for den delte lås, der bruges til at beskytte læseoperationer, afhænger af transaktionsisolationsniveauet. Med standard transaktionsisolationsniveau READ COMMITTED kontrolleres den delte lås kun i hele read-sidens varighed. Ved en scanning frigives låsen ikke, før låsen er opnået på næste side i scanningen. Hvis du angiver en HOLDLOCK-prompt eller sætter transaktionsisolationsniveauet til REPEATABLE READ eller SERIALIZABLE, frigives låsen ikke, før transaktionen slutter.
Afhængigt af samtidighedsindstillingen for markøren kan markøren opnå en scroll lock i delt tilstand for at beskytte udtrækket. Når en scroll lock er nødvendig, frigives scroll lock først næste gang, markøren udtrækkes eller lukkes, alt efter hvad der sker først. Men hvis du angiver en HOLDLOCK, frigives scroll-låsen først ved transaktionens afslutning.
Den eksklusive lås, der bruges til at beskytte opdateringen, vil ikke blive frigivet før transaktionens afslutning.
Hvis en forbindelse forsøger at opnå en lås, der er i konflikt med en lås kontrolleret af en anden forbindelse, vil forbindelsen, der forsøger at få fat i låsen, blive blokeret, indtil:
Den modstridende lås frigives, og forbindelsen får den anmodede lås.
Forbindelsestimeouten er udløbet. Der er som standard ikke noget timeout-interval, men nogle apps sætter timeout-intervaller for at forhindre ubegrænset ventetid
Fem tilpasninger af låse i SQL Server
1 Håndter deadlocks og sæt deadlock-prioriteter
Deadlock er den endeløse ventetid, som flere brugere forårsager ved at ansøge om forskellige blokeringer, fordi ansøgeren har en del af blokeringsretten og venter på den delvise blokering, som tilhører andre brugere
Du kan bruge SET-DEADLOCK_PRIORITY til at styre, hvordan sessionen reagerer i tilfælde af en deadlock-tilstand. Hvis begge processer låser dataene, og hver proces ikke kan frigive sin egen lås, før den anden proces frigiver sin egen lås, opstår der en deadlock-situation.
2 Håndter timeouts og sæt lock-timeout-varigheder.
@@LOCK_TIMEOUT Returnerer den aktuelle låse-timeout-indstilling for den aktuelle session i millisekunder
SET LOCK_TIMEOUT-indstillingen tillader applikationen at sætte den maksimale tid, som sætningen venter på at blokere ressourcen. Når ventetiden for sætningen er længere end den LOCK_TIMEOUT indstilling, annullerer systemet automatisk blokeringssætningen og sender applikationen en fejlmeddelelse på 1222 om, at låseanmodningens timeout-periode er overskredet
eksempel
I det følgende eksempel er låsetidsudløbsperioden sat til 1.800 millisekunder.
SÆT LOCK_TIMEOUT1800
3) Sæt transaktionsisolationsniveauet.
4) Brug tabelniveau-låsehints til SELECT, INSERT, UPDATE og DELETE-sætninger.
5) Konfigurer låsegranulariteten af indekset
Du kan bruge sp_indexoption systemlagrede procedurer til at sætte låsegranulariteten for indeksering
6. Se oplysningerne om slusen
1 Udfør EXEC SP_LOCK rapporter information om låsen
2 Tryk Ctrl + 2 i forespørgselsanalysatoren for at se informationen om låsen
7. Forholdsregler for brug
Sådan undgår du fastlåste situationer
1. Når du bruger transaktioner, prøv at forkorte den logiske behandlingsproces for transaktioner og indsend eller rulle transaktioner tilbage tidligt.
2 Sæt deadlock-timeout-parameteren til et rimeligt interval, såsom: 3 minutter - 10 minutter; Efter tiden vil operationen automatisk blive opgivet for at undgå, at processen hænger op;
3. Optimer programmet, tjek og undgå fænomenet deadlock;
4. Test alle scripts og SP'er grundigt før den præcise version.
5 Alle SP'er skal have fejlhåndtering (via @error)
6 Ændr ikke standardniveauet for SQL SERVER-transaktioner. Tvangslåsning anbefales ikke
Løs problemet Sådan låser man en række tabel-database
8. Flere spørgsmål om låse
1 Hvordan man låser en række i et bord
SÆT TRANSAKTIONSISOLATIONSNIVEAU READUNCOMMITTED
SELECT *FROM table ROWLOCKWHERE id = 1
2 Lås en tabel i databasen
VÆLG *FRA tabel MED( HOLDLOCK )
Låseerklæring:
sybase:
Opdateringstabel sæt kol1 = kol1 hvor1= 0 ;
MSSQL:
vælg kol1 fra tabel (tablockx), hvor 1= 0 ;
oracle:
LÅSEBORDTABEL I EKSKLUSIV TILSTAND ;
Efter låsen er låst, kan ingen andre betjene den, før den låste bruger låser den op, og den låses op med commit eller rollback
Et par eksempler hjælper dig med at uddybe dit indtryk
Sæt bord1(A,B,C)
A B C
a1 b1 c1
A2 B2 C2
a3 b3 c3
1) Eksklusiv lås
Skab to nye forbindelser
Udfør følgende udstrækning i den første forbindelse
Start Tran
Opdatering tabel1
sæt A= ' aa '
hvor B= ' b2 '
vent på forsinkelse' 00:00:30' --vent 30 sekunder
commit tran
Udfør følgende udsagn i den anden forbindelse
Start Tran
Vælg *fra tabel1
hvor B= ' b2 '
commit tran
Hvis de to ovenstående sætninger udføres samtidig, skal select-forespørgslen vente på, at opdateringen bliver udført, det vil sige vente 30 sekunder
2) Delt lås
Udfør følgende udstrækning i den første forbindelse
Start Tran
vælg *fra tabel1 holdlock - holdlocken tilføjes kunstigt til locken
hvor B= ' b2 '
vent på forsinkelse' 00:00:30' --vent 30 sekunder
commit tran
Udfør følgende udsagn i den anden forbindelse
Start Tran
vælg A,C fra tabel1
hvor B= ' b2 '
Opdatering tabel1
sæt A= ' aa '
hvor B= ' b2 '
commit tran
Hvis de to ovenstående sætninger udføres samtidig, kan select-forespørgslen i den anden forbindelse udføres
Opdateringen skal vente på den første transaktion for at frigive den delte lås og konvertere den til en eksklusiv lås, før den kan udføres, det vil sige vente 30 sekunder
3) Dødvande
Tilføjet tabel2(D,E)
D E
d1 e1
d2 e2
Udfør følgende udstrækning i den første forbindelse
Start Tran
Opdatering tabel1
sæt A= ' aa '
hvor B= ' b2 '
vent på forsinkelse' 00:00:30'
Opdatering tabel2
sæt D= ' d5 '
hvor E= ' e1 '
commit tran
Udfør følgende udsagn i den anden forbindelse
Start Tran
Opdatering tabel2
sæt D= ' d5 '
hvor E= ' e1 '
vent på forsinkelse' 00:00:10'
Opdatering tabel1
sæt A= ' aa '
hvor B= ' b2 '
commit tran
Samtidig registrerer systemet deadlocken og afbryder processen
For at tilføje:
Tabelniveau-låsehints understøttet af SQL Server 2000
HOLDLOCK holder den delte lås, indtil hele transaktionen er fuldført, og bør frigives, så snart det låste objekt ikke længere er nødvendigt, svarende til SERIALIZABLE-transaktionsisolationsniveauet
NOLOCK-udsagnet udføres uden at udstede en delt lås, hvilket tillader beskidte læsninger, hvilket svarer til READ UNCOMMITTED transaktionsisolationsniveauet
PAGLOCK bruger flere sidelåse, hvor én tabellås bruges
READPAST lader SQL-serveren springe alle låste linjer over og udføre transaktioner, og for READ UNCOMMITTED transaktionsisolationsniveauer kun springe RID-låse over, ikke side-, zone- og tabellåse
ROWLOCK håndhæver brugen af rowlocks
TABLOCKX håndhæver brugen af en eksklusiv tabel-niveau lås, som forhindrer andre transaktioner i at bruge tabellen under transaktionen
UPLOCK tvinger brugen af opdateringer, når man læser en tabel uden en delt lås
App-lås:
En applikationslås er en lås genereret af klientkode, ikke en lås genereret af SQL Server selv
To processer til håndtering af applikationslåse
sp_getapplock Låse-applikationsressourcer
sp_releaseapplock Lås op for applikationsressourcerne
Bemærk: Forskellen på at låse en tabel i en database
VÆLG *FRA tabel MED( HOLDLOCK ) Andre transaktioner kan læse tabellen, men kan ikke opdatere og slette
VÆLG *FRA tabellen WITH(TABLOCKX) Andre transaktioner kan ikke læse, opdatere og slette tabellen
|
Tidligere:Der var ikke noget slutpunkt, der lyttede http://localhost:111/xxx.svc den k...Næste:SQL locks NOLOCK, HOLDLOCK, UPDLOCK, TABLOCK, TABLOCKX
|
