Descrivere la concorrenza
Una funzionalità di base dei database multiutente è la concorrenza. La concorrenza utilizza il blocco e il bloccaggio per consentire ai dati di rimanere coerenti con molti utenti che aggiornano e leggono i dati contemporaneamente. Ad esempio, a causa dei costi di spedizione, tutti i nostri prodotti hanno un aumento del prezzo di $ 5. Allo stesso tempo, a causa dei tassi di valuta, tutti i prodotti hanno una diminuzione del prezzo di 3%. Se questi aggiornamenti si verificano esattamente nello stesso momento, il prezzo finale sarà variabile e probabilmente ci saranno molti errori. Usando il blocco, è possibile assicurarsi che un aggiornamento venga completato prima dell'inizio dell'altro.
La concorrenza si verifica a livello di transazione. Una transazione di scrittura può impedire ad altre transazioni di aggiornare e persino leggere gli stessi dati. Allo stesso modo, una transazione di lettura può bloccare altri lettori o anche alcuni scrittori. Per questo motivo, è importante evitare transazioni o transazioni eccessivamente lunghe che si estendono su quantità eccessive di dati.
Esistono molti livelli di isolamento delle transazioni specifici che possono essere usati per definire il modo in cui un sistema di database gestisce più utenti. Ai fini di questo modulo, verranno esaminate ampie categorie di livello di isolamento, blocco ottimistico e blocco pessimistico.
Annotazioni
Il dettaglio completo del blocco delle transazioni, oltre la concorrenza, riguarda principalmente le prestazioni e non dipende solo dal codice, sebbene un buon codice migliori le prestazioni. Per maggiori dettagli, consultare la Guida approfondita al blocco delle transazioni in SQL Server e al versioning delle righe. Per informazioni sul blocco, vedere anche la documentazione sulle prestazioni di SQL Server.
Concorrenza ottimistica
Con il blocco ottimistico si presuppone che si verifichino pochi aggiornamenti in conflitto. All'inizio della transazione, viene registrato lo stato iniziale dei dati. Prima del commit della transazione, lo stato corrente viene confrontato con lo stato iniziale. Se gli stati sono uguali, la transazione viene completata. Se gli stati sono diversi, viene eseguito il rollback della transazione.
Ad esempio, è disponibile una tabella contenente gli ordini di vendita degli ultimi anni. Questi dati vengono aggiornati raramente, ma i report vengono eseguiti spesso. Usando il blocco ottimistico, le transazioni non si bloccano e il sistema viene eseguito in modo più efficiente. Sfortunatamente, gli errori sono stati rilevati negli ultimi anni di dati e gli aggiornamenti devono essere eseguiti. Mentre una transazione aggiorna ogni riga, un'altra transazione apporta una modifica secondaria a una singola riga contemporaneamente. Poiché lo stato dei dati è stato modificato durante l'esecuzione della transazione iniziale, viene eseguito il rollback dell'intera transazione.
Concorrenza pessimistica
Con il blocco pessimistico si presuppone che molti aggiornamenti vengano eseguiti sugli stessi dati contemporaneamente. Utilizzando i blocchi, può avvenire solo un aggiornamento alla volta e le letture dei dati vengono impedite mentre gli aggiornamenti sono in corso. Ciò consente di evitare rollback di grandi dimensioni, come quelli dell'esempio precedente, ma può causare inutilmente il blocco delle query.
È importante considerare la natura dei dati e le query in esecuzione sui dati quando si decide se usare la concorrenza ottimistica o pessimistica per garantire prestazioni ottimali.
Isolamento dello snapshot
Esistono cinque livelli di isolamento diversi in SQL Server, ma per questo modulo ci si concentrerà solo su READ_COMMITTED_SNAPSHOT_OFF e READ_COMMITTED_SNAPSHOT_ON. "READ_COMMITTED_SNAPSHOT_OFF" è il livello di isolamento predefinito per SQL Server. READ_COMMITTED_SNAPSHOT_ON è il livello di isolamento predefinito per il database SQL di Azure.
READ_COMMITTED_SNAPSHOT_OFF manterrà i blocchi sulle righe interessate fino alla fine della transazione se la query usa il livello di isolamento delle transazioni con commit di lettura. Anche se è possibile che si verifichino alcuni aggiornamenti, ad esempio la creazione di una nuova riga, ciò impedirà la maggior parte delle modifiche in conflitto ai dati letti o aggiornati. Si tratta di concorrenza pessimistica.
READ_COMMITTED_SNAPSHOT_ON crea un'istantanea dei dati. Gli aggiornamenti vengono quindi eseguiti su tale snapshot consentendo ad altre connessioni di eseguire query sui dati originali. Alla fine della transazione lo stato corrente dei dati viene confrontato con lo snapshot. Se i dati sono uguali, viene eseguito il commit della transazione. Se i dati sono diversi, viene eseguito il rollback della transazione.
Per impostare il livello di isolamento su READ_COMMITTED_SNAPSHOT_ON, eseguire il comando seguente:
ALTER DATABASE *db_name* SET READ_COMMITTED_SNAPSHOT ON;
Per modificare il livello di isolamento in READ_COMMITTED_SNAPSHOT_OFF eseguire il comando seguente:
ALTER DATABASE *db_name* SET READ_COMMITTED_SNAPSHOT OFF;
Se il database è stato modificato per attivare lo snapshot con commit di lettura, qualsiasi transazione che usa il livello di isolamento con commit di lettura predefinito userà il blocco ottimistico.
Annotazioni
L'isolamento snapshot si verifica solo per le transazioni con commit di lettura. Le transazioni che usano altri livelli di isolamento non sono interessate.