Множественные отчеты об обновлении/таблицы переходных процессов/предотвращение блокировки

Question

Я ищу несколько рекомендаций относительно наилучшего подхода к обработке данных в базе данных с использованием SQL Server.

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

Две мысли у меня были на это следующим образом:

1. Все обновления заявления содержат подсказку ROWLOCK, так что блокировка страниц не будет происходить, которые охватывают различные родословные.
2. Измените уровень изоляции - грязные чтения никогда не произойдут. Может ли кто-нибудь пролить свет, на котором может быть лучший подход к этой ситуации?

Answer 1

Если предположить, что таблица будет выглядеть примерно так:

CREATE TABLE MyTable 
( 
    ID INT IDENTITY(1,1), 
    LineageId INT NOT NULL, -- FK to Lineage 
    Col1 ... 
    Col2 ... 

    PRIMARY KEY CLUSTERED(ID), 
    FOREIGN KEY LineageId REFERENCES Lineage(LineageId) 
) 

1. Рекомендуют изменить кластерный индекс на вашем столе, чтобы LineageId (но см ниже). Это должно гарантировать, что страницы с наименьшим количеством обновлений будут обновлены, если SQL активирует блокировку строки до блокировки страницы. Недостатком этого является то, что LineageId не уникален, поэтому SQL добавит уникальный идентификатор. Таким образом, перед изменением кластеризации, если ваш PK увеличивается, и если вы обнаружите, что почти все строки в вашей таблице уже смежно расположены LineageId (например, если данные вставляются в эту таблицу с помощью однопоточного пакетного задания), то кластеризация по приращение суррогатного pkey было бы предпочтительнее, поскольку это позволяет избежать уникальности (лучше узость).

2. Подсказка ROWLOCK может помочь, хотя это не гарантия. http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/60238304-04e8-4f98-84d1-3ddf1ed786a9

3. Установка уровня изоляции для READ UNCOMMITTED или SNAPSHOT или с помощью (NOLOCK) намек должен был бы сделать для других одновременных запросов к, чтобы избежать их блокировки во время ваших обновлений LineageId к вашему столу. Это будет радикальной мерой, и незафиксированные чтения могут привести к проблемам целостности.