Платформа 1С 8.2, в базе есть примерно 68 млн. документов одного вида, без табличных частей, около 35 млн. из них надо удалить с отбором по дате меньше определенной, ссылочная целостность не важна. Время простоя базы ограничено. Понятно, что средствами 1С быстро это сделать нереально. Как сделать это максимально быстро? Удалять в одной транзакции или бить на несколько, если на несколько, то как определить оптимальный с точки зрения скорости размер порции?

(0) порция = 1 месяц

(14) Точно быстрее будет, чем одной транзакцией? По месяцам это будет 15 транзакций, запустил на тестовой, сравню время с удалением одной транзакцией. Но интересно не только из опыта, но и теоретически понять как быстрее всего решить такую задачу.

(13)Если хочется быстрее, то надо нарисовать процедуру по удалению порциями с транзакциями для каждой порции. В которой, может быть, и создавать временно нужный индекс. Если нет подходящего. И размер порции подобрать эмпирически.  И эту процедуру запускать через ADO.

(15) когда в одной транзакции - не знаешь умер процесс или шевелится и ресурсов много надо.
а когда квантами - сразу видно, что процесс идет:)

а движения почему не удаляешь ?

(17) Конфигурация нетиповая, движения только по одному регистру накопления с одним регистратором, почистил раньше уже.

база большая?

в рабочей базе - truncate table, а потом из копии в нее bulk insert нужного

DELETE table_or_view
FROM table_sources
WHERE search_condition

(0) Быстрое   в ы б о р о ч н о е   удаление большого количества записей из раздутого регистра!? Нет сынок, это фантастика - намучились вволю уже. Если подскажете по-настоящему быстрый способ буду благодарен. (20) точно не быстро.

(0)Средствами скуля разделить на секции и потом уже секции грохать. В конце собрать все, как было.

(19) Размер удаляемой таблицы 15 GB, с учетом включенного сжатия на SQL.Это много?

(20) Спасибо, кэп.

(21) Регистр пока не рассматриваем, только документы с отбором по дате меньше.

рой в сторону (19) - это не журналируемые операции заточенные на большие разовые объемы данных

(25) тем более - на объектные данные еще и ссылки могут быть

(25) Вы уверены, что (27) исключено?

(24) delete - фигня по скорости, пробовал уже. Я бы (19) попробовал - вот bulk insert может ускорить.

(19) "а потом из копии в нее bulk insert нужного"
А как сделать bulk insert из таблицы SQL? Это команда вроде только с файлами работает?

а так?
1) select * into [destinationTable] from [sourceTable] where search_condition
2) подменить sourceTable на destinationTable.
3) похерить sourceTable.

(31) Индексы же потеряются

(28) Уверен. Кроме регистра накопления, который уже очищен, ссылок на этот документ нет.

(30) Ну в теории можно выгрузить в файл - из файла bulk insert, только не факт, что по времени это быстрее будет.

(32) + (33) = пофиг.

(30) ну можно обойтись insert into

можно через ssis, если он доступен

(36) Я у себя так и делаю - медленно выходит :(
Тоже большие таблицы

Вариант - ПодключитьОбработчикОжидания. Интервал вызова и количество документов на удаление обработка читает каждый раз из регистра сведений - можно подбирать нагрузку, чтоб и процесс шел, и пользователи работали. Иногда только так выкручиваемся, когда надо изменять большие объемы в фоновом режиме.

(0) Поставь платформу 8.3 ))) попробуй как удаляет. (офигеешь от разницы в скорости)
Попробуй грохнуть в файловом варианте.
а. так то в сиквеле 2 варианта
1. Выгрузка данных в промежуточную таблицу (те что надо оставить) truncate потом таблицы. и те что оставил заливаешь обратно
2. delete from tab where tab.date < date

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

(40) Не будет платформой быстрей, чем через SQL всеравно, даже пробовать не буду.

delete from можно делать пока все работают

(43) смотря какие блокировки скуль наложит

Эскалацию можно отключить на время

(43) Можно, но в этой задаче не нужно :) Да и потом статистики всеравно пересчитывать, можно словить тормоза на неактуальных статистиках.

(41) На SSD и простой delete за час справится с такой таблицей.

(47) Да, рабочий сервер на SSD да и памяти на скуле побольше, надеюсь раза в 2 быстрее, чем на тестовом будет. Но нет пределов совершенству :)

(46) в данном случае статистика не решает. статистика решает при добавлении

(10)если эти 68 млн Г копились столько лет  и никому не мешали  - ничего не мешает их так же потихоньку удалять.
каждый день по 100 тыс и все ...

Кстати - да, работу останавливать совсем не обязательно при удалении частями.

(49) Ну да, если при работе пользователей удалять много записей, кривая статистика на работе этих пользователей может сказаться отрицательно.

вот мы и вернулись к (20)
только допишем
DELETE TOP (ВашеЛюбимоеЧисло)
FROM ВашаТаблица
WHERE ДатаДокумента < 'НужнаяДата';

теперь запускаем это периодично, когда нагрузка на систему ниже определенной психологической отметки.

(10)А удалял командой "УдалитьОбъекты()" ?

(53) Это решение совсем другой задачи :)

(55) вам шашечки или ехать?

Мне уточнить у автора

(54) Так намного быстрее будет? Нет, по одному удалял.

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

Для MS SQL советуют использовать SET NO_BROWSETABLE ON
https://support.microsoft.com/ru-ru/help/885146/additional-information-about-the-for-browse-option-and-the-no-browseta

Обсуждение
http://www.sql.ru/forum/199345/udalenie-zapisey-iz-bolshoy-tablicy

(58)Да, попробуй

(56) Я принял вашу информацию к сведению :)

(59) А вот это интересно, попробую. Там еще хинт TABLOCK попробовать советуют. А SET NO_BROWSETABLE ON можно через ADODB сделать, или только в менеджмент студии?

(62) Думаю можно. Там как бы на сессию это действует скорее всего

(0)
Выбери во временную таблицу, те документы, которые нужно оставить, сделай truncate основной, вставь из временной таблицы обратно.

(64) Выборка может быть медленной ( если объём ), а потом ещё и вставка ( индекс так же будет вставляться ). Проще как я описал. И после удаления пересоздать удалённые индексы ( можно уже руками, предварительно сделав дефрагментацию ).

(59) Не ускорили советы по ссылкам, к сожалению. 2 млн записей удаляется 8 минут.

(66) WITH TABLOCK тоже не ускорил?

>2 млн записей удаляется 8 минут.

нормальный результат

(68) Ну, скажем так, приемлемый. Нормальный было бы все 35 млн за 8 минут. Но жить с этим можно, да.

(67) Нет, а вот WITH (TABLOCKX) процентов на 10 ускорил.

(70) Ты все индексы удалил кроме одного где Дата + Ссылка ( Дата в индексе должна быть первой )?
Можно ещё статистику подсобрать после удаления индексов приблизительную. И сообщи какие у тебя условия в where. И зачем тебе транзакция в этом действии ( ты хочешь чтобы пользователи в этот момент работали? )

(15) "2 млн записей удаляется 8 минут.

нормальный результат"


нормальный результат 15 летней давности когда запись 20 МБ/сек была нормальной. сейчас ~30 сукунд.

ошибся .
(72) относится к (68)

вопрос поставлен в (0)
некорректно


тк существуют две ситуации  1) избыток вычислительных ресурсов

2 ) недостаток.


большинство успешных решений для случая 1)
будут не успешными для случая 2)

(71) Не, индексы не удалял. Транзакция для надежности, вдруг что-нибудь пойдет не так. Хотя, наверное можно и без транзакции, если подумать. Кстати, в менеджмент студии Delete выполняется по умолчанию в транзакции или нет?

(72) Замедление из-за перестроения индексов в общем нормальное предположение, склонен с ним согласится.
Что касается ресурсов вопрос интересный конечно, недостатка ресурсов нет однозначно, насчет избытка не уверен...

(75) Нужно удалить индексы. Они удаляются пометкой удаления без физического удаления. Транзакция создаёт лишний объём работы, да и не нужна она в общем-то ( актуально для oracle с его undotablespace. Скорее всего для M$ так же хотя и не уверен, так как M$ всё равно в лог всё запишет и восстановление идёт из него если что. Транзакция влияет на блокировки ). DELETE работает без транзакции но в лог попадает разумеется, возможно режим логирования SIMPLE уменьшит объём логов ( не уверен. Надеюсь log файл на отдельном диске ). После удаления просто командой DML - CREATE INDEX создаёшь удалённые индексы. Время должно уменьшиться серьёзно, особенно если индексов много, да и индексные файлы сами по себе большие из-за большой таблицы. При относительно маленьком объёме оперативки может происходить много I/O.

(77) Затупил CREATE INDEX это команда семейства DDL https://ru.wikipedia.org/wiki/Data_Definition_Language

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


уточню (74) если с таблицами не работают реальные
много пользователей (olap) то одни варианты  , иначе - другие.

(79) OLTP https://ru.wikipedia.org/wiki/OLTP а не OLAP

(77) + Приведи что в конструкции после WHERE. Если удаление диапазонами, то оставь 1 индекс, где поле Дата будет первым полем и количество полей в индексе минимально.

(80) извините . написал коряво, НО правильно . читайте внимательней

(77)если с таблицей работают люди, то удаление индексов - преступление.

(83) в (0) Время простоя базы ограничено
в (41) есть 3-4 часа допустимого простоя системы, надо в них уложиться.

(82) OLAP это аналитика, для неё обычно данные переносятся в другое хранилище, да и нагрузка не такая как на OLTP, так как данные в OLAP обычно агрегируются.

И да после удаления такого объёма нужно как минимум перестраивать индексы данной таблицы + статистику для ускорения доступа ( запросы )

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

(79) Да, вы правы, эксплуатацией СУБД занимается отдельный человек, просто для себя интересно чуть глубже понимать механизмы. Главы пересказывать не надо, надо просто подтолкнуть в правильном направлении :)

(87) Если удаление по периоду, то кластерный можно так же грохнуть и потом воссоздать

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

(90) Только что делать, если таблиц - десяток. Руками с ума сойдешь индексы удалять/пересоздавать :(
А то мне предстоит скоро таблицы на сотни миллионов записей чистить.

(91) Да скрипт готовишь используя SQL Server Management Studio. Можно ещё программно из 1С скрипт подготовить, используя ПолучитьСтруктуруХраненияБазыДанных

(90) По итогу - 30 млн записей удалились за 16 минут, 28 минут на пересоздание индексов. Дальше оптимизировать смысла не вижу.

(92) Ну да, для одного индекса получить скрипт на drop/create, дальше по аналогии для всех нужных индексов делаешь, и через ADODB запускаешь итоговый скрипт.

(94)А (54) не попробовал?

(95) Пятница только завтра... или ты решил со среды начать народ подогревать?

Мне правда интересно.
Я удалял много объектов этой одной командой.

(95) Порциями по 1 млн? Оно не подохнет по памяти?

(98)Не пробовал, значит

100

А говорят индекс можно просто отключить на время, а не пересоздавать

ALTER INDEX IX_Employee_OrganizationLevel_OrganizationNode ON HumanResources.Employee
DISABLE;

или даже так
ALTER INDEX ALL ON HumanResources.Employee

https://msdn.microsoft.com/ru-ru/library/ms177456(v=sql.110).aspx

(101) Так при удалении такого количества записей всеравно надо будет скорее всего реиндексацию и дефрагментацию индексов делать, так почему бы и не пересоздать? Но попробую и такой вариант, спасибо.

(99) Тоесть ты реально удалял миллион объектов через УдалитьОбъекты?

(105) Кода меньше просто, не нужно думать какие индексы есть ибо ALL

Ну и включение индекса - это и есть Rebuild

(105) не будет операций по обновлению индекса во время удаления

(108) О! Спасибо, пригодится.

(109) Я имею в виду после удаления это сделать надо будет.

(106) УдалитьОбъекты удаляет родителькую запись  + подчинённые записи таблиц + движения делая запросы вида DELETE в базу. Скорость удаления только замедлится ( на сколько я понимаю ты удаляешь не все данные, а только чтобы почистить к примеру движения? Не понимаю настойчивость товарища с УдалитьОбъекты, но уже не смешно...

(112) + на каждый документ будет генерироваться несколько DELETE, если документов к примеру миллион то запросов будет несколько миллионов. Там только на сетевую активность между 1С и базой данных уйдёт куча времени. Чтобы получить массив ссылок нужно ещё используя отбор грузануть эти ссылки ( пусть даже и будет чтение только из индекса ). И так как индексы не отключены / удалены в том числе в подчинённых таблицах и регистрах то удаление будет в индексах возрастёт многократно.

PS: Совет тому кто такое советует бездумно. Ты лучше в пятницу давай такие советы, подумают что юморишь...