Databasekonsistens er også en af de vigtige indikatorer for at måle DBMS' ydeevne. I øjeblikket bruger de fleste kommercielle databaser (DB2, SQL Server) Two-Phase Locking (2PL)-protokollen til samtidighedskontrol, hvilket sikrer serialisering af samtidige transaktioner. Dog skal 2PL låse data, før den kan læse eller skrive til den. I blokeringskompatibilitetsmatricen er S-låse (Share Locks) og X-låse (Eksklusive låse) inkompatible, så når transaktion 1 udfører en læseoperation på data A (plus en S-lås), og transaktion 2 ønsker at skrive til dataene (tilføje en X-lås), skal transaktion 2 vente på, at transaktion 1 frigiver S-låsen på data A, før den kan fortsætte. Multi-Version Concurrency Control (MVCC) løser dette problem godt. I et multiversionssystem genererer hver skrivedata en ny version, og læseoperationen kan læse den relevante version efter behov, så læse- og skriveoperationerne blokerer ikke hinanden. MVCC øger samtidigheden, men det medfører også lagringsomkostningerne ved at vedligeholde flere versioner.
Microsoft SQL Server-databasemotoren introducerer en ny implementering af det eksisterende transaktionsisolationsniveau – commited reads, som giver snapshots på sætningsniveau ved hjælp af rækkeversionering. SQL Server-databasemotoren introducerer også et nyt niveau af transaktionsisolering – snapshots til at levere transaktionsniveau-snapshots, som også bruger rækkeversionering.
At sætte READ_COMMITTED_SNAPSHOT database-indstillingen til ON muliggør dedikeret læseisolation ved hjælp af rækkeversionering. At sætte ALLOW_SNAPSHOT_ISOLATION databaseindstillingen til ON muliggør snapshot-isolering. Når en af mulighederne er aktiveret for databasen, vedligeholder databasemotoren den version af hver række, der ændres. Hver gang en transaktion ændrer en række, kopieres billedet af rækken før ændringen til en side i versionslageret. Et versionslager er en samling af datasider i tempdb. Hvis der er flere transaktionsmodifikationslinjer, vil flere versioner af den linje være forbundet i en versionskæde. En læseoperation ved hjælp af rækkeversionering vil hente den sidste version af hver række, der blev forpligtet på tidspunktet for transaktionen eller sætningens start.
Applikationer skrevet til SQL Server 2008 eller nye til SQL Server implementerer isolation af read commits ved hjælp af rækkeversionering ved at specificere transaktionsisolationsniveauet for read commits, når READ_COMMITTED_SNAPSHOT databaseindstillingen er TIL. Alle læsninger vil se på rækkeversionen, der blev gennemført, da erklæringen startede. Dette vil give et statement-niveau snapshot af dataene.
Applikationer skrevet til SQL Server implementerer snapshot-isolation ved at specificere snapshot-transaktionsisolationsniveauet, når ALLOW_SNAPSHOT_ISOLATION-databaseindstillingen er TIL. Alle læsninger i en snapshot-transaktion vil se på den version af rækken, der blev commitmentet, da transaktionen startede. Dette vil give et transaktionsniveau snapshot af dataene.
For transaktioner, der bruger rækkebaserede isolationsniveauer, anmoder reads ikke om delte låse på dataene. Det betyder, at læsere, der bruger rækkeversionering, ikke forhindrer andre læsere eller forfattere i at få adgang til de samme data. På samme måde står forfatteren ikke i vejen for læseren. Men forfattere kommer i vejen for hinanden (selv når de kører på et isolationsniveau baseret på rækkeversionering). To skriveoperationer kan ikke ændre de samme data på samme tid.
Funktionen Snapshot Isolation udvider låserammen i SQL Server 2008 ved at gøre det muligt for applikationer at se værdier, før der sker dataændringer. Dette forhindrer, at applikationen bliver låst, samtidig med at den leverer reelt indsendte data. SQL Server 2008's Read Committed Snapshot kræver, at en databaseadministrator aktiveres, hvilket gør det muligt at læse data via skrivebeskyttede transaktioner. Så SI's samtidighedskontrol af skrivebeskyttede transaktioner er meget god, men det er uklart, om det gælder for opdateringstransaktioner. Det er mere ugunstigt, at langvarige opdateringstransaktioner konkurrerer med kortsigtede højniveautransaktioner. Hvis en transaktion på tværs af databaser forsøger at bruge Snapshot Isolation (SI)-standarden i stedet for at alle databaser er sat, fejler transaktionen. Dette skaber uden tvivl visse forhindringer for skalerbarhed. Det ser ud til, at Microsoft stadig har lang vej igen for at opnå sin egen SI, der er stærkere end SQL 92-specifikationen.
Før nogen ændring skal du lave en kopi af den tidligere version, og alle efterfølgende læseoperationer vil læse den kopierede version, og ændringen vil skabe en ny version. På denne måde,Læse- og skriveoperationer blokerer ikke hinanden. Fordelen ved at bruge denne linjeversioneringsmekanisme er, at programmets samtidighed er relativt høj, men ulempen er, at selvom brugeren ikke læser ukrypterede data, kan det være en dataværdi, der ændres og er ved at udløbe. Hvis du ændrer dataene baseret på denne udløbne værdi, vil det forårsage en logisk fejl。
SQL-kommandoer:
Referencelinks:
Hyperlink-login er synlig.
Hyperlink-login er synlig.
Hyperlink-login er synlig.
Hyperlink-login er synlig.
Hyperlink-login er synlig.
Hyperlink-login er synlig.
|
Opslået på 28/01/2021 17.55.52
|
|
|
Opslået på 29/01/2021 09.13.40
|
ville