La coerenza del database è anche uno degli indicatori importanti per misurare le prestazioni del DBMS. Attualmente, la maggior parte dei database commerciali (DB2, SQL Server) utilizza il protocollo Two-Phase Locking (2PL) per il controllo della concorrenza, che garantisce la serializzazione dell'esecuzione concorrente delle transazioni. Tuttavia, il 2PL deve bloccare qualsiasi dato prima di poter leggervi o scriverci. Nella matrice di compatibilità bloccante, i lock S (blocchi di condivisione) e X lock (blocchi esclusivi) sono incompatibili, quindi quando la transazione 1 sta eseguendo un'operazione di lettura sui dati A (più un lock S), e la transazione 2 vuole scrivere sui dati (aggiungere un lock X), la transazione 2 deve attendere che la transazione 1 rilasci il lock S sui dati A prima di procedere. Il Controllo di Concorrenza Multi-Versione (MVCC) risolve bene questo problema. In un sistema multi-versione, ogni data di scrittura genera una nuova versione, e l'operazione di lettura può leggere la versione appropriata secondo necessità, così che le operazioni di lettura e scrittura non si bloccano a vicenda. MVCC aumenta la concorrenza, ma introduce anche il sovraccarico di storage dovuto al mantenimento di più versioni.
Il motore di database Microsoft SQL Server introduce una nuova implementazione del livello di isolamento delle transazioni esistente: le letture committite, che forniscono istantanee a livello di istruzione utilizzando il versioning delle righe. Il motore di database SQL Server introduce anche un nuovo livello di isolamento delle transazioni: snapshot per fornire snapshot a livello di transazione che utilizzano anche il versioning delle righe.
Impostare l'opzione READ_COMMITTED_SNAPSHOT database su ON consente l'isolamento di lettura commit tramite il versioning delle righe. Impostare l'opzione ALLOW_SNAPSHOT_ISOLATION database su ON abilita l'isolamento degli snapshot. Quando una delle due opzioni è abilitata per il database, il motore del database mantiene la versione di ogni riga modificata. Ogni volta che una transazione modifica una riga, l'immagine della riga precedente alla modifica viene copiata in una pagina dello store versioni. Uno store di versioni è una raccolta di pagine dati in tempdb. Se ci sono più linee di modifica delle transazioni, più versioni di quella linea saranno collegate in una catena di versioni. Un'operazione di lettura tramite versioning delle righe recupererà l'ultima versione di ogni riga che è stata commessa al momento dell'inizio della transazione o dell'istruzione.
Le applicazioni scritte per SQL Server 2008 o nuove su SQL Server implementano l'isolamento dei commit di lettura utilizzando il versioning delle righe specificando il livello di isolamento delle transazioni per i commit di lettura quando l'opzione READ_COMMITTED_SNAPSHOT database è attiva. Tutte le letture guarderanno la versione della riga che è stata commessa all'inizio della dichiarazione. Questo fornirà un'istantanea a livello di istruzione dei dati.
Le applicazioni scritte per SQL Server implementeranno l'isolamento degli snapshot specificando il livello di isolamento delle transazioni snapshot quando l'opzione ALLOW_SNAPSHOT_ISOLATION database è attiva. Tutte le letture in una transazione snapshot guarderanno la versione della riga che è stata commessa quando la transazione è iniziata. Questo fornirà un'istantanea a livello di transazione dei dati.
Per le transazioni che utilizzano livelli di isolamento basati su righe, le letture non richiedono locks condivisi sui dati. Ciò significa che i lettori che utilizzano il versioning delle righe non impediscono ad altri lettori o autori di accedere agli stessi dati. Allo stesso modo, lo scrittore non intralcia il lettore. Tuttavia, gli scrittori si ostacolano a vicenda (anche quando si usa a un livello di isolamento basato sulla versione delle righe). Due operazioni di scrittura non possono modificare gli stessi dati contemporaneamente.
La funzione Snapshot Isolation estende il framework di locking in SQL Server 2008 permettendo alle applicazioni di visualizzare i valori prima che avvengano modifiche ai dati. Questo impedisce che l'applicazione venga bloccata, pur fornendo dati effettivamente inviati. Il Read Committed Snapshot di SQL Server 2008 richiede l'attivazione di un amministratore di database, consentendo la lettura dei dati tramite transazioni di sola lettura. Quindi il controllo di concorrenza di SI sulle transazioni in sola lettura è molto buono, ma non è chiaro se questo sia il caso delle transazioni di aggiornamento. È più sfavorevole che le transazioni di aggiornamento a lungo termine competano con quelle di alto livello a breve termine. Se una transazione tra database tenta di utilizzare lo standard Snapshot Isolation (SI), invece di impostare tutti i database, la transazione fallisce. Questo senza dubbio crea alcuni ostacoli alla scalabilità. Sembra che Microsoft abbia ancora molta strada da fare per raggiungere un proprio SI più forte della specifica SQL 92.
Prima di qualsiasi modifica, fai una copia della versione precedente e tutte le operazioni di lettura successive leggeranno la versione copiata, mentre la modifica creerà una nuova versione. In questo modo,Le operazioni di lettura e scrittura non si bloccano a vicenda. Il vantaggio di utilizzare questo meccanismo di versioning delle righe è che la concorrenza del programma è relativamente elevata, ma lo svantaggio è che, sebbene l'utente non legga un dato sporco, potrebbe trattarsi di un valore di dato in fase di modifica e che sta per scadere. Se modifichi i dati in base a questo valore scaduto, causerà un errore logico。
Comandi SQL:
Collegamenti di riferimento:
Il login del link ipertestuale è visibile.
Il login del link ipertestuale è visibile.
Il login del link ipertestuale è visibile.
Il login del link ipertestuale è visibile.
Il login del link ipertestuale è visibile.
Il login del link ipertestuale è visibile.
|
Pubblicato su 28/01/2021 17:55:52
|
|
|
Pubblicato su 29/01/2021 09:13:40
|
volere