Databaseconsistentie is ook een van de belangrijke indicatoren om de prestaties van DBMS te meten. Momenteel gebruiken de meeste commerciële databases (DB2, SQL Server) het Two-Phase Locking (2PL)-protocol voor gelijktijdigheidscontrole, wat zorgt voor de serialisatie van gelijktijdige transactie-uitvoering. Echter, 2PL moet alle data vergrendelen voordat het kan lezen of schrijven. In de blokkeringscompatibiliteitsmatrix zijn S-locks (Share Locks) en X-locks (Exclusive Locks) incompatibel, dus wanneer transactie 1 een leesoperatie uitvoert op data A (plus een S-lock), en transactie 2 naar de data wil schrijven (een X-lock toevoegen), moet transactie 2 wachten tot transactie 1 de S-lock op data A loslaat voordat ze verder kan gaan. Multi-Version Concurrency Control (MVCC) lost dit probleem goed op. In een multiversiesysteem genereert elke schrijfdata een nieuwe versie, en kan de leesoperatie de juiste versie lezen wanneer nodig, zodat de lees- en schrijfbewerkingen elkaar niet blokkeren. MVCC verhoogt gelijktijdigheid, maar introduceert ook de opslagoverhead van het onderhouden van meerdere versies.
De Microsoft SQL Server-database-engine introduceert een nieuwe implementatie van het bestaande transaction isolation level - committed reads, die snapshots op instructieniveau bieden met behulp van rijversiebeheer. De SQL Server-database-engine introduceert ook een nieuw niveau van transactieisolatie - snapshots om transactie-niveau snapshots te bieden die ook gebruikmaken van rijversiebeheer.
Door de READ_COMMITTED_SNAPSHOT databaseoptie op AAN te zetten, wordt gecommitteerde leesisolatie mogelijk gemaakt met behulp van rijversiebeheersing. Door de ALLOW_SNAPSHOT_ISOLATION database-optie op AAN te zetten, wordt snapshot-isolatie mogelijk gemaakt. Wanneer een van beide opties voor de database is ingeschakeld, onderhoudt de database-engine de versie van elke rij die wordt gewijzigd. Telkens wanneer een transactie een rij wijzigt, wordt het beeld van de rij vóór de wijziging gekopieerd naar een pagina in de versiewinkel. Een versieopslag is een verzameling datapagina's in tempdb. Als er meerdere transactiewijzigingslijnen zijn, worden meerdere versies van die lijn gekoppeld in een versieketen. Een leesoperatie met behulp van rijversiebeheer haalt de laatste versie van elke rij op die bij het begin van de transactie of instructie werd gecommit.
Applicaties die geschreven zijn voor SQL Server 2008 of nieuw zijn voor SQL Server, implementeren isolatie van read commits via rijversiebeheer door het transactieisolatieniveau voor read commits te specificeren wanneer de READ_COMMITTED_SNAPSHOT databaseoptie AAN staat. Alle reads kijken naar de rijversie die werd aangebracht toen de verklaring begon. Dit levert een statement-niveau snapshot van de data.
Applicaties geschreven voor SQL Server implementeren snapshot isolatie door het snapshot-transmissie-isolatieniveau te specificeren wanneer de ALLOW_SNAPSHOT_ISOLATION databaseoptie AAN staat. Alle reads in een snapshottransactie kijken naar de versie van de rij die werd gecommitteerd toen de transactie begon. Dit levert een transactie-niveau momentopname van de data op.
Voor transacties die gebruikmaken van rijgebaseerde isolatieniveaus, vragen reads geen gedeelde vergrendelingen op de data aan. Dit betekent dat lezers die rijversiebeheer gebruiken andere lezers of schrijvers niet verhinderen om dezelfde data te benaderen. Evenzo staat de schrijver de lezer niet in de weg. Toch zitten schrijvers elkaar in de weg (zelfs als ze op een niveau van isolatie draaien op basis van rijversiebeheersing). Twee schrijfbewerkingen kunnen niet dezelfde data tegelijkertijd wijzigen.
De Snapshot Isolation-functie breidt het vergrendelingsframework in SQL Server 2008 uit door applicaties in staat te stellen waarden te bekijken voordat er datawijzigingen plaatsvinden. Dit voorkomt dat de applicatie wordt vergrendeld terwijl daadwerkelijk ingediende gegevens worden geleverd. De Read Committed Snapshot van SQL Server 2008 vereist dat een databasebeheerder activeert, waardoor data kan worden gelezen door alleen-lezen transacties. Dus SI's gelijktijdige controle over alleen-lezen transacties is erg goed, maar het is onduidelijk of dit geldt voor updatetransacties. Het is ongunstiger dat langlopende updatetransacties concurreren met kortetermijntransacties op hoog niveau. Als een transactie tussen databases probeert de Snapshot Isolation (SI)-standaard te gebruiken in plaats van alle databases te zijn ingesteld, faalt de transactie. Dit creëert ongetwijfeld bepaalde obstakels voor schaalbaarheid. Het lijkt erop dat Microsoft nog een lange weg te gaan heeft om zijn eigen SI te bereiken die sterker is dan de SQL 92-specificatie.
Maak vóór elke wijziging een kopie van de vorige versie, en alle volgende leesbewerkingen lezen de gekopieerde versie, waarna de wijziging een nieuwe versie aanmaakt. Op deze manier,Lees- en schrijfoperaties blokkeren elkaar niet. Het voordeel van dit regelversiesysteem is dat de gelijktijdigheid van het programma relatief hoog is, maar het nadeel is dat hoewel de gebruiker geen corrupte data leest, het een datawaarde kan zijn die wordt aangepast en op het punt staat te verlopen. Als je de gegevens aanpast op basis van deze verlopen waarde, veroorzaakt dat een logische fout。
SQL-commando's:
Referentielinks:
De hyperlink-login is zichtbaar.
De hyperlink-login is zichtbaar.
De hyperlink-login is zichtbaar.
De hyperlink-login is zichtbaar.
De hyperlink-login is zichtbaar.
De hyperlink-login is zichtbaar.
|
Geplaatst op 28-01-2021 17:55:52
|
|
|
Geplaatst op 29-01-2021 09:13:40
|
willen