Beskriv samtidighed
En central funktion i flerbrugerdatabaser er samtidighed. Samtidighed bruger låsning og blokering for at gøre det muligt for data at forblive konsistente med mange brugere, der opdaterer og læser data på samme tid. På grund af forsendelsesomkostninger har alle vores produkter f.eks. en prisstigning på $5. På grund af valutakurser har alle produkter samtidig et prisfald på 3%. Hvis disse opdateringer sker på præcis samme tid, vil den endelige pris være variabel, og der vil sandsynligvis være mange fejl. Ved hjælp af låsning kan du sikre, at én opdatering fuldføres, før den anden starter.
Samtidighed forekommer på transaktionsniveau. En skrivningstransaktion kan forhindre andre transaktioner i at opdatere og endda læse de samme data. Ligeledes kan en læsetransaktion blokere andre læsere eller endda nogle forfattere. Derfor er det vigtigt at undgå unødigt lange transaktioner eller transaktioner, der strækker sig over store mængder data.
Der er mange specifikke transaktionsisolationsniveauer, der kan bruges til at definere, hvordan et databasesystem håndterer flere brugere. I dette modul ser vi på brede kategorier af isolationsniveau, optimistisk låsning og pessimistisk låsning.
Seddel
De fulde detaljer om låsning af transaktioner ud over samtidighed er mere relateret til ydeevnen og ikke kun afhængig af koden – selvom god kode klarer sig bedre. Du kan finde flere oplysninger i den detaljerede vejledning til låsning og versionsstyring af SQL Server-transaktioner . Du kan få oplysninger om blokering i dokumentationen til SQL Server Performance.
Optimistisk samtidighed
Med optimistisk låsning er der en antagelse om, at der kun vil forekomme få modstridende opdateringer. I starten af transaktionen registreres dataenes oprindelige tilstand. Før transaktionen bekræftes, sammenlignes den aktuelle tilstand med den oprindelige tilstand. Hvis staterne er ens, fuldføres transaktionen. Hvis staterne er forskellige, annulleres posteringen.
Du har f.eks. en tabel, der indeholder de seneste års salgsordrer. Disse data opdateres sjældent, men rapporter køres ofte. Ved at bruge optimistisk låsning blokerer transaktioner ikke hinanden, og systemet kører mere effektivt. Der er desværre fundet fejl i de seneste års data, og der skal foretages opdateringer. Mens én transaktion opdaterer hver række, foretager en anden transaktion en mindre redigering af en enkelt række på samme tid. Da tilstanden for dataene blev ændret, mens den indledende transaktion kørte, annulleres hele transaktionen.
Pessimistisk samtidighed
Med pessimistisk låsning er der en antagelse om, at der sker mange opdateringer af dataene på samme tid. Ved at bruge låse kan der kun ske én opdatering på samme tid, og læsninger af dataene forhindres, mens opdateringerne finder sted. Dette kan forhindre store annulleringer, som det ses i det forrige eksempel, men kan medføre, at forespørgsler blokeres unødigt.
Det er vigtigt at overveje arten af dine data og de forespørgsler, der kører på dataene, når du beslutter, om du vil bruge optimistisk eller pessimistisk samtidighed for at sikre optimal ydeevne.
Snapshotisolation
Der er fem forskellige isolationsniveauer i SQL Server, men i dette modul koncentrerer vi os kun om READ_COMMITTED_SNAPSHOT_OFF og READ_COMMITTED_SNAPSHOT_ON. READ_COMMITTED_SNAPSHOT_OFF er standardisolationsniveauet for SQL Server. READ_COMMITTED_SNAPSHOT_ON er standardisoleringsniveauet for Azure SQL Database.
READ_COMMITTED_SNAPSHOT_OFF holder låse på de berørte rækker indtil slutningen af transaktionen, hvis forespørgslen bruger isolationsniveauet for den bekræftede transaktion. Selvom det er muligt for nogle opdateringer, f.eks. oprettelse af en ny række, forhindrer dette de fleste modstridende ændringer af dataene i at blive læst eller opdateret. Dette er pessimistisk samtidighed.
READ_COMMITTED_SNAPSHOT_ON tager et snapshot af dataene. Opdateringerne udføres derefter på det øjebliksbillede, så andre forbindelser kan forespørge de oprindelige data. I slutningen af transaktionen sammenlignes den aktuelle tilstand af dataene med snapshottet. Hvis dataene er de samme, bekræftes transaktionen. Hvis dataene er forskellige, annulleres transaktionen.
Hvis du vil ændre isolationsniveauet til READ_COMMITTED_SNAPSHOT_ON skal du udstede følgende kommando:
ALTER DATABASE *db_name* SET READ_COMMITTED_SNAPSHOT ON;
Hvis du vil ændre isolationsniveauet til READ_COMMITTED_SNAPSHOT_OFF skal du udstede følgende kommando:
ALTER DATABASE *db_name* SET READ_COMMITTED_SNAPSHOT OFF;
Hvis databasen er blevet ændret for at aktivere et skrivebeskyttet snapshot, vil alle transaktioner, der bruger standardniveauet for bekræftet isolation, bruge optimistisk låsning.
Seddel
Snapshotisolation sker kun for skrivebeskyttede transaktioner. Transaktioner, der bruger andre isolationsniveauer, påvirkes ikke.