Le scritture del database SQL Server sono più lente con l'isolamento dello snapshot?

8

Ho molti deadlock in corso nel mio sistema.

Vorrei utilizzare Isolamento istantanea per risolverli, ma il mio DBA ha delle riserve a riguardo.

Una delle sue preoccupazioni è che l'isolamento dell'istantanea rallenta le scritture. Questo perché deve scrivere nella cache e quindi nel TempDb (versione riga) e quindi può tornare al chiamante.

Una scrittura "normale" può semplicemente scrivere nella cache e quindi essere eseguita.

È così che funziona il controllo delle versioni di riga? O è più complesso di così? In qualche modo li fa in parallelo?

Oppure le scritture sono più lente con Isolamento istantanea?

— Vaccano
fonte

2

Un problema a cui prestare attenzione quando si abilita l'isolamento dello snapshot: la dimensione della riga aumenterà di 14 byte. Assicurati di aver pianificato questo aumento di capacità e qualsiasi divisione della pagina risultante.

— StanleyJohns

14

è perché deve scrivere nella cache e quindi nel TempDb (versione riga) e quindi può tornare al chiamante.

No, questo non è corretto. Ciò implica in qualche modo che le scritture in presenza di versioning abbiano una latenza più elevata poiché ogni scrittura deve toccare il disco (per tempdb) che non è vero. La scrittura nel tempdb è anche una scrittura nella 'cache'. L'unica 'attesa' si verifica al momento COMMIT quando il registro deve essere rafforzato. È vero che con il controllo delle versioni sia il registro DB sia il registro tempdb devono essere rafforzati, ma ciò non implica necessariamente una latenza più elevata (l'IO deve essere parallelo su percorsi di archiviazione diversi, il tempdb viene archiviato su un'unità separata dal LDF utilizzato pesantemente, destra?). Per una spiegazione completa leggi Come funziona: Presentazione I / O di SQL Server di Bob Dorr Spero davvero che il tuo DBA lo capisca meglio di quanto tu lo trasmetta qui.

Come ho già detto nel tuo altro post: lo snapshot non ha alcun costo per INSERTS e il costo per gli aggiornamenti e le eliminazioni può essere facilmente mitigato. L'utilizzo delle risorse per il controllo delle versioni delle righe spiega i compromessi. In questo momento dovresti probabilmente provare con un carico di lavoro realistico, che è l'unico modo per valutare correttamente l'impatto che potresti sperimentare.

— Remus Rusanu
fonte

4

A proposito, considera questo: tu o il tuo DBA avete mai usato i trigger negli ultimi 7 anni? Dal momento che i trigger di SQL 2005 vengono implementati utilizzando l'istantanea dietro le quinte. Lo stesso vale se hai mai usato la ricostruzione dell'indice online o MARS . Che ne dici se controlli subito sys.dm_db_file_space_usagesul tuo server di produzione. Se version_store_reserved_page_countè diverso da zero, stai già utilizzando lo store versione .

— Remus Rusanu,

Non penso che il registro di tempdb debba mai essere rafforzato perché la ripetizione non viene mai eseguita su tempdb. Quindi il sovraccarico è ancora più basso.

— usr

0

Credo che ci siano altri problemi nell'applicazione se si ottengono deadlock. L'isolamento dello snapshot di solito aiuta a ridurre i blocchi di attesa, ma la radice dei deadlock è di solito metodi di accesso diversi nell'applicazione che dovrebbero essere evitati aderendo a un modello coerente. Le discussioni sugli deadlock sono complicate e ci sono molte risorse dedicate a loro.

Il DBA ha ragione a preoccuparsi di cambiare il livello di isolamento in uno snapshot poiché aumenta il carico sul tempDB. Consiglio di andare all'isolamento dell'istantanea in generale, ma penso che sia solo una parte dell'affrontare i tuoi deadlock. Potresti finire con scritture sporche, in cui una transazione aggiorna la riga A quindi B e un'altra transazione aggiorna la riga B quindi A.

— Robert-Ryan.
fonte