Beskriva samtidighet
En viktig funktion i databaser med flera användare är samtidighet. Samtidighet använder låsning och blockering för att säkra att data förblir konsekventa när många användare uppdaterar och läser data samtidigt. Till exempel, på grund av fraktkostnader, har alla våra produkter en prisökning på $ 5. Samtidigt, på grund av valutakurser, har alla produkter en 3% prissänkning. Om dessa uppdateringar sker exakt samtidigt, kommer det slutliga priset att vara variabelt och det kommer sannolikt att finnas många fel. Med hjälp av låsning kan du se till att en uppdatering slutförs innan den andra påbörjas.
Samtidighet sker på transaktionsnivå. En skrivtransaktion kan blockera andra transaktioner från att uppdatera och till och med läsa samma data. På samma sätt kan en lästransaktion blockera andra läsare eller till och med vissa författare. Därför är det viktigt att undvika onödigt långa transaktioner eller transaktioner som sträcker sig över stora mängder data.
Det finns många specifika transaktionsisoleringsnivåer som kan användas för att definiera hur ett databassystem hanterar flera användare. I den här modulen tittar vi på breda kategorier av isoleringsnivå, optimistisk låsning och pessimistisk låsning.
Anmärkning
Den fullständiga informationen om transaktionslåsning utöver samtidighet handlar mer om prestanda och inte bara beroende av koden – även om bra kod presterar bättre. Mer information finns i den djupgående sql server-transaktionslåsnings- och radversionsguiden . Information om blockering finns i dokumentationen om SQL Server-prestanda.
Optimistisk konkurrens
Vid användning av optimistisk låsning antar man att det bara kommer att ske få konflikterande uppdateringar. I början av transaktionen registreras det ursprungliga tillståndet för data. Innan transaktionen checkas in jämförs det aktuella tillståndet med det ursprungliga tillståndet. Om tillstånden är desamma slutförs transaktionen. Om tillstånden är olika återställs transaktionen.
Du har till exempel en tabell som innehåller försäljningsorder för de senaste åren. Dessa data uppdateras sällan, men rapporter körs ofta. Genom att använda optimistisk låsning blockerar transaktioner inte varandra och systemet körs mer effektivt. Tyvärr har fel hittats under de senaste årens data och uppdateringar måste ske. Medan en transaktion uppdaterar varje rad, gör en annan transaktion en mindre redigering till en enskild rad samtidigt. Eftersom datatillståndet ändrades när den första transaktionen kördes återställs hela transaktionen.
Pessimistisk konkurrentåtkomst
Med pessimistisk låsning antar man att många uppdateringar sker i datan samtidigt. Genom att använda lås kan endast en uppdatering ske samtidigt och läsningar av data förhindras medan uppdateringar sker. Detta kan förhindra stora återställningar, som du såg i föregående exempel, men kan göra så att frågor blockeras i onödan.
Det är viktigt att tänka på typen av data och de frågeställningar som körs på datan när du överväger att använda optimistisk eller pessimistisk samtidighet för att säkerställa optimal prestanda.
Isolering av ögonblicksbilder
Det finns fem olika isoleringsnivåer i SQL Server, men för den här modulen koncentrerar vi oss på bara READ_COMMITTED_SNAPSHOT_OFF och READ_COMMITTED_SNAPSHOT_ON. READ_COMMITTED_SNAPSHOT_OFF är standardisoleringsnivån för SQL Server. READ_COMMITTED_SNAPSHOT_ON är den standardisoleringsnivå som används för Azure SQL Database.
READ_COMMITTED_SNAPSHOT_OFF håller lås på de berörda raderna till transaktionens slut om frågan använder sig av den read committed transaktionsisoleringsnivån. Även om det är möjligt att vissa uppdateringar inträffar, till exempel skapandet av en ny rad, förhindrar detta de flesta motstridiga ändringar av data som läses eller uppdateras. Det här är pessimistisk samtidighet.
READ_COMMITTED_SNAPSHOT_ON skapar en ögonblicksbild av data. Uppdateringar görs sedan på ögonblicksbilden så att andra anslutningar kan köra frågor mot ursprungliga data. I slutet av transaktionen jämförs datans aktuella tillstånd med ögonblicksbilden. Om uppgifterna är desamma, genomförs transaktionen. Om data skiljer sig åt återställs transaktionen.
Om du vill ändra isoleringsnivån till READ_COMMITTED_SNAPSHOT_ON utfärda följande kommando:
ALTER DATABASE *db_name* SET READ_COMMITTED_SNAPSHOT ON;
Om du vill ändra isoleringsnivån till READ_COMMITTED_SNAPSHOT_OFF utfärda följande kommando:
ALTER DATABASE *db_name* SET READ_COMMITTED_SNAPSHOT OFF;
Om databasen har ändrats för att aktivera skrivskyddad ögonblicksbild, kommer alla transaktioner som använder standardnivån för skrivskyddad isolering att använda optimistisk låsning.
Anmärkning
Ögonblicksbildisolering sker endast för skrivskyddade transaktioner. Transaktioner som använder andra isoleringsnivåer påverkas inte.