Isolamento TSQL Snapshot

Question

Utilizzando SQL2k5, ho una tabella di gestione temporanea che contiene le colonne che popoleranno numerosi altri tavoli. Per esempio, una dichiarazione come questa:

 INSERT INTO [appTable1] ([colA], [colB])
 SELECT [appTable1_colA], [appTable1_colB]
 FROM [stageTable]

Un trigger su [appTable1] sarà quindi popolare i valori della colonna identità delle nuove righe inserite nuovamente dentro [stageTable]; per questo esempio, diremo che è [stageTable]. [appTable1_ID] che vengono poi inseriti in altre tabelle come un FK. dichiarazioni più simili succedono come:

 INSERT INTO [appTable2] ([colA], [colB], [colC], [appTable1_FK])
 SELECT [appTable2_colA], [appTable2_colB], [appTable2_colC], [appTable1_ID]
 FROM [stageTable]

Questo processo continua attraverso numerosi tavoli come questo. Come potete vedere, non sto tra cui una clausola WHERE sulle seleziona da tabella di gestione temporanea come questa tabella viene troncato alla fine del processo. Tuttavia, questo lascia la possibilità di un altro processo di aggiunta record a questa tabella di gestione temporanea nel bel mezzo di questa transazione e quei record non conterrebbe i FKS precedentemente popolate. Dovrei voler rilasciare questa dichiarazione per evitare questo:?

 SET TRANSACTION ISOLATION LEVEL SNAPSHOT

Se questa è la soluzione migliore, quali sono gli aspetti negativi di fare in questo modo?

Answer 1

Si può aggiungere un batch id alla tabella di gestione temporanea, in modo che si può utilizzare in cui le clausole per garantire che si sta lavorando solo sul lotto originale di record? Qualsiasi processo che aggiunge record alla tabella di gestione temporanea avrebbe dovuto utilizzare un nuovo, unico lotto id. Questo sarebbe più efficiente (e più robusto) di seconda isolamento dello snapshot, credo.

Answer 2

Tutti i livelli di isolamento, tra cui fotografia, influenzano legge solo. Seleziona da stageTable non vedranno inserti uncommited, né si bloccheranno. Non sono sicuro che risolve il problema di buttare tutto nel stageTable senza alcun riguardo per la proprietà. Cosa succede quando la transazione finalmente impegna, lo stageTable è lasciato con tutti i risultati intermedi pronto per essere letto dal prossimo transazione? Forse si dovrebbe usare un #stageTable temporanea che garantirà un naturale isolamento tra i thread concurent.

Per capire il costo di utilizzo di isolamento dello snapshot, leggere versioni delle righe Uso delle Risorse :

• spazio extra consumati in tempdb
• spazio in più consumato in ogni riga della tabella dei dati
• spazio in più consumato in archiviazione BLOB per i grandi campi