Databasens konsistens är också en av de viktiga indikatorerna för att mäta DBMS-prestanda. För närvarande använder de flesta kommersiella databaser (DB2, SQL Server) Two-Phase Locking (2PL)-protokollet för samtidighetskontroll, vilket säkerställer serialisering av samtidiga transaktioner. Dock måste 2PL låsa all data innan den kan läsa eller skriva till den. I blockningskompatibilitetsmatrisen är S-lås (Share Locks) och X-lås (exklusiva lås) inkompatibla, så när transaktion 1 utför en läsoperation på data A (plus ett S-lås), och transaktion 2 vill skriva till datan (lägga till ett X-lås), måste transaktion 2 vänta tills transaktion 1 släpper S-låset på data A innan den fortsätter. Multi-Version Concurrency Control (MVCC) löser detta problem väl. I ett multiversionssystem genererar varje skrivdata en ny version, och läsoperationen kan läsa den lämpliga versionen vid behov, så att läs- och skrivoperationerna inte blockerar varandra. MVCC ökar samtidigheten, men det innebär också lagringsöverhead för att underhålla flera versioner.
Microsoft SQL Server-databasmotorn introducerar en ny implementation av den befintliga transaktionsisoleringsnivån – committed reads, som ger statement-nivåsnapshots med radversionering. SQL Server-databasmotorn introducerar också en ny nivå av transaktionsisolering – ögonblicksbilder för att tillhandahålla transaktionsnivå-snapshots som också använder radversionering.
Att ställa in READ_COMMITTED_SNAPSHOT-databasalternativet till ON möjliggör dedikerad läsisolering med radversionering. Att sätta ALLOW_SNAPSHOT_ISOLATION-databasalternativet på ON aktiverar snapshot-isolering. När något av alternativen är aktiverat för databasen behåller databasmotorn versionen av varje rad som ändras. När en transaktion ändrar en rad kopieras bilden av raden före ändringen till en sida i versionslagret. En versionslagring är en samling datasidor i tempdb. Om det finns flera transaktionsmodifieringslinjer kommer flera versioner av den raden att länkas i en versionskedja. En läsoperation med radversionering hämtar den sista versionen av varje rad som committerades vid transaktionen eller satsstarten.
Applikationer skrivna för SQL Server 2008 eller nya i SQL Server implementerar isolering av läscommits med radversionering genom att specificera transaktionsisoleringsnivån för läscommits när READ_COMMITTED_SNAPSHOT databasalternativet är PÅ. Alla läsningar kommer att titta på radversionen som gjordes när uttalandet började. Detta ger en statusnivå-ögonblicksbild av datan.
Applikationer skrivna för SQL Server implementerar snapshot isolation genom att specificera snapshot-transaktionsisoleringsnivån när alternativet ALLOW_SNAPSHOT_ISOLATION databas är PÅ. Alla läsningar i en snapshot-transaktion kommer att titta på den version av raden som committerades när transaktionen startade. Detta ger en transaktionsnivå-ögonblicksbild av datan.
För transaktioner som använder radbaserade isoleringsnivåer begär läsningar inte delade lås på datan. Detta innebär att läsare som använder radversionering inte hindrar andra läsare eller skribenter från att komma åt samma data. På samma sätt står författaren inte i vägen för läsaren. Men författare kommer i vägen för varandra (även när de kör på en nivå av isolering baserad på radversionering). Två skrivoperationer kan inte ändra samma data samtidigt.
Funktionen Snapshot Isolation utökar låsningsramverket i SQL Server 2008 genom att göra det möjligt för applikationer att visa värden innan några dataändringar sker. Detta förhindrar att applikationen låses samtidigt som den fortfarande tillhandahåller verkligt inlämnad data. SQL Server 2008:s Read Committed Snapshot kräver att en databasadministratör aktiveras, vilket gör det möjligt att läsa data via skrivskyddade transaktioner. Så SI:s samtidiga kontroll av skrivskyddade transaktioner är mycket bra, men det är oklart om detta gäller för uppdateringstransaktioner. Det är mer ogynnsamt för långvariga uppdateringstransaktioner att konkurrera med kortsiktiga högnivåtransaktioner. Om en transaktion mellan databaser försöker använda Snapshot Isolation (SI)-standarden istället för att alla databaser är satta, misslyckas transaktionen. Detta skapar utan tvekan vissa hinder för skalbarhet. Det verkar som att Microsoft fortfarande har en lång väg kvar för att uppnå sin egen SI som är starkare än SQL 92-specifikationen.
Innan någon ändring görs, gör en kopia av den tidigare versionen, och alla efterföljande läsoperationer kommer att läsa den kopierade versionen, och modifieringen skapar en ny version. På detta sätt,Läs- och skrivoperationer blockerar inte varandra. Fördelen med att använda denna radversioneringsmekanism är att programmets samtidighet är relativt hög, men nackdelen är att även om användaren inte läser en smutsig data, kan det vara ett datavärde som ändras och är på väg att gå ut. Om du ändrar datan baserat på detta utgångna värde kommer det att orsaka ett logiskt fel。
SQL-kommandon:
Referenslänkar:
Inloggningen med hyperlänken är synlig.
Inloggningen med hyperlänken är synlig.
Inloggningen med hyperlänken är synlig.
Inloggningen med hyperlänken är synlig.
Inloggningen med hyperlänken är synlig.
Inloggningen med hyperlänken är synlig.
|
Publicerad på 2021-01-28 17:55:52
|
|
|
Publicerad på 2021-01-29 09:13:40
|
vilja