T-SQL + 1С: как правильно удалять очень много записей

Обработки - Свертка базы

Свёртка (архивация) больших объёмов данных 1С часто выполняется средствами SQL Server. Эта публикация рассказывает о том, как правильно использовать простую команду DELETE на больших объёмах данных. Даются советы по оптимизации свёртки данных средствами T-SQL.

Сразу скажу, что выполнять свёртку большой таблицы следующей командой, это очень плохая идея:

DELETE [_AccumRg1234] WHERE [_Period] < @Period;

Дело в том, что если в выборку попадёт больше 5000 записей, то SQL Server может применить эскалацию блокировок до уровня таблицы и вся работа с ней для других транзакций будет невозможна. Однако блокировка всей таблицы может быть использована SQL Server не только по этой причине. Есть ещё ряд других условий, при которых это может произойти. Например, превышение определённого порога пямяти, используемого SQL Server. Подробнее об этом можно прочитать в онлайн документации Microsoft SQL Server Books Online. Факт остаётся фактом - использование команды DELETE "в лоб" может создать большие проблемы для параллельной работы пользователей.

Кто-то может сказать, что, как правило, администраторы баз данных 1С отключают возможность эскалации блокировок до уровня таблиц на уровне SQL Server. Да, это действительно так. Однако не все знают, что это не отменяет эскалации блокировок до уровня страниц пямяти SQL Server, размер которых равен 8 Кб.

Таким образом, правильным использованием команды DELETE является удаление больших объёмов данных небольшими порциями в цикле. Шаблоном такого кода может быть следующий скрипт:

DECLARE @RowsAffected int = 1;
DECLARE @RowsToDelete int = 4000;

WHILE @RowsAffected > 0
BEGIN
   DELETE TOP(@RowsToDelete) [_AccumRg1234] WHERE [_Period] < @Period;
   SET @RowsAffected = @@ROWCOUNT;
END

Этот вариант значительно лучше первого, но он всё ещё может страдать от проблемы эскалации блокировок до уровня страниц (page locks). Если это то, что происходит в вашем случае, то можно попробовать использовать хинты (hints) SQL Server. Вкратце, хинты это специальные инструкции SQL Server, которые заставляют его для отдельных команд использовать поведение отличное от принятого по умолчанию. В русском переводе можно ещё встретить термин "табличные указания". Например таким хинтом является ROWLOCK. Это табличное указание заставляет SQL Server, использовать блокировку на уровне записей  и не применять никаких эскалаций. Конечно же это может создать дополнительную нагрузку на "железо", но иногда без этого не обойтись. Использование этого хинта выглядит следующим образом:

DELETE TOP(@RowsToDelete) [_AccumRg1234] WITH (ROWLOCK) WHERE [_Period] < @Period;

Что интересно: я как-то использовал такую команду для свёртки таблицы, которая насчитывала десятки миллионов записей. Свёртка выполнялась в "боевой" базе в рабочее время. Иногда без этого тоже никак. Использование обычной команды DELETE давало множество блокировок на уровне страниц памяти SQL Server. Конфликт происходил в основном из-за интенсивного обмена данными, который имел место быть в этой базе и на код которого не было возможности повлиять в обозримом будущем. Всё было очень плохо. Было принято решение использовать "тяжёлую артиллерию" в виде хинтов.

По началу применение хинта ROWLOCK не дало прироста производительности, а даже наоборот ухудшило показатели. Правда блокировок на уровне страниц удалось избежать. На тот момент времени переменная @RowsToDelete имела значение 10000. Грубо говоря, команда выполнилась за 5 минут. Однако, увеличив это значение до 100000, команда выполнилась ровно за те же самые 5 минут! И это дало значительный прирост производительности по сравнению с вариантом без ROWLOCK! Затем это значение было увеличено до 500000 и эта история завершилась счастливым концом =)

Мораль этой истории заключается в том, что до тех пор, пока вы не попробовали все возможные варианты, не делайте окончательных выводов. Часто бывает так, что успех ждёт вас прямо за углом =)

В заключение я хотел бы поделиться ещё парой "хитростей" на тему массового удаления записей в таблицах SQL Server:

1. Иногда бывает выгоднее использовать команду TRUNCATE TABLE. Идея заключается в том, что сначала выполняется копирование тех записей, которые останутся после свёртки в какую-нибудь вспомогательную таблицу. Затем выполняется команда TRUNCATE, которая очень быстро очищает всю основную таблицу (гораздо быстрее команды DELETE). После этого сохранённые ранее записи возвращаются обратно в основную таблицу. Это выглядит примерно вот так:

INSERT [_AccumRg1234_Save]
SELECT * FROM [_AccumRg1234] WHERE [_Period] >= @Period;

TRUNCATE TABLE [_AccumRg1234];

INSERT [_AccumRg1234]
SELECT * FROM [_AccumRg1234_Save];

2. Иногда есть возможность распараллелить удаление записей по нескольким соединениям (сессиям) SQL Server. Если быть кратким, то нужно найти какой-то разделитель для удаляемых записей таблицы, например, таким разделителем может быть месяц. То есть один поток (сессия) выполняет команду по удалению записей января, второй - февраля и так далее. Можно по типам регистраторов так делать и т.п. Зависит от ситуации. Единственное, о чём следует помнить, что слишком большое количество открываемых одновременно соединений SQL Server может в какой-то момент не понравиться и он их начнёт просто сбрасывать. Обычно рекомендуется использовать количество активных потоков (сессий) по количеству ядер сервера. Ну и, естественно, не следует забывать, что любое распараллеливание нагружает оборудование. Если нет свободных ресурсов по "железу", то не стоит этого делать.

См. также

Комментарии
1. c+ + (ture) 228 21.12.16 10:13 Сейчас в теме
select 1
while(@@ROWCOUNT>0)
DELETE TOP(500) [_AccumRg1234] WHERE <...>;

Ты был близок!

Если все то транкейт.
Если мало оставить, то копируй малую часть во времянку, транкейти, и копируй назад.
2. Михаил Максимов (МихаилМ) 21.12.16 17:01 Сейчас в теме
автор ни слова не сказал о кластером индексе либо о дополнительном индексировании.
3. Дмитрий Жичкин (zhichkin) 209 21.12.16 18:13 Сейчас в теме
(2) Я прошу прощения, но я не понял Вашего комментария. У Вас какой-то вопрос, который Вы решили не задавать? Или у Вас есть уточняющая публикацию информация, которой Вы решили не делиться?

По основному тексту статьи с индексами делать ничего не надо - свёртка выполняется "на бою". С таблицей работают пользователи. Фрагментация индекса неизбежна. Для этого существуют регламентные задания и прочее. Можно ещё поговорить о логах SQL Server и других сопутствующих темах ...

По поводу варианта с использованием TRUNCATE, да - там есть такая тема. Индексы на таблице save создавать вообще не нужно. На основной таблице, как вариант, можно их дропнуть и создать потом заново. Не стал об этом писать, так как основной мотив статьи - свёртка "на бою" параллельно основной работе пользователей.
4. c+ + (ture) 228 22.12.16 11:11 Сейчас в теме
(3) ээ-э.. индексы?
...индексы фрагментируются и разок другой можно их переиндексировать руками, а потом лучше воткнуть в обслуживание.
...запрос не продолжается, а всякий раз начинается с начала (но это весчь очевидная)

Вот что действительно никто не сказал, так это режим работы сервера при удаление большого объема флуда из таблицы - можно потребовать максимальный приоритет и не уступать место другим потокам (типа крут бесконечно), тогда в сос уходить не будет (хотя это вроде тоже весчь очевидная)
5. Михаил Максимов (МихаилМ) 23.12.16 12:05 Сейчас в теме
так же как и отбирать , так и удалять записи таблицы быстрее всего по кластерному индексу.

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


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

если удаляется меньше половины записей, то этот способ быстрее, чем способ с транкетом.
6. Дмитрий Жичкин (zhichkin) 209 23.12.16 15:45 Сейчас в теме
(5) Идея понятна. Спасибо за дополнение.
Честно говоря, мне даже в голову не пришло, что что-то можно удалять не по индексу =)
Кстати сказать, пример в публикации использует отбор по полю _Period, которое является первым полем кластерного индекса для регистров накопления. В данном случае кластерный индекс будет использован.
7. Марат Хафизов (Painted) 16 09.01.17 10:05 Сейчас в теме
Конструкцию
INSERT [_AccumRg1234_Save]
SELECT * FROM [_AccumRg1234] WHERE [_Period] >= @Period;
можно заменить на
SELECT *
INTO [_AccumRg1234_Save]
FROM [_AccumRg1234] WHERE [_Period] >= @Period;
которая работает, как будто бы, быстрее.
8. Дмитрий Жичкин (zhichkin) 209 09.01.17 10:11 Сейчас в теме
(7) Зачем гадать что быстрее ? Планы запросов в студию ...
9. Марат Хафизов (Painted) 16 09.01.17 13:51 Сейчас в теме
(8)
Зачем гадать что быстрее ?
С чего вы взяли, что я гадаю? Я не гадаю, я читаю обзоры.
Даже не целиком обзоры, а лишь ключевые фразы.
Пример ключевой фразы "As we can see the SELECT...INTO was considerably faster 489ms compared to 3241ms." ))
10. Дмитрий Жичкин (zhichkin) 209 09.01.17 15:32 Сейчас в теме
(9) Извините, но Вы написали: "которая работает, как будто бы, быстрее". Это выглядит как неуверенность в своих словах.

Эта ссылка и объяснения показались мне более понятными и обстоятельными: http://stackoverflow.com/questions/6947983/insert-into-vs-select-into. Можно сказать, что Вы правы ... частично, так как таблица [_AccumRg1234_Save] в моём примере не является временной. Если использовать временную таблицу, как Вы предлагаете, то нужно весь код удаления в обязательном порядке заключить в одну транзакцию между BEGIN TRANSACTION и COMMIT TRANSACTION. В примере этого нет, и это не просто так. Если выполнение программы вдруг "упадёт" после TRUNCATE, то в моём примере данные останутся в таблице [_AccumRg1234_Save] и не будут потеряны.
11. Геннадий dotPRICE.ru (dotPRICE.ru) 41 13.01.17 09:31 Сейчас в теме
Наверное, можно оптимизировать код и убрать 1 лишний цикл:

DECLARE @RowsToDelete int = 4000;
DECLARE @RowsAffected int = @RowsToDelete;

WHILE @RowsAffected = @RowsToDelete
...
...
12. Дмитрий Жичкин (zhichkin) 209 13.01.17 09:43 Сейчас в теме
(11) Простите, но я как-то с утра не могу понять где лишний цикл ? Итерация, наверное, точнее сказать ...
13. Геннадий dotPRICE.ru (dotPRICE.ru) 41 13.01.17 09:48 Сейчас в теме
Если @RowsAffected > 0 но < @RowsToDelete, следущая итерация удалит нулевое кол-во записей.
14. Дмитрий Жичкин (zhichkin) 209 13.01.17 10:55 Сейчас в теме
(13) Удаляем 5000 записей.
1. итерация: удалили 4000, осталась 1000.
2. итерация: удалили 1000, осталось 0.
3. итерация: @RowsAffected = 1000, удаляем 0 записей ...
Вы правы ...
Однако, а что если, пока мы удаляем записи, другая транзакция их туда добавляет ?
При определённых условиях этот цикл может быть вечным ... =)
dotPRICE.ru; +1 Ответить 1
15. Геннадий dotPRICE.ru (dotPRICE.ru) 41 13.01.17 11:25 Сейчас в теме
(14) а при WHILE @RowsAffected > 0 он будет вечным + 1
:)
16. Дмитрий Жичкин (zhichkin) 209 13.01.17 11:43 Сейчас в теме
(15) Чтобы расставить все точки над i:
при WHILE @RowsAffected = @RowsToDelete цикл не будет вечным и после его выполнения в базе могут остаться записи, которые подходят под условие удаления.
Мой пример был взят из боевой базы. Первая версия была вообще такая: WHILE EXISTS(SEL ECT 1 FR OM ... отсюда и такая логика.
17. Геннадий dotPRICE.ru (dotPRICE.ru) 41 13.01.17 12:35 Сейчас в теме
(16) Все правильно. Выбор варианта зависит от задачи. :)
Оставьте свое сообщение