Как избежать этой ситуации блокировки в .NET 3.0 / WinForms / SQLServer 2005?

Question

Приложение 1 -

• Открывает SqlConnection и SqlTransaction для базы данных SQLServer 2005
• Вставляет запись в таблицу1
• Не совершает и не откатывает SqlTransaction - намеренно поддерживает это, чтобы продемонстрировать / описать проблему

Приложение 2 -

• Открывает SqlConnection и SqlTransaction для базы данных SqlServer 2005
• Пытается выполнить этот запрос - «ВЫБЕРИТЕ СЧЕТЧИК (Id) ИЗ Table1»

Table1 - Id - это поле Identity. Имя - это поле varchar. Других полей в таблице нет

Приложение 2 не может выполнить запрос «SELECT ...». Кажется, что Table1 заблокирован или заблокирован вставкой, сделанной в Приложении 1.

Хотя вышеупомянутый сценарий вымышлен - он демонстрирует проблему, с которой мы сталкиваемся адекватно. Мы хотим иметь возможность открывать длительную SqlTransaction (возможно, часы) и делать много вставок / обновлений через эту SqlTransaction.

Мы разрабатываем приложение для преобразования данных, которое должно выполнить большую обработку большого количества данных, прежде чем их можно будет вставить / обновить в базу данных. Преобразование данных должно происходить, пока у нас основное приложение на основе WebForms работает на той же базе данных SQLServer 2005, в которой мы хотим выполнить длительную транзакцию.

Все таблицы в нашем приложении сегментированы полем ClientID из таблицы ClientMaster. Например, если у нас есть таблица CollegeMaster, то она будет иметь поле ClientID как часть первичного ключа и поле ID для своей собственной идентификации. Преобразование данных начинается с создания нового ClientID, и это новое поле ClientID используется во всех других таблицах.

В идеале на все запросы, подобные тому, который упомянут в Приложении 2, не должна влиять длительная транзакция. Эти запросы должны только читать / использовать данные, которые уже зафиксированы и продолжают работать, а не блокироваться из-за длительной транзакции. Что может сделать Приложение 1 для обеспечения этого?

Answer 1

Возможно, вы захотите взглянуть на эту функцию Sql 2005. Похоже, это может помочь вам. Это более новый механизм блокировки, который вы должны включить в БД, но, очевидно, он имеет гораздо меньше блокировок.

http://msdn.microsoft.com/en-us/library/ms177404(SQL.90).aspx

Answer 2

Я рекомендую не иметь долгосрочных транзакций; однако, с этим сказал:

Вы можете снизить уровень изоляции транзакции, используя подсказки. Обычно я не рекомендую эту практику, но если ваш выбор будет делать:

выберите количество (id) из таблицы 1 (NOLOCK), вы, по сути, обойдете все блокировки таблицы; однако, имейте в виду, что вы можете и получите грязные чтения, фантомные чтения (где данные присутствуют одну минуту, но не следующую). Если ваши запросы полностью сегментированы, то все будет в порядке. Есть также другие советы, которые вы можете посмотреть в Книгах онлайн.

Другой вариант - выполнить всю вашу длительную обработку в промежуточных таблицах, а затем выполнить одно окончательное копирование / вставку в таблицу1. Это поможет сократить продолжительность транзакции.

Answer 3

Почему бы не сохранить все изменения в наборе данных и зафиксировать все сразу? Разве это не решит проблему длительных транзакций?

Answer 4

Причина длительной транзакции для преобразования данных заключается в том, что SQLServer 2005 уже имеет функцию отката. В случае возникновения проблем с преобразованием данных, мы можем использовать эту возможность для отката вставленных / обновленных данных.

Причина, по которой составляются промежуточные таблицы, заключается в том, что у нас есть много полей идентификации, которые в параллельной ситуации будет трудно отследить. Выполняя преобразование из фактических исходных таблиц в промежуточные таблицы, мы будем генерировать один набор значений идентичности в «основных» таблицах, которые в дальнейшем будут использоваться в «дочерних» промежуточных таблицах. Затем, передавая данные из промежуточных таблиц в целевые таблицы, мы должны убедиться, что новые значения идентификаторов, которые генерируются для «главных» таблиц, отображаются и правильно распространяются на «дочерние» таблицы.