Beskriv samtidighet
En kjernefunksjon i flerbrukerdatabaser er samtidighet. Samtidighet bruker låsing og blokkering for å gjøre det mulig for data å forbli konsekvente med mange brukere som oppdaterer og leser data samtidig. På grunn av fraktkostnader har for eksempel alle produktene våre en prisøkning på USD 5. Samtidig, på grunn av valutakurser, alle produkter har en 3% prisnedgang. Hvis disse oppdateringene skjer på nøyaktig samme tid, vil den endelige prisen være variabel, og det vil sannsynligvis være mange feil. Ved hjelp av låsing kan du sikre at én oppdatering fullføres før den andre begynner.
Samtidighet forekommer på transaksjonsnivå. En skrivetransaksjon kan blokkere andre transaksjoner fra å oppdatere og til og med lese de samme dataene. Likeledes kan en lesetransaksjon blokkere andre lesere eller til og med noen forfattere. Derfor er det viktig å unngå unødvendig lange transaksjoner eller transaksjoner som strekker seg over store mengder data.
Det finnes mange spesifikke isoleringsnivåer for transaksjoner som kan brukes til å definere hvordan et databasesystem håndterer flere brukere. I forbindelse med denne modulen skal vi se på brede kategorier av isolasjonsnivå, optimistisk låsing og pessimistisk låsing.
Merk deg
Den fullstendige detaljen om transaksjonslås utover samtidighet er relatert mer til ytelse og ikke bare avhengig av koden - selv om god kode yter bedre. Se gjennom den dyptgående veiledningen for SQL Server-transaksjonslåsing og radversjonskontroll for mer informasjon. Hvis du vil ha informasjon om blokkering, kan du også se dokumentasjonen for SQL Server Performance.
Optimistisk samtidighet
Med optimistisk låsing er det en antagelse at få motstridende oppdateringer vil skje. I begynnelsen av transaksjonen registreres den opprinnelige tilstanden til dataene. Før transaksjonen utføres, sammenlignes gjeldende tilstand med den opprinnelige tilstanden. Hvis statene er like, fullføres transaksjonen. Hvis statene er forskjellige, rulles transaksjonen tilbake.
Du har for eksempel en tabell som inneholder salgsordrer i fjor. Disse dataene oppdateres sjelden, men rapporter kjøres ofte. Ved å bruke optimistisk låsing blokkerer ikke transaksjoner hverandre, og systemet kjører mer effektivt. Dessverre har det blitt funnet feil i de siste årene data og oppdateringer må finne sted. Mens én transaksjon oppdaterer hver rad, gjør en annen transaksjon en mindre redigering til én enkelt rad samtidig. Siden tilstanden til dataene ble endret mens den første transaksjonen kjørte, rulles hele transaksjonen tilbake.
Pessimistisk samtidighet
Med pessimistisk låsing er det en antagelse at mange oppdateringer skjer med dataene samtidig. Ved å bruke låser kan bare én oppdatering skje samtidig, og lesing av dataene forhindres mens oppdateringer finner sted. Dette kan forhindre store tilbakerullinger, som vist i forrige eksempel, men kan føre til at spørringer blokkeres unødvendig.
Det er viktig å vurdere dataenes natur og spørringene som kjører på dataene når du bestemmer deg for å bruke optimistisk eller pessimistisk samtidighet for å sikre optimal ytelse.
Isolering av øyeblikksbilde
Det finnes fem forskjellige isoleringsnivåer i SQL Server, men for denne modulen konsentrerer vi oss om bare READ_COMMITTED_SNAPSHOT_OFF og READ_COMMITTED_SNAPSHOT_ON. READ_COMMITTED_SNAPSHOT_OFF er standard isoleringsnivå for SQL Server. READ_COMMITTED_SNAPSHOT_ON er standard isoleringsnivå for Azure SQL Database.
READ_COMMITTED_SNAPSHOT_OFF vil holde låser på de berørte radene frem til slutten av transaksjonen hvis spørringen bruker isoleringsnivået for lesedefinert transaksjon. Selv om det er mulig at noen oppdateringer oppstår, for eksempel oppretting av en ny rad, vil dette forhindre at de fleste motstridende endringer i dataene leses eller oppdateres. Dette er pessimistisk samtidighet.
READ_COMMITTED_SNAPSHOT_ON tar et øyeblikksbilde av dataene. Oppdateringer utføres deretter på dette øyeblikksbildet, slik at andre tilkoblinger kan spørre etter de opprinnelige dataene. På slutten av transaksjonen sammenlignes gjeldende tilstand for dataene med øyeblikksbildet. Hvis dataene er de samme, utføres transaksjonen. Hvis dataene er forskjellige, rulles transaksjonen tilbake.
Hvis du vil endre isoleringsnivået til READ_COMMITTED_SNAPSHOT_ON kan du utstede følgende kommando:
ALTER DATABASE *db_name* SET READ_COMMITTED_SNAPSHOT ON;
Hvis du vil endre isoleringsnivået til READ_COMMITTED_SNAPSHOT_OFF utsteder du følgende kommando:
ALTER DATABASE *db_name* SET READ_COMMITTED_SNAPSHOT OFF;
Hvis databasen er endret for å aktivere leseinnsatt øyeblikksbilde, vil alle transaksjoner som bruker standard isolert isoleringsnivå, bruke optimistisk låsing.
Merk deg
Isolering av øyeblikksbilde forekommer bare for lesedefinerte transaksjoner. Transaksjoner som bruker andre isoleringsnivåer, påvirkes ikke.