Может обновиться до поиска причины ParentTable в дочерней таблице с отношением внешнего ключа в SQL SERVER 2008

Question

следующие таблицы являются частью дизайна базы данных. У меня нет некластеризованного индекса в моих иностранных ключах.

Я блокирую таблицу PatientChartImages с помощью следующей команды

begin transaction t1
update PatientChartImages set RotationAngle = 55
--ROLLBACK TRANSACTION t1

После этого все обновления пользовательской таблицы истекают. Я прикрепляю трассировку SqlProfiler. Выбранная команда на этом изображении вызывает TimeOut. Так как я обновляю PatientChartImages и CreatedByUserId в PatientChartImages не является FK для основной пользовательской таблицы, почему поиск Fk вызывает TimeOut.

Согласно Мне, происходит следующая последовательность

1. Транзакция имеет эксклюзивную блокировку PatientChartImages
2. Поскольку PatientChartid в PatientChartImages является FK для PatientChartid в PatientCharts, это вызывает поиск внешнего ключа и блокирует таблицу PatientCharts.
3. Подобно тому, как CreatedByUserId в таблице PatientCharts представляет собой FK to UserID в таблице Users, так что поиск FK также блокирует таблицу Users.

Правильно ли мое понимание этого? Пожалуйста, предложите, а также скажите мне, как я могу предотвратить этот вид блокировки.

Трассировка снимка экрана

Answer 1

Я почти уверен, что вы правильно понимаете ситуацию.

Как вы, очевидно, знаете, при выполнении транзакции SQL любое обновление, которое может повлиять на обновляемые вами таблицы, должно быть предотвращено.Подумайте о принципах ACID (http://en.wikipedia.org/wiki/ACID).

Я думаю, что единственный способ обойти это - использовать READ UNCOMMITTED или NOLOCK

Реализация грязного чтения или блокировки уровня 0, что означаетчто общие блокировки не выдаются и исключительные блокировки не учитываются. Когда установлена ​​эта опция, можно читать незафиксированные или грязные данные, значения в данных могут быть изменены, а строки могут появляться или исчезать в наборе данных до концатранзакция. Этот параметр имеет тот же эффект, что и установка NOLOCK для всех таблиц во всех операторах SELECT в транзакции. Это наименее ограничивающий из четырех уровней изоляции.

Вы можете работатьрискнуть этим для себя.

Я на самом деле думаю, что ответ заключается в том, чтобы сделать транзакцию как можно более короткой и мириться с ней, поскольку она делает это только для защиты целостности данных, например, только запускает и заканчиваеттранзакция вокруг фактических операций обновления.

Надеюсь, это немного поможет.