Я работаю над приложением C # + SqlServer, которое обрабатывает большие объемы данных.
В данный момент наша основная проблема связана с масштабной операцией DELETE с одной транзакцией: администраторы баз данных предложили разделить эту монолитную транзакцию.во многие транзакции, чтобы получить следующие результаты:
- меньший журнал транзакций
- меньше строк для отката в случае ошибки тайм-аута
- меньше проблем с синхронизацией / блокировкой,из-за сокращения времени транзакции
(В нашем сценарии не проблема отказаться от атомарности отдельной транзакции: семантически мы могли бы выполнить TRUNCATE, но не можем, потому что мы фильтруем строкинеобходимо удалить)
Мне интересно, есть ли какая-либо разница с точки зрения управления транзакциями и синхронизации между выдачей одного (Transact) оператора SQL, содержащего цикл, подобный
SET @r = 1;
WHILE @r > 0
BEGIN
BEGIN TX;
DELETE TOP (100000)
[OUR_BIG_TABLE]
WHERE ...;
SET @r = @@ROWCOUNT;
COMMIT TX;
END
и зацикливание кода приложения (C #), выдавая несколько DELETE TOP(100000) ... в разных транзакциях, обработанных клиентом.
Мне кажется, что оператор с одним SQL-запросом имеет лучшую производительность из-за уменьшенного количества обходов в сети.Вместо этого у меня есть сомнения относительно синхронизации / блокировки между моей операцией удаления и другими параллельными действиями в одной и той же таблице;Итак, мой вопрос, в частности: Есть ли разница между подходами, описанными выше, с точки зрения возможности для транзакций, выпущенных другим клиентом, чередовать между транзакциями, выпущенными нашим процессом ?
IЯ думаю, что нет никакой разницы (с точки зрения, изложенной выше) между предлагаемыми подходами, поскольку контролируемые клиентом транзакции эквивалентны BEGIN TX ... COMMIT TX заявлениям, но я предпочитаю подтверждение того, кто знает больше меня...
Заранее спасибо!