Nivået av isolasjon av transaksjoner i SQL Server og deres forhold til dirty reads, ikke-repeterbare reads, phantom reads osv. (kodeargumenter og tidssekvenser)
Ved å forstå disse problemene som kan oppstå ved samtidig tilgang til databasen, kan vi fortsette å forstå konseptet databaseisolasjonsnivå, på enkle språk: hvordan ønsker du å isolere samtidige transaksjoner, og i hvilken grad? For eksempel, hvis skitne lesninger kan tolereres, eller hvis du ikke vil at samtidige transaksjoner skal ha skitne lesninger, kan disse settes til isolasjonsnivå for å gjøre isolasjonen mellom samtidige transaksjoner løs eller alvorlig.
Jo høyere isolasjonsnivå, desto mindre sjanse for å lese skitne eller ufullstendige data, men desto mer alvorlig er ytelsesforringelsen i systemer med høy samtidighet. Jo lavere isolasjonsnivå, desto større ytelsesforbedring i det samtidige systemet, men dataene i seg selv kan være ufullstendige.
I SQL Server 2012 kan du sette isolasjonsnivået for en transaksjon (fra lavt til høyt) ved å bruke denne syntaksen:
SETT TRANSAKSJONSISOLASJONSNIVÅ
{ LES UFORPLIKTET
| LES FORPLIKTET
| REPETERBAR LESNING
| ØYEBLIKKSBILDE
| SERIALISERBAR
}
[ ; ]
Opprett et nytt vindu A, åpne en transaksjon, utføre oppdateringsoperasjonen, og vent 10 sekunder før du forplikter deg, koden er som følger:
Opprett et nytt vindu B, sett transaksjonen READ UNCOMMITTED (Uncommitted read, laveste nivå, det enkle problemet er dirty reading, fordi den kan lese data som er modifisert av andre transaksjoner men ikke committed.) Den gjør det samme som å sette (NOLOCK) på SELECT-setningsobjekttabellen i en transaksjon. Spør i dataene, koden er som følger:
Opprett et nytt vindu C, spør dataene direkte, som følger:
På sin side,Kjør vinduer A, B og C, og finn at når du oppdaterer data, kan vindu B umiddelbart returnere data (Det er mulig at avlesningen er skitten data), C-vindu må vente til A-vindu er ferdig med å kjørevil returnere dataene, som vist i figuren nedenfor:
(Vindu B)
(Vindu C)
(Slutt)
|
Publisert på 05.02.2021 11:53:34
|
|
|
|
