|
|
Publisert på 20.07.2016 12:37:53
|
|
|
Oversikt over sluser
1. Hvorfor introdusere låser
Når flere brukere utfører samtidige operasjoner på databasen samtidig, oppstår følgende datainkonsistenser:
Manglende oppdateringer
To brukere, A og B, leser de samme dataene og endrer dem, og resultatet av én brukers endring ødelegger resultatet av den andre endringen, som for eksempel billettbestillingssystemet
Skitten lesning
Bruker A endrer dataene, og så leser bruker B opp dataene, men bruker A kansellerer endringen av dataene av en eller annen grunn, og dataene returnerer til sin opprinnelige verdi
Ikke les gjentatte ganger
Bruker A leser dataene, og deretter leser og endrer bruker B dataene
Hovedmetoden for samtidighetskontroll er blokkering, som er å forby brukere å utføre visse operasjoner i en periode for å unngå datainkonsistenser
2. Klassifisering av sluser
Det finnes to inndelinger i kategorier av sluser:
1 . Fra databasesystemets perspektiv: det er delt inn i eksklusive låser (dvs. eksklusive låser), delte låser og oppdateringslåser
MS - SQL Server bruker følgende ressurslåsmønstre.
Beskrivelse av låsemodus
Share(s) brukes for operasjoner som ikke endrer eller oppdaterer data (skrivebeskyttede operasjoner), som SELECT-setninger.
Update (U) brukes i oppdaterbare ressurser. Forhindrer vanlige former for deadlocks når flere økter leses, låses, og eventuelt en ressursoppdatering som kan skje.
Eksklusiv (X) brukes for dataendringsoperasjoner, som INSERT, UPDATE eller DELETE. Sørg for at flere oppdateringer ikke utføres på samme ressurs samtidig.
Intensjonslås brukes for å etablere et hierarki av låser. Typene intensjonslåser er: Intensjonsdelt (IS), Intensjonseksklusiv (IX) og Intensjonseksklusiv (SIX).
Skjemalåser brukes når man utfører operasjoner som avhenger av tabellens skjema. Typene skjemalåser er: skjemamodifikasjon (Sch -M) og skjemastabilitet (Sch -S).
Bulkoppdateringer (BU) brukes når store datamengder kopieres til en tabell og et TABLOCK-hint er spesifisert.
Delte sluser
En shared(s)-lås tillater samtidige transaksjoner å lese (SELECTE) en ressurs. Når en delt (S) lås finnes på en ressurs, kan ingen annen transaksjon endre dataene. Slipp den delte (S)-låsen på ressursen så snart dataene er lest, med mindre transaksjonsisolasjonsnivået settes til repeterbart eller høyere, eller den delte (S)-låsen beholdes med et låsehint gjennom hele transaksjonens levetid.
Oppdateringslås
Oppdateringslåser (U) forhindrer fastlåser i sin vanlige form. Et typisk oppdateringsmønster består av en transaksjon som leser en post, får en delt (S) lås for en ressurs (side eller rad), og deretter endrer en rad, noe som krever at låsen konverteres til en eksklusiv (X) lås. Hvis to transaksjoner får en delt modus-lås på en ressurs og deretter prøver å oppdatere dataene samtidig, forsøker én transaksjon å konvertere låsen til en eksklusiv (X) lås. Overgangen fra delt modus til eksklusiv lås må vente en stund fordi den eksklusive låsen til én transaksjon ikke er kompatibel med delt modus-låsen til en annen transaksjon; En ventetid på sluse oppstår. Den andre transaksjonen forsøker å oppnå en eksklusiv (X) lås for en oppdatering. En deadlock oppstår fordi begge transaksjonene konverteres til eksklusive (X) låser, og hver transaksjon venter på at den andre transaksjonen skal frigjøre delte modus-låsen.
For å unngå dette potensielle deadlock-problemet, bruk en oppdatert (U)-lås. Kun én transaksjon om gangen kan få en oppdatert (U)-lås for en ressurs. Hvis transaksjonen endrer ressursen, konverteres oppdateringslåsen (U) til en eksklusiv (X) lås. Ellers konverteres låsen til en delt lås.
Eksklusive låser
Eksklusive (X) låser hindrer samtidige transaksjoner i å få tilgang til ressurser. Andre transaksjoner kan ikke lese eller endre dataene som er låst av den eksklusive (X) låsen.
Intensjonslås
En intensjonslås indikerer at SQL Server må skaffe seg en delt (S) lås eller en eksklusiv (X) lås på noen av de underliggende ressursene i hierarkiet. For eksempel indikerer en share-intent-lås plassert på tabellnivå at transaksjonen har til hensikt å plassere en share(s)-lås på en side eller rad i tabellen. Å sette en intensjonslås på tabellnivå forhindrer at en annen transaksjon senere får en eksklusiv (X) lås på tabellen som inneholder den siden. Intensjonslåser kan forbedre ytelsen fordi SQL Server kun sjekker intensjonslåsen på tabellnivå for å avgjøre om en transaksjon trygt kan få en lås på den tabellen. I stedet for å sjekke låsene på hver rad eller side i tabellen for å avgjøre om en transaksjon kan låse hele tabellen.
Intensjonslåser inkluderer Intensjonsdeling (IS), Intensjonseksklusiv (IX) og Intensjonseksklusiv deling (SIX).
Beskrivelse av låsemodus
Intensjonsdeling (IS) indikerer at transaksjonens intensjon er noen, ikke alle, av de underliggende ressursene i lesehierarkiet ved å plassere S-låser på hver ressurs.
Intensjonseksklusiv (IX) indikerer at transaksjonens intensjon er å endre noen, men ikke alle, av de underliggende ressursene i hierarkiet ved å plassere en X-lås på hver ressurs. IX er et supersett av IS.
Eksklusiv deling med intensjon (SIX) indikerer at transaksjonens hensikt er å lese alle de underliggende ressursene i hierarkiet og endre noen, men ikke alle, av de underliggende ressursene ved å plassere IX-låser på hver ressurs. Tillat samtidige IS-låser på toppnivåressurser. For eksempel plasserer en tabells SIX-lås en SIX-lås på tabellen (som tillater samtidige IS-låser) og en IX-lås på den for øyeblikket modifiserte siden (en X-lås på den modifiserte raden). Selv om hver ressurs bare kan ha én SIX-lås i en periode for å hindre at andre transaksjoner oppdaterer ressursen, kan andre transaksjoner lese de underliggende ressursene i hierarkiet ved å skaffe tabellnivå IS-låser.
Eksklusiv lås: Kun programmet som utfører låseoperasjonen får bruke den, og andre operasjoner på den vil ikke bli akseptert. Når du kjører en dataoppdateringskommando, bruker SQL Server automatisk en eksklusiv lås. Når andre låser finnes på et objekt, kan du ikke legge til en eksklusiv lås på det.
Delt lås: Ressursen som låses av den delte låsen kan leses av andre brukere, men andre brukere kan ikke endre den.
Oppdateringslås: Når SQL Server er klar til å oppdatere data, låser den først dataobjektet slik at dataene ikke kan endres, men kan leses. Når SQL Server bestemmer at den vil oppdatere data, vil den automatisk erstatte oppdateringslåsen med en eksklusiv lås, og kan ikke legge til en oppdateringslås når andre låser finnes på objektet.
2 . Fra programmererens synspunkt: det er delt inn i optimistisk lås og pessimistisk lås.
Optimismelås: Er helt avhengig av databasen for å administrere låsens arbeid.
Pessimistiske låser: Programmerere håndterer låshåndtering på data eller objekter selv.
MS - SQLSERVER bruker låser for å implementere pessimistisk samtidighetskontroll mellom flere brukere som utfører endringer i databasen samtidig
3. Partikkelstørrelsen til låsen
Låsegranulariteten er størrelsen på det blokkerte målet, den lille blokkeringsgranulariteten er høy samtidighet, men overheaden er stor, og den store blokkeringsgranulariteten er lav samtidighet, men overheaden er liten
SQL Server støtter låsgranularitet for rader, sider, nøkler, nøkkelområder, indekser, tabeller eller databaser
Ressursbeskrivelse
RID-radidentifikator. Pleide å låse en rad i et bord individuelt.
Nøkkelradlås i indeksen. Brukes for å beskytte nøkkelområdet i serialiserbare transaksjoner.
8 kilobyte (KB) med datasider eller indekssider.
Utvidet disk Et sett med åtte tilstøtende datasider eller indekssider.
Tabell Hele tabellen inkludert alle data og indekser.
DB-database.
4. Lengden på låsetiden
Tiden en lås holdes er den tiden som kreves for å beskytte ressursen på det forespurte nivået.
Holdetiden for den delte låsen som brukes til å beskytte leseoperasjoner avhenger av nivået for transaksjonsisolasjon. Med standard transaksjonsisolasjonsnivå READ COMMITTED, kontrolleres den delte låsen kun for varigheten av lesesiden. I en skanning frigjøres ikke låsen før låsen er funnet på neste side i skanningen. Hvis du spesifiserer en HOLDLOCK-prompt eller setter transaksjonsisolasjonsnivået til REPEATABLE READ eller SERIALIZABLE, slippes ikke låsen før transaksjonen avsluttes.
Avhengig av samtidighetsalternativet som er satt for markøren, kan markøren få en scroll lock i delt modus for å beskytte utdraget. Når en scroll-lås er nødvendig, slippes ikke scroll-låsen før neste gang markøren trekkes ut eller lukkes, avhengig av hva som skjer først. Men hvis du spesifiserer en HOLDLOCK, frigjøres ikke scroll-låsen før transaksjonen er ferdig.
Den eksklusive låsen som brukes for å beskytte oppdateringen vil ikke bli frigitt før transaksjonen er over.
Hvis en forbindelse prøver å få tak i en lås som kolliderer med en lås kontrollert av en annen forbindelse, vil forbindelsen som forsøker å få tak i låsen bli blokkert inntil:
Den motstridende låsen frigjøres, og forbindelsen får den forespurte låsen.
Tilkoblingstimeouten er utløpt. Det finnes ikke noe timeout-intervall som standard, men noen apper setter timeout-intervaller for å forhindre uendelig ventetid
Fem tilpasninger av låser i SQL Server
1 Håndter deadlocks og sett deadlock-prioriteringer
Deadlock er den endeløse ventingen forårsaket av flere brukere som søker om forskjellige blokkeringer, fordi søkeren har en del av blokkeringsretten og venter på den delvise blokkeringen som eies av andre brukere
Du kan bruke SET-DEADLOCK_PRIORITY for å kontrollere hvordan økten reagerer ved en deadlock-tilstand. Hvis begge prosessene låser dataene, og hver prosess ikke kan frigjøre sin egen lås før den andre prosessen frigjør sin egen lås, oppstår en deadlock-situasjon.
2 Håndter timeouts og sett timeout-varigheter for låsing.
@@LOCK_TIMEOUT Returnerer den nåværende låsetidsinnstillingen for den nåværende økten i millisekunder
SET LOCK_TIMEOUT-innstillingen lar applikasjonen sette maksimal tid setningen venter på å blokkere ressursen. Når ventetiden for setningen er lengre enn LOCK_TIMEOUT-innstillingen, kansellerer systemet automatisk blokkeringssetningen og sender applikasjonen en feilmelding på 1222 om at tidsavbruddsperioden for låseforespørsler er overskredet
eksempel
I det følgende eksempelet settes låsetidsperioden til 1 800 millisekunder.
SETT LOCK_TIMEOUT1800
3) Sett nivået for transaksjonsisolasjon.
4) Bruk låshint på tabellnivå for SELECT, INSERT, UPDATE og DELETE-setninger.
5) Konfigurer låsegranulariteten til indeksen
Du kan bruke sp_indexoption systemlagrede prosedyrer for å sette låsegranulariteten for indeksering
6. Se informasjonen om slusen
1 Utføre EXEC SP_LOCK rapportere informasjon om låsen
2 Trykk Ctrl + 2 i spørringsanalysatoren for å se informasjonen om låsen
7. Forholdsregler for bruk
Hvordan unngå fastlåste situasjoner
1. Når du bruker transaksjoner, prøv å forkorte den logiske behandlingsprosessen for transaksjoner, og send inn eller rull tilbake transaksjoner tidlig.
2 Sett deadlock-timeout-parameteren til et rimelig område, for eksempel: 3 minutter - 10 minutter; Etter denne tiden vil operasjonen automatisk bli avbrutt for å unngå at prosessen henger opp;
3. Optimalisere programmet, sjekke og unngå fenomenet deadlock;
4. Test alle skript og SP-er nøye før den eksakte versjonen.
5 Alle SP-er må ha feilhåndtering (via @error)
6 Ikke endre standardnivået for SQL SERVER-transaksjoner. Tvangslås anbefales ikke
Løs problemet Hvordan låse en radtabelldatabase
8. Flere spørsmål om låser
1 Hvordan låse en rad i et bord
SETT TRANSAKSJONSISOLASJONSNIVÅ READUNCOMMITTED
VELG *FRA tabell ROWLOCKWHERE id = 1
2 Lås en tabell i databasen
VELG *FRA tabell MED( HOLDLOCK )
Lock-uttalelse:
sybase:
oppdaterte tabellsett col1 = kol1 hvor 1= 0 ;
MSSQL:
velg kol1 fra tabell (tablockx) hvor 1= 0 ;
oracle:
LÅSEBORDBORD I EKSKLUSIV MODUS;
Etter at låsen er låst, kan ingen andre betjene den før den låste brukeren låser den opp, og den låses opp med commit eller rollback
Noen eksempler hjelper deg å utdype inntrykket ditt
Dekketabell1(A,B,C)
A B C
a1 b1 c1
a2 b2 c2
a3 b3 c3
1) Eksklusiv lås
Lag to nye forbindelser
Utfør følgende utsagn i den første tilkoblingen
Begin Tran
Oppdateringstabell1
sett A= ' aa '
hvor B= ' b2 '
vent på forsinkelse' 00:00:30' --vent 30 sekunder
commit tran
Utfør følgende utsagn i den andre forbindelsen
Begin Tran
velg *fra tabell1
hvor B= ' b2 '
commit tran
Hvis de to ovennevnte setningene utføres samtidig, må select-spørringen vente på at oppdateringen skal bli utført, det vil si vente 30 sekunder
2) Delt lås
Utfør følgende utsagn i den første tilkoblingen
Begin Tran
velg *fra tabell1 holdlock - Holdlocken legges kunstig til låsen
hvor B= ' b2 '
vent på forsinkelse' 00:00:30' --vent 30 sekunder
commit tran
Utfør følgende utsagn i den andre forbindelsen
Begin Tran
velg A,C fra tabell1
hvor B= ' b2 '
Oppdateringstabell1
sett A= ' aa '
hvor B= ' b2 '
commit tran
Hvis de to setningene ovenfor utføres samtidig, kan select-spørringen i den andre tilkoblingen utføres
Oppdateringen må vente på den første transaksjonen for å frigjøre den delte låsen og konvertere den til en eksklusiv lås før den kan kjøres, det vil si vente 30 sekunder
3) Fastlåst situasjon
Lagt til tabell2(D,E)
D E
d1 e1
d2 e2
Utfør følgende utsagn i den første tilkoblingen
Begin Tran
Oppdateringstabell1
sett A= ' aa '
hvor B= ' b2 '
vent på forsinkelse' 00:00:30'
Oppdateringstabell2
sett D= ' d5 '
hvor E= ' e1 '
commit tran
Utfør følgende utsagn i den andre forbindelsen
Begin Tran
Oppdateringstabell2
sett D= ' d5 '
hvor E= ' e1 '
vent på forsinkelse' 00:00:10'
Oppdateringstabell1
sett A= ' aa '
hvor B= ' b2 '
commit tran
Samtidig oppdager systemet fastlåsingen og avbryter prosessen
For å legge til:
Tabellnivå-låsetips støttet av SQL Server 2000
HOLDLOCK holder den delte låsen til hele transaksjonen er fullført, og bør frigjøres så snart det låste objektet ikke lenger trengs, tilsvarende nivået for transaksjonsisolasjon
NOLOCK-setningen utføres uten å utstede en delt lås, noe som tillater skitne lesinger, som tilsvarer nivået for READ UNCOMMITTED transaksjonsisolasjonsnivået
PAGLOCK bruker flere sidelåser hvor én tabelllås brukes
READPAST lar SQL-serveren hoppe over låste linjer og utføre transaksjoner, og for READ UNCOMMITTED transaksjonsisolasjonsnivåer, kun hoppe over RID-låser, ikke side-, sone- og tabelllåser
ROWLOCK håndhever bruken av rowlocks
TABLOCKX håndhever bruk av en eksklusiv tabellnivålås, som forhindrer at andre transaksjoner bruker tabellen under transaksjonen
UPLOCK tvinger bruk av oppdateringer når man leser en tabell uten delt lås
App-lås:
En applikasjonslås er en lås generert av klientkode, ikke en lås generert av SQL Server selv
To prosesser for håndtering av applikasjonslåser
sp_getapplock Låseapplikasjonsressurser
sp_releaseapplock Lås opp applikasjonsressursene
Merk: Forskjellen mellom å låse en tabell i en database
VELG *FRA tabell WITH( HOLDLOCK ) Andre transaksjoner kan lese tabellen, men kan ikke oppdatere og slette
VELG *FRA tabell WITH(TABLOCKX) Andre transaksjoner kan ikke lese, oppdatere og slette tabellen
|
Foregående:Det fantes ingen endepunkt som lyttet http://localhost:111/xxx.svc den k...Neste:SQL-låser NOLOCK, HOLDLOCK, UPDLOCK, TABLOCK, TABLOCKX
|
