T-SQL + 1С: как правильно удалять очень много записей
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(2) Я прошу прощения, но я не понял Вашего комментария. У Вас какой-то вопрос, который Вы решили не задавать? Или у Вас есть уточняющая публикацию информация, которой Вы решили не делиться?
По основному тексту статьи с индексами делать ничего не надо - свёртка выполняется "на бою". С таблицей работают пользователи. Фрагментация индекса неизбежна. Для этого существуют регламентные задания и прочее. Можно ещё поговорить о логах SQL Server и других сопутствующих темах ...
По поводу варианта с использованием TRUNCATE, да - там есть такая тема. Индексы на таблице save создавать вообще не нужно. На основной таблице, как вариант, можно их дропнуть и создать потом заново. Не стал об этом писать, так как основной мотив статьи - свёртка "на бою" параллельно основной работе пользователей.
По основному тексту статьи с индексами делать ничего не надо - свёртка выполняется "на бою". С таблицей работают пользователи. Фрагментация индекса неизбежна. Для этого существуют регламентные задания и прочее. Можно ещё поговорить о логах SQL Server и других сопутствующих темах ...
По поводу варианта с использованием TRUNCATE, да - там есть такая тема. Индексы на таблице save создавать вообще не нужно. На основной таблице, как вариант, можно их дропнуть и создать потом заново. Не стал об этом писать, так как основной мотив статьи - свёртка "на бою" параллельно основной работе пользователей.
(3) ээ-э.. индексы?
...индексы фрагментируются и разок другой можно их переиндексировать руками, а потом лучше воткнуть в обслуживание.
...запрос не продолжается, а всякий раз начинается с начала (но это весчь очевидная)
Вот что действительно никто не сказал, так это режим работы сервера при удаление большого объема флуда из таблицы - можно потребовать максимальный приоритет и не уступать место другим потокам (типа крут бесконечно), тогда в сос уходить не будет (хотя это вроде тоже весчь очевидная)
...индексы фрагментируются и разок другой можно их переиндексировать руками, а потом лучше воткнуть в обслуживание.
...запрос не продолжается, а всякий раз начинается с начала (но это весчь очевидная)
Вот что действительно никто не сказал, так это режим работы сервера при удаление большого объема флуда из таблицы - можно потребовать максимальный приоритет и не уступать место другим потокам (типа крут бесконечно), тогда в сос уходить не будет (хотя это вроде тоже весчь очевидная)
так же как и отбирать , так и удалять записи таблицы быстрее всего по кластерному индексу.
поэтому все рекомендации относятся для случая , когда удаление записей нужно сделать
по условию, не соответствующему кластерному индексу.
для случая массовой го удаления записей из больших таблиц и удобно создать дополнительный индекс по условию удаления. после удаления записей индекс удалить.
если удаляется меньше половины записей, то этот способ быстрее, чем способ с транкетом.
поэтому все рекомендации относятся для случая , когда удаление записей нужно сделать
по условию, не соответствующему кластерному индексу.
для случая массовой го удаления записей из больших таблиц и удобно создать дополнительный индекс по условию удаления. после удаления записей индекс удалить.
если удаляется меньше половины записей, то этот способ быстрее, чем способ с транкетом.
(5) Идея понятна. Спасибо за дополнение.
Честно говоря, мне даже в голову не пришло, что что-то можно удалять не по индексу =)
Кстати сказать, пример в публикации использует отбор по полю _Period, которое является первым полем кластерного индекса для регистров накопления. В данном случае кластерный индекс будет использован.
Честно говоря, мне даже в голову не пришло, что что-то можно удалять не по индексу =)
Кстати сказать, пример в публикации использует отбор по полю _Period, которое является первым полем кластерного индекса для регистров накопления. В данном случае кластерный индекс будет использован.
Конструкцию
INSERT [_AccumRg1234_Save]
SELECT * FROM [_AccumRg1234] WHERE [_Period] >= @Period;
можно заменить на
SELECT *
INTO [_AccumRg1234_Save]
FROM [_AccumRg1234] WHERE [_Period] >= @Period;
которая работает, как будто бы, быстрее.
INSERT [_AccumRg1234_Save]
SELECT * FROM [_AccumRg1234] WHERE [_Period] >= @Period;
можно заменить на
SELECT *
INTO [_AccumRg1234_Save]
FROM [_AccumRg1234] WHERE [_Period] >= @Period;
которая работает, как будто бы, быстрее.
(9) Извините, но Вы написали: "которая работает, как будто бы, быстрее". Это выглядит как неуверенность в своих словах.
Эта ссылка и объяснения показались мне более понятными и обстоятельными: . Можно сказать, что Вы правы ... частично, так как таблица [_AccumRg1234_Save] в моём примере не является временной. Если использовать временную таблицу, как Вы предлагаете, то нужно весь код удаления в обязательном порядке заключить в одну транзакцию между BEGIN TRANSACTION и COMMIT TRANSACTION. В примере этого нет, и это не просто так. Если выполнение программы вдруг "упадёт" после TRUNCATE, то в моём примере данные останутся в таблице [_AccumRg1234_Save] и не будут потеряны.
Эта ссылка и объяснения показались мне более понятными и обстоятельными: . Можно сказать, что Вы правы ... частично, так как таблица [_AccumRg1234_Save] в моём примере не является временной. Если использовать временную таблицу, как Вы предлагаете, то нужно весь код удаления в обязательном порядке заключить в одну транзакцию между BEGIN TRANSACTION и COMMIT TRANSACTION. В примере этого нет, и это не просто так. Если выполнение программы вдруг "упадёт" после TRUNCATE, то в моём примере данные останутся в таблице [_AccumRg1234_Save] и не будут потеряны.
(13) Удаляем 5000 записей.
1. итерация: удалили 4000, осталась 1000.
2. итерация: удалили 1000, осталось 0.
3. итерация: @RowsAffected = 1000, удаляем 0 записей ...
Вы правы ...
Однако, а что если, пока мы удаляем записи, другая транзакция их туда добавляет ?
При определённых условиях этот цикл может быть вечным ... =)
1. итерация: удалили 4000, осталась 1000.
2. итерация: удалили 1000, осталось 0.
3. итерация: @RowsAffected = 1000, удаляем 0 записей ...
Вы правы ...
Однако, а что если, пока мы удаляем записи, другая транзакция их туда добавляет ?
При определённых условиях этот цикл может быть вечным ... =)
(15) Чтобы расставить все точки над i:
при WHILE @RowsAffected = @RowsToDelete цикл не будет вечным и после его выполнения в базе могут остаться записи, которые подходят под условие удаления.
Мой пример был взят из боевой базы. Первая версия была вообще такая: WHILE EXISTS(SEL ECT 1 FR OM ... отсюда и такая логика.
при WHILE @RowsAffected = @RowsToDelete цикл не будет вечным и после его выполнения в базе могут остаться записи, которые подходят под условие удаления.
Мой пример был взят из боевой базы. Первая версия была вообще такая: WHILE EXISTS(SEL ECT 1 FR OM ... отсюда и такая логика.
А такое можно провернуть если таблица ( неподчиненный регистр) учавствует в РИБе?
После truncate получится, что в соответсвующей таблице изменения (_ChnRg которая) будут записи на не существующие записи основной таблицы?
После truncate получится, что в соответсвующей таблице изменения (_ChnRg которая) будут записи на не существующие записи основной таблицы?
Да, собственно, имеется РИБ (порядка 30 баз) на 8.2. Одна таблица отключается из состава обмена, есть мысль её удалить на sql напрямую. Вопрос - обязательно таблицу изменений еще и чистить, её ведь платформа удалить и так должна. И еще вопрос - если удалить основные записи, а изменения нет, при функционирующих обменах с ней (еще), в таблицах изменения останутся ссылки на несуществующие строки видимо.(?) Как это отразится на обменах?
(20) Добрый день, Сергей!
В Вашем случае все операции типовые - ничего удалять в SQL напрямую не нужно.
Таблица изменений объекта будет удалена автоматически платформой 1С в том случае, когда объект будет исключён из состава всех планов обмена, в которые он входит.
При удалении объектов, они регистрируются в таблице обмена и выгружаются как тип данных УдалениеОбъекта - по сути это контейнер для хранения ссылки или ключа записи удалённого объекта.
В Вашем случае все операции типовые - ничего удалять в SQL напрямую не нужно.
Таблица изменений объекта будет удалена автоматически платформой 1С в том случае, когда объект будет исключён из состава всех планов обмена, в которые он входит.
При удалении объектов, они регистрируются в таблице обмена и выгружаются как тип данных УдалениеОбъекта - по сути это контейнер для хранения ссылки или ключа записи удалённого объекта.
(21) Дмитрий, подскажите, пожалуйста, что за это за зверь "контейнер" (УдалениеОбъекта) и для чего он служит (имеется ввиду в обменах типовых конфигураций)?
Вот удалил я объект в источнике, далее он регистрируется в таблице изменений как "Объект удалён <УИД>". Что должно произойти после совершения обмена? Удаляться соответствия на эту ссылку в базе приёмнике?
Вот удалил я объект в источнике, далее он регистрируется в таблице изменений как "Объект удалён <УИД>". Что должно произойти после совершения обмена? Удаляться соответствия на эту ссылку в базе приёмнике?
(23) УдалениеОбъекта (встроенная справка 1С):
Предназначен для удаления объекта базы данных. Объект хранит ссылку на объект базы данных и при обращении к методу Записать() производит удаление объекта базы данных, на который показывает ссылка. Кроме того, данный объект имеет свойство ОбменДанными, которое содержит параметры обмена данными, используемые при удалении объекта, на который показывает ссылка. Основное назначение данного объекта - переносить удаление объектов базы данных при использовании в составе других механизмов обмена данными.
(28) Дело происходит так:
1. В источнике удалили объект.
2. В источнике в таблице регистрации изменений зарегистрировалась ссылка на удалённый объект.
3. При выгрузке из источника платформа видит, что ссылка в таблице регистрации изменений "битая" - объект-то удалили. Такую ссылку она выгружает, "завернув" её в УдалениеОбъекта.
4. Приёмник принимает УдалениеОбъекта и знает, что внутри ссылка, которая была удалена в источнике.
Вот для такого сценария в основном и нужен тип "УдалениеОбъекта".
1. В источнике удалили объект.
2. В источнике в таблице регистрации изменений зарегистрировалась ссылка на удалённый объект.
3. При выгрузке из источника платформа видит, что ссылка в таблице регистрации изменений "битая" - объект-то удалили. Такую ссылку она выгружает, "завернув" её в УдалениеОбъекта.
4. Приёмник принимает УдалениеОбъекта и знает, что внутри ссылка, которая была удалена в источнике.
Вот для такого сценария в основном и нужен тип "УдалениеОбъекта".
Немного не так. Сама таблица чистится (большая её часть, но не вся) чтобы её реструктуризация быстро прошла в последующем обновлении (в неё добавляется колонка и она исключается из обмена). Сама таблица в РИБе, функционирует обмен данными. Скорее всего, будет сделан способ c truncate через вспомогательную таблицу (). Вопрос - обмены не остановятся, битых ссылок не понаделается? Нужно ли еще удалять записи в другой таблице (пока она еще есть в базе)? Вот это непонятно мне...
Нет, вопрос не в реструктуризации.Еще раз процитирую мой вопрос: "...обмены не остановятся, битых ссылок не понаделается? Нужно ли еще удалять записи в другой таблице (пока она еще есть в базе)?" Под "другой" таблицей имеется ввиду таблица изменений.
(26) Задача не понятна. Удаляем записи ради чего ? Свёртка ?
Я понял так: Вы исключаете объект из состава плана обмена, который является единственным, в котором этот объект участвует. В таком случае платформа сама всё за Вас сделает: удалит регистрацию изменений для этого объекта. Затем возник вопрос добавления нового реквизита и реструктуризации. По этому поводу я дал ссылки.
Если всё-таки есть желание поработать на уровне SQL, то отвечаю на вопросы:
Обмены не остановятся ?
Непонятна суть вопроса. Если вопрос про блокировки и прочее, то зависит от уровня изоляции и гранулярности налагаемых блокировок. Для меня термин "обмены остановились" слишком широк. Нужна конкретика.
Битых ссылок не понаделается ?
Если не выполнять контроля ссылочной целостности, то конечно же понаделается.
Нужно ли удалять записи в таблице изменений ?
Ну конечно же нужно. Это тоже касается контроля ссылочной целостности базы.
Я понял так: Вы исключаете объект из состава плана обмена, который является единственным, в котором этот объект участвует. В таком случае платформа сама всё за Вас сделает: удалит регистрацию изменений для этого объекта. Затем возник вопрос добавления нового реквизита и реструктуризации. По этому поводу я дал ссылки.
Если всё-таки есть желание поработать на уровне SQL, то отвечаю на вопросы:
Обмены не остановятся ?
Непонятна суть вопроса. Если вопрос про блокировки и прочее, то зависит от уровня изоляции и гранулярности налагаемых блокировок. Для меня термин "обмены остановились" слишком широк. Нужна конкретика.
Битых ссылок не понаделается ?
Если не выполнять контроля ссылочной целостности, то конечно же понаделается.
Нужно ли удалять записи в таблице изменений ?
Ну конечно же нужно. Это тоже касается контроля ссылочной целостности базы.
Спасибо за ответы.
Задам еще один: Что будет, если в базе удалить "напрямую" данные из независимого регистра сведений (без регистратора, не имеющего внешних ссылок),и на момент удаления эта таблица имеет "зарегистрированные изменения" в плане обмена. То есть, генерации типа "Удаление объекта" не будет. Как себя поведет 1С при загрузке,выгрузке данных? Что в таком случае придет в "приемник"?
Задам еще один: Что будет, если в базе удалить "напрямую" данные из независимого регистра сведений (без регистратора, не имеющего внешних ссылок),и на момент удаления эта таблица имеет "зарегистрированные изменения" в плане обмена. То есть, генерации типа "Удаление объекта" не будет. Как себя поведет 1С при загрузке,выгрузке данных? Что в таком случае придет в "приемник"?
(30) В таком случае регистрация изменений останется. Источник выгрузит в целевую базу объекты типа УдалениеОбъекта. Приёмник примет их и удалит у себя. Дело в том, что УдалениеОбъекта генерируется при выгрузке. Логика примерно такая: у меня есть изменение, ищу объект по этому изменению в основной таблице, объекта нет - выгружаю УдалениеОбъекта.
Вопросы с вознаграждением
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|