РОЗВ'ЯЗАННЯ РОЗВИТКУ ІЗОЛЯЦІЇ РОЗВИТКУ І ТРУНКАТ?

Я сподіваюся, що хтось може пролити трохи світла на таку поведінку, яку я не очікував щодо ізоляції SNAPSHOT проти TRUNCATE.

База даних: Дозволити ізоляцію знімків = Істинно; Читає зроблений знімок увімкнено = помилково.

Процедура1 (Замінює вміст foo таблиці з давно запущеного комплексу SELECT з великою кількістю з'єднань):

BEGIN TRAN; 
TRUNCATE TABLE foo; 
INSERT INTO foo SELECT...; 
COMMIT;

Порядок2 (Читає з таблиці Foo):

SET TRANSACTION ISOLATION LEVEL SNAPSHOT; 
SELECT * FROM foo;

Якщо Процедура1 працює під час виконання Процедури2, Процедура2 затримується зачеканням LCK_M_SCH_S (відповідно до sp_WhoIsActive) до завершення Процедура1. І коли процедуру2 завершено, вона викликає цей виняток:

Не вдалося здійснити транзакцію ізоляції знімків у базі даних «DatabaseName», оскільки об’єкт, до якого звертається за допомогою оператора, був змінений оператором DDL в іншій одночасній транзакції з моменту початку цієї транзакції. Це заборонено, оскільки метадані не є версійними. Одночасне оновлення метаданих може призвести до невідповідності, якщо її змішати з ізоляцією знімків.

Однак Microsoft не перераховує TRUNCATE як заяву DDL, заборонену в ізоляції SNAPSHOT: http://msdn.microsoft.com/en-us/library/bb933783.aspx

Ясно, що я не розумію щось правильно, так як я б очікував, що найкращий випадок Порядку2 негайно поверне найсвіжіші дані з таблиці перед TRUNCATE або найгірший випадок, коли буде проведено процедуру1, а потім поверне новий вміст стіл. Ви можете допомогти?

Перелік 'DDL'перерахованих операцій не є вичерпним (і TRUNCATE TABLEце не єдиний пропуск із цього списку). Чи TRUNCATE TABLEє це DMLчи DDLє загрозливим питанням у SQL Server із переконливими прикладами з обох сторін дебатів та вписується обома способами в Книги онлайн.

З точки зору транзакції з ізоляцією знімків, усікання має важливу якість зняття Sch-Mблокування , що пояснює блокування (тому що RCSIі SIвсе-таки набувають Sch-Sзамки ); а також стикається з внутрішньою версією метаданих (з внутрішніх причин *), що призводить до помилки 3961.

Отже, поведінка, яку ви бачите, очікується, просто не задокументована дуже добре.

* _{Поточна реалізація таблиці TRUNCATE не створює версії рядків. Нарізання версії метаданих - це найпростіший спосіб забезпечити правильну поведінку.}