0. zhichkin 352 21.12.16 01:21 Сейчас в теме

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

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

Перейти к публикации

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

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

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

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

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

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

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


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

если удаляется меньше половины записей, то этот способ быстрее, чем способ с транкетом.
6. zhichkin 352 23.12.16 15:45 Сейчас в теме
(5) Идея понятна. Спасибо за дополнение.
Честно говоря, мне даже в голову не пришло, что что-то можно удалять не по индексу =)
Кстати сказать, пример в публикации использует отбор по полю _Period, которое является первым полем кластерного индекса для регистров накопления. В данном случае кластерный индекс будет использован.
7. Painted 20 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 352 09.01.17 10:11 Сейчас в теме
(7) Зачем гадать что быстрее ? Планы запросов в студию ...
9. Painted 20 09.01.17 13:51 Сейчас в теме
(8)
Зачем гадать что быстрее ?
С чего вы взяли, что я гадаю? Я не гадаю, я читаю обзоры.
Даже не целиком обзоры, а лишь ключевые фразы.
Пример ключевой фразы "As we can see the SELECT...INTO was considerably faster 489ms compared to 3241ms." ))
10. zhichkin 352 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 48 13.01.17 09:31 Сейчас в теме
Наверное, можно оптимизировать код и убрать 1 лишний цикл:

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

WHILE @RowsAffected = @RowsToDelete
...
...
12. zhichkin 352 13.01.17 09:43 Сейчас в теме
(11) Простите, но я как-то с утра не могу понять где лишний цикл ? Итерация, наверное, точнее сказать ...
13. dotPRICE.ru 48 13.01.17 09:48 Сейчас в теме
Если @RowsAffected > 0 но < @RowsToDelete, следущая итерация удалит нулевое кол-во записей.
zhichkin; +1 Ответить
14. zhichkin 352 13.01.17 10:55 Сейчас в теме
(13) Удаляем 5000 записей.
1. итерация: удалили 4000, осталась 1000.
2. итерация: удалили 1000, осталось 0.
3. итерация: @RowsAffected = 1000, удаляем 0 записей ...
Вы правы ...
Однако, а что если, пока мы удаляем записи, другая транзакция их туда добавляет ?
При определённых условиях этот цикл может быть вечным ... =)
dotPRICE.ru; +1 Ответить
15. dotPRICE.ru 48 13.01.17 11:25 Сейчас в теме
(14) а при WHILE @RowsAffected > 0 он будет вечным + 1
:)
16. zhichkin 352 13.01.17 11:43 Сейчас в теме
(15) Чтобы расставить все точки над i:
при WHILE @RowsAffected = @RowsToDelete цикл не будет вечным и после его выполнения в базе могут остаться записи, которые подходят под условие удаления.
Мой пример был взят из боевой базы. Первая версия была вообще такая: WHILE EXISTS(SEL ECT 1 FR OM ... отсюда и такая логика.
17. dotPRICE.ru 48 13.01.17 12:35 Сейчас в теме
(16) Все правильно. Выбор варианта зависит от задачи. :)
18. nofx 26.01.18 18:31 Сейчас в теме
А такое можно провернуть если таблица ( неподчиненный регистр) учавствует в РИБе?
После truncate получится, что в соответсвующей таблице изменения (_ChnRg которая) будут записи на не существующие записи основной таблицы?
19. zhichkin 352 26.01.18 18:49 Сейчас в теме
(18) Всё верно. Удалять записи при помощи TRUNCATE нужно в обеих таблицах: основной и регистрации изменений. А в чём вопрос ?
20. nofx 27.01.18 20:02 Сейчас в теме
Да, собственно, имеется РИБ (порядка 30 баз) на 8.2. Одна таблица отключается из состава обмена, есть мысль её удалить на sql напрямую. Вопрос - обязательно таблицу изменений еще и чистить, её ведь платформа удалить и так должна. И еще вопрос - если удалить основные записи, а изменения нет, при функционирующих обменах с ней (еще), в таблицах изменения останутся ссылки на несуществующие строки видимо.(?) Как это отразится на обменах?
21. zhichkin 352 28.01.18 11:34 Сейчас в теме
(20) Добрый день, Сергей!
В Вашем случае все операции типовые - ничего удалять в SQL напрямую не нужно.
Таблица изменений объекта будет удалена автоматически платформой 1С в том случае, когда объект будет исключён из состава всех планов обмена, в которые он входит.
При удалении объектов, они регистрируются в таблице обмена и выгружаются как тип данных УдалениеОбъекта - по сути это контейнер для хранения ссылки или ключа записи удалённого объекта.
23. yelloo 28.01.18 16:01 Сейчас в теме
(21) Дмитрий, подскажите, пожалуйста, что за это за зверь "контейнер" (УдалениеОбъекта) и для чего он служит (имеется ввиду в обменах типовых конфигураций)?
Вот удалил я объект в источнике, далее он регистрируется в таблице изменений как "Объект удалён <УИД>". Что должно произойти после совершения обмена? Удаляться соответствия на эту ссылку в базе приёмнике?
24. zhichkin 352 28.01.18 19:36 Сейчас в теме
(23) УдалениеОбъекта (встроенная справка 1С):
Предназначен для удаления объекта базы данных. Объект хранит ссылку на объект базы данных и при обращении к методу Записать() производит удаление объекта базы данных, на который показывает ссылка. Кроме того, данный объект имеет свойство ОбменДанными, которое содержит параметры обмена данными, используемые при удалении объекта, на который показывает ссылка. Основное назначение данного объекта - переносить удаление объектов базы данных при использовании в составе других механизмов обмена данными.
28. yelloo 28.01.18 22:39 Сейчас в теме
(24) Но ведь удаление объекта не происходит, если в источнике его удалили и был выполнен обмен =\
Тем более, если в приёмнике имеются ссылки на него.
29. zhichkin 352 28.01.18 23:25 Сейчас в теме
(28) Дело происходит так:
1. В источнике удалили объект.
2. В источнике в таблице регистрации изменений зарегистрировалась ссылка на удалённый объект.
3. При выгрузке из источника платформа видит, что ссылка в таблице регистрации изменений "битая" - объект-то удалили. Такую ссылку она выгружает, "завернув" её в УдалениеОбъекта.
4. Приёмник принимает УдалениеОбъекта и знает, что внутри ссылка, которая была удалена в источнике.
Вот для такого сценария в основном и нужен тип "УдалениеОбъекта".
31. yelloo 29.01.18 08:26 Сейчас в теме
(29) подскажите, пожалуйста, что происходит после приема такого рода сообщения в приёмнике? Не могу в бсп (1.2.х) разобраться.
33. zhichkin 352 29.01.18 12:08 Сейчас в теме
(31) Происходит удаление объекта по ссылке или ключу записи.
35. yelloo 29.01.18 13:50 Сейчас в теме
(33) Без проверки ссылочной целостности???
36. zhichkin 352 29.01.18 15:09 Сейчас в теме
(35) Конечно же с проверками средствами самой платформы 1С.
22. nofx 28.01.18 15:42 Сейчас в теме
Немного не так. Сама таблица чистится (большая её часть, но не вся) чтобы её реструктуризация быстро прошла в последующем обновлении (в неё добавляется колонка и она исключается из обмена). Сама таблица в РИБе, функционирует обмен данными. Скорее всего, будет сделан способ c truncate через вспомогательную таблицу (вот). Вопрос - обмены не остановятся, битых ссылок не понаделается? Нужно ли еще удалять записи в другой таблице (пока она еще есть в базе)? Вот это непонятно мне...
25. zhichkin 352 28.01.18 19:52 Сейчас в теме
(22) Стало быть вопрос в реструктуризации. Так бы сразу и сказали.
Можно для начала почитать это: Ускорение реструктуризации таблиц
и это: Миллионы строк в таблицах 1С? Быстрая реструктуризация - не проблема!
26. nofx 28.01.18 21:22 Сейчас в теме
Нет, вопрос не в реструктуризации.Еще раз процитирую мой вопрос: "...обмены не остановятся, битых ссылок не понаделается? Нужно ли еще удалять записи в другой таблице (пока она еще есть в базе)?" Под "другой" таблицей имеется ввиду таблица изменений.
27. zhichkin 352 28.01.18 22:07 Сейчас в теме
(26) Задача не понятна. Удаляем записи ради чего ? Свёртка ?
Я понял так: Вы исключаете объект из состава плана обмена, который является единственным, в котором этот объект участвует. В таком случае платформа сама всё за Вас сделает: удалит регистрацию изменений для этого объекта. Затем возник вопрос добавления нового реквизита и реструктуризации. По этому поводу я дал ссылки.
Если всё-таки есть желание поработать на уровне SQL, то отвечаю на вопросы:

Обмены не остановятся ?
Непонятна суть вопроса. Если вопрос про блокировки и прочее, то зависит от уровня изоляции и гранулярности налагаемых блокировок. Для меня термин "обмены остановились" слишком широк. Нужна конкретика.

Битых ссылок не понаделается ?
Если не выполнять контроля ссылочной целостности, то конечно же понаделается.

Нужно ли удалять записи в таблице изменений ?
Ну конечно же нужно. Это тоже касается контроля ссылочной целостности базы.
30. nofx 29.01.18 00:40 Сейчас в теме
Спасибо за ответы.
Задам еще один: Что будет, если в базе удалить "напрямую" данные из независимого регистра сведений (без регистратора, не имеющего внешних ссылок),и на момент удаления эта таблица имеет "зарегистрированные изменения" в плане обмена. То есть, генерации типа "Удаление объекта" не будет. Как себя поведет 1С при загрузке,выгрузке данных? Что в таком случае придет в "приемник"?
32. zhichkin 352 29.01.18 12:06 Сейчас в теме
(30) В таком случае регистрация изменений останется. Источник выгрузит в целевую базу объекты типа УдалениеОбъекта. Приёмник примет их и удалит у себя. Дело в том, что УдалениеОбъекта генерируется при выгрузке. Логика примерно такая: у меня есть изменение, ищу объект по этому изменению в основной таблице, объекта нет - выгружаю УдалениеОбъекта.
34. nofx 29.01.18 13:30 Сейчас в теме
Ага, спасибо за информацию. Соответсвенно, при массовом удалении будет "куча" таких объектов в обменах.
37. zhichkin 352 29.01.18 15:09 Сейчас в теме
38. nofx 30.01.18 14:13 Сейчас в теме
Попробовал это проверить. Удалил, выгрузил из источника, посмотрел xml пакет, а там ничего нового не видно.(1С 8.2.19)
39. zhichkin 352 30.01.18 15:26 Сейчас в теме
(38) Чтобы понять что и как нужно показать состояние системы до, показать код и состояние системы после выполнения кода. Так я Вам ничего не скажу.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии


Программист 1С-проектов / Консультант 1С
Ульяновск
зарплата от 60 000 руб. до 120 000 руб.
Полный день

Удаленный консультант-разработчик 1С
Краснодар
зарплата от 60 000 руб. до 60 000 руб.
Полный день