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

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

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

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

Попробуйте добавить подсказку with (nolock) к оператору чтения SQL View.

Лично, если вы всегда собираетесь вводить время простоя для запуска пакетного процесса для таблицы, я думаю, вам следует управлять взаимодействием с пользователем на уровне бизнеса / доступа к данным. Представьте объект управления таблицей, который отслеживает подключения к этой таблице и контролирует пакетную обработку.

Когда новые пакетные данные готовы, объект управления останавливает все новые запросы запросов (возможно, даже ставит их в очередь?), Позволяет завершить существующие запросы, запускает пакет, а затем повторно открывает таблицу для запросов. Объект управления может вызвать событие (BatchProcessingEvent), которое слой пользовательского интерфейса может интерпретировать, чтобы сообщить людям, что таблица в настоящее время недоступна.

Мои 0,02 доллара США,

Нейт

Прочтите, что вы используете SSIS

, вы можете использовать компонент TableDiference из: http://www.sqlbi.eu/Home/tabid/36/ctl/Details/ mid / 374 / ItemID / 0 / Default.aspx

_{(источник: sqlbi.eu )}

Таким образом, вы можете применять изменения к таблице, ОДИН за ОДИН, но, конечно, это будет будет намного медленнее и в зависимости от размера таблицы потребует больше ОЗУ на сервере, но проблема с блокировкой будет полностью решена.

Почему бы не использовать транзакции для обновления информации, а не операцию усечения.

Усечение не регистрируется, поэтому оно не может быть выполнено в транзакции.

Если ваша операция выполнена в транзакции существующие пользователи не пострадают.

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

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

Мы делаем это в наших часто используемых системах, и у нас не было никаких проблем. Однако, как и во всем, что касается базы данных, единственный способ убедиться, что это поможет, - это внести изменения в dev, а затем провести нагрузочное тестирование. Не зная, что еще делает ваш пакет SSIS, он все равно может вызывать блоки.

Одним из возможных решений было бы минимизировать время, необходимое для обновления таблицы.

Сначала я бы создал промежуточную таблицу для загрузки данных из хранилища.

Если вам нужно выполните «вставки, обновления и удаления» в финальной таблице

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

Table Products:
    ProductId       int
    QuantityOnHand  Int

И вам нужно обновить QuantityOnHand со склада.

Сначала создайте промежуточную таблицу, например:

Table Prodcuts_WareHouse
    ProductId       int
    QuantityOnHand  Int

Затем создайте таблицу «Действия» следующим образом:

Table Prodcuts_Actions
    ProductId       int
    QuantityOnHand  Int
    Action          Char(1)

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

1.Обрезать таблицу Prodcuts_WareHouse

2.Урезать таблицу Prodcuts_Actions

3. Заполнить таблицу Prodcuts_WareHouse указанием данные из хранилища

4. Заполните таблицу Prodcuts_Actions следующим образом:

Вставки:

INSERT INTO Prodcuts_Actions (ProductId, QuantityOnHand,Action)
SELECT     SRC.ProductId, SRC.QuantityOnHand, 'I' AS ACTION
FROM         Prodcuts_WareHouse AS SRC LEFT OUTER JOIN
                      Products AS DEST ON SRC.ProductId = DEST.ProductId
WHERE     (DEST.ProductId IS NULL)

Удаляет

INSERT INTO Prodcuts_Actions (ProductId, QuantityOnHand,Action)
SELECT     DEST.ProductId, DEST.QuantityOnHand, 'D' AS Action
FROM         Prodcuts_WareHouse AS SRC RIGHT OUTER JOIN
                      Products AS DEST ON SRC.ProductId = DEST.ProductId
WHERE     (SRC.ProductId IS NULL)

Обновления

INSERT INTO Prodcuts_Actions (ProductId, QuantityOnHand,Action)
SELECT     SRC.ProductId, SRC.QuantityOnHand, 'U' AS Action
FROM         Prodcuts_WareHouse AS SRC INNER JOIN
                      Products AS DEST ON SRC.ProductId = DEST.ProductId AND SRC.QuantityOnHand <> DEST.QuantityOnHand

До сих пор у вас нетt заблокировал финальную таблицу.

5. При обновлении транзакции финальная таблица:

BEGIN TRANS

DELETE Products FROM Products INNER JOIN
Prodcuts_Actions ON Products.ProductId = Prodcuts_Actions.ProductId
WHERE     (Prodcuts_Actions.Action = 'D')

INSERT INTO Prodcuts (ProductId, QuantityOnHand)
SELECT ProductId, QuantityOnHand FROM Prodcuts_Actions WHERE Action ='I';

UPDATE Products SET QuantityOnHand = SRC.QuantityOnHand 
FROM         Products INNER JOIN
Prodcuts_Actions AS SRC ON Products.ProductId = SRC.ProductId
WHERE     (SRC.Action = 'U')

COMMIT TRAN

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

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

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

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

Билл

Если в вашем распоряжении Enterprise Edition SQL Server, то могу ли я предложить вам использовать технологию секционирования SQL Server.

Вы можете разместить необходимые в настоящее время данные в «Живой» раздел и обновленная версия данных в «Вторичном» разделе (который доступен не для запросов, а для администрирования данных).

После того, как данные были импортированы во «Вторичный» раздел, вы можете мгновенно ПЕРЕКЛЮЧИТЬ «LIVE» раздел OUT и «Secondary» раздел IN, что приводит к нулевому времени простоя и отсутствию блокировки.

После того, как вы сделали переключение, вы можете приступить к усечению больше не нужных данных, не затрагивая пользователей новых данных в реальном времени (ранее вторичный раздел).

Каждый раз, когда вам нужно выполнить задание импорта, вы просто повторяете / обращаете процесс.

Чтобы узнать больше о секционировании SQL Server, см .:

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

Или вы можете просто спросить меня: -)

EDIT:

Кстати, для решения любых проблем с блокировкой вы можете использовать технологию управления версиями строк SQL Server.

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