Доброго времени суток. Готовлюсь к удалению не нужной номенклатуры, тестю разные варианты ;)

Код простой. запросом выбираю номенклатуру.
Далее тестирую удаление ее, с транзакцией и без.

Может я делаю что то не так но разницу я не увидел..
В общем запросом выбрал первые 200. ради теста.

Первый раз удалил эти 200 с транзакцией . Второй раз удалил эти 200 без нее. просто подряд.

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

Во втором запуске разницы вообще не было.. милисекунды какие-то.

Или на такой мелочи как 200 элементов справочника, он ни чего и не покажет?

(99) правильно товары на складах. Только нужно проверить не остатки а были ли движения.  Так это мне сюквелом ещё надо проверить доки была ли эта номенклатура ). Так я совсем запутаюсь

(97) монопольный попробую. Уже убежал с работы. Но помню про него.

(102) в чем запутаешься ? в запросе к одной табличке регистра ?

А можно еще тупее, удалить по min(_idref)

Точнее, минимум оставить, а удалить максимум с ссылки

(104) Если говорить о номенклатуре, то там полно регистров. Это и цены номенклатуры, и Аналитики различные, штрихкоды, сегменты и т.д.

(100) Да еп..
Проверяй в 1С. Удаляй в скуле.

(108) можно из 1с выплюнуть тот же csv файл с кодами товаров для удаления. А потом уже его прочитать во временную таблицу, ее к номенклатуре прикрутить и грохнуть данные.

Самый идеальный вариант, это пометить на удаление именно те позиции, которые 100% будут удалены и ссылок не имеют. Тогда простой запрос с отбором на пометку удаления

(109) Это было сказано еще в (9)
Тут, видимо, проблема гораздо глубже)

Да даже временная таблица не нужна. Я прям строки через запятую передаю в подобных случаях)

(111) пробовали так для 1кк позиций и более?

(110) так блин. В том то и проблема. Что бы пометить на удаление такое же количество номенклатуры. Это столько же времени. Пометка на удаление.  
Записать.

Делается не быстреее.
Чем удалить ()

все не читал, но судя по названию темы, вы все таки смогли успешно перенести 4.5 млн позиций в базу из прошлой темы про ускорение загрузки?)

(112) Разбить на десять запросов?
Ну короче, это уже дело техники.

Я не знаю, как из csv во временную табличку в скуле загрузить. Как?

(115) с помощью OPENROWSET попробовать https://docs.microsoft.com/ru-ru/sql/t-sql/functions/openrowset-transact-sql?view=sql-server-ver15

(115) ТСКЛем наверно
а вобще если есть возможность сделать нужный отбор на скл, то это и использовать

(116) Спасибо. Надеюсь, не пригодится :)
Да, конечно, если файл большой, то лучше читать его инструментами, которые предназначены для этого.

(114) да загрузилось норм. Теперь все в нужных папках и категориях.)

А в скуле в таблицах есть поле какое то по которому можно понять что данная позиция создана позже чем другая. И следовательно ее нужно удалить

(120) по коду можно ориентироваться, в крайнем случае по гуиду

(120) есть _Version например или ссылка Ref, но они шестнадцатиричные, сравнивать на больше меньше думаю можно, муторно правда

(122) кому муторно?

хотя..

(121) код. Не число. А строка. Это что бы автоматом сравнивать коды на больше меньше. Надо их сделать числом. А там буковки в начале есть. Надо удалять. Это ещё плюс к мароке и времени

(125) с каких пор нельзя сравнивать строки?

Ладно завтра в тестовой базе попробую через скуль что нибудь сделать. Будем на связи ) всем спасибо

(125) ну ссылку можно взять, стремно показалось, что они увеличиваются всквозную по базе, а не отдельному справочнику, _Version вроде по справочнику

(126) н де, да сравнивать то можно, только результат какой будет?

(126) сравнивать строки с буквами на больше меньше ?)

(130) да! это же один С, она все может **мнение буха

(131) это да. Не напоминай. Это точно так же. Ну ты же программист выбери мне пылесос

(120) Нет. Все те же поля, что и в предприятии +/-

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

(8) Я проверял - быстрее.

если ссылок нет грохай в скуле и все.

(130) ты реально не знаешь как выполняется сравнение строк или прикалываешься?)

(4) "С чего вдруг запись в транзакции должна быть быстрее?"
С того, что вместо Создаем Запись - Пишем на Диск - Создаем Запись - Пишем на Диск - Создаем Запись - Пишем на Диск - ...
Переходим к Создаем Запись - Создаем Запись - Создаем Запись - Создаем Запись - Создаем Запись - Создаем Запись - Пишем большой блок на Диск - ...

Тестирую удаление на 100к позиций из папки ном в иерархии.. не суть.
запросом, выбрал нужную ном из нужных папок.
получил 102к количества.
Далее со всеми возможными штуками  обменданными.загрузка истина и транзакцией по 2к штук (ради теста). поставил удаление.

поставил ушел курить... прихожу через минут 5-10. удалилась давольно быстро. Открываю справочник, эту папку во втором окне смотрю и да пусто... открываю первое окно с обработкой удаление.. а оно еще висит. подумал что за бред. папка пустая а обработка все висит.
Открываю журнал регистрации. и вижу строчки Данные.Удаление и следователньо позиция номенклатуры.. то есть грубо говоря еще удаляет.
То есть получается транзакция у меня по 2к строк. в номенклатуре в папке уже "0" то есть я их уже не вижу.
Но обработка работает и до сих пор в журнал записывается удаление.
Причем транзакция по "пакетам" работает я ее тестил то есть фиксирует по количеству указанному

Если он не удалил еще всю номенклатуру, почему тогда в папке ее уже нет? ни глазами, "ни запросом"
Если порция транзакции 2к, то почему до сих пор в журнал регистрации пишется удаление и обработка все еще работает.

(140) А фиг знает, что и откуда там ТВОЯ программа удаляет. Может пытается удалить то, что уже удалено, падает с ошибкой, а ты в обработке исключений заставляешь ее выполнить эту операцию еще раз.

Так ладно с удалением понятно удаляет более менее норм 100к позиций минут за 15.. приемлемо...

А как оптимизировать теперь проверку на движения...
Есть запрос, который отбирает дубли по артиклу. и выводит. список дублей
всего их 2кк, это и правильная позиция и дубль.
Дубли надо удалять только из определенного родителя. следовательно остается 1кк дублей истенных.
Ноооо по этим 1кк реальных дублей, могут быть движения (поступление товаров как минимум). следовательно такие удалять не стоит)) ибо объект не найден нам не нужен.
Следовательно 1кк дублей, нужно проверить как минимум по регистру ТоварыНаСкладах

Как продуктивнее это сделать? там же в запросе или при удалении каждую позицию проверять по регистру накопления?

поиск ссылок работает почти с одинаковой скоростью для 1 элемента и для 10к элементов.

(143) ну то есть я запросом отбираю дубли которые считаю надо грохать. остается 1кк
и далее при удалении ищу на каждый дубль ссылку? если нет то грохю

(138) скуль работает не так
Гугли про журнал транзакций и чекпойнт

я не знаю как отработает поиск ссылок если ему передать массив 1кк элементов. может повиснет насмерть.
при таких объемах лучше самому искать наверное.

(146) Как ты предлагаешь мне обработать 1кк номенклатуры на поиск ссылок руками ?)

может эти 1кк номенклатуры програть в РН товары на складах (за определенный период). типо если нет значит удаляепм если есть ну значит есть

(147) а что, на другие регистры пофиг?) Если это УТ11, то я бы ключи аналитики смотрел в первую очередь и иже с ними.

(147) самому имеется в виду не использовать ПоискСсылок() от 1с
а писать свои обработки которые будут как то частями проверять и лопатить не по всей базе а только там где ссылки могут быть.

(148) так у нас там ни чего нет если не было ни каких поступлений на склад. значит нет ни картинки, ни установки цен, ни каких то файлов, ни чего.

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

(151) я так и не понял как в скуле проверять на движение допустим товаров на складах
отобрать в скуле дубли по артиклу это одно. а проверить их потом по РН это уже другое)

(152) делал поиск неиспользуемых 1 запросом.
работает быстрее чем найти по ссылкам
https://drive.google.com/file/d/1CBzki0Hqn2GyxgyXvf7IxmEcf38XYGyA/view?usp=sharing

(153) благодарю


Кстати интересно а как "количество" порций в транзакции влияет на время??
на малых количествах 10-100-1000... ни как не влияет..
то есть если записей 1000
то хоть разбй их по 10 хоть по 100. хоть сразу в одну транзакцию.. время не меняется (ну может мили секунды).

А если речь идет о 1кк (протестировать на 1кк нет возможности).
если 1кк разбивать допустим по 10к порций или по 30к порций.. будет ли какая-то разница?)

(153) Забыл про общие реквизиты, системные поля, системные табличные части, регистры расчета и бухгалтерии. Отчасти поэтому оно и работает быстрее универсального поиска.

(145) А х.з., вот тут транзакции ускорили запись на 25% https://курсы-по-1с.рф/news/2017-03-27-four-methods-of-write-acceleration/#recording-in-transaction-not-used

Вопрос...
Если началась транзакци... потом закрылась 1с.. не дойдя до завершитьтранзакцию или отменитьтранзакцию
То она потом сама вернет все в зад или надо что то делать?

(157) вернет все в зад, так как данные не записались в таблицу.

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

(159) А если сервер ребутнулся еще в этот момент, то все равно вернет или уже нет?

я сделал пакет по 50к..
запустил... пошла транзакция... до 50к она не дошла поэтому фиксации не было.
сначала закрылась 1с... че то там админ химичет с сервером...
я открыл заного. запустил обработку... Но выскачила ошибка.. транзакции не помню дословно но что то из серии не возможно начать транзакцию или блокировка не помню.. видимо потому что та еще шла.
А потом сервер вообще ребутнулся

(160) вот вы правите документ, указывает организацию и контрагента и в этот момент у вас вырубается комп. Вопрос, документ будет записан в базу? Вот тут так же

(152) ну как маленький, на вот, удаляй сколько влезет:

delete from _Reference12345 --подставишь свой справочник
where _IDRRef in (
select max(_Reference12345._IDRRef) from _Reference12345
where Fld12345<>''
group by _Description,Fld12345 --подставишь своё поле с артикулом
where Fld12345<>''
having COUNT (_IDRRef)>1)

в group by еще и ,_Folder воткнуть, мало ли, ты там налепил групп с одинаковым наименованием и артикулом

(113) может просто пометить скл все дубли на удаление. потом средствами 1с удалить что удалиться и скл снять пометки на удаление.
Мололи может товар только набрали. заказывают. пришел на склад и т.п.

И вопрос а точно нужно искать дубли артиклей и наименований или можно все товары пометить отменить пометку для созданных за последние несколько дней и средствами 1с грохнуть все что негде не используется. Точно нужно реле которое хотели заказать но так никогда и не заказывали и не продавали даже если у него нет дубля.

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

в общем я уже поставил на удаление 1кк номенклатуры. посмотрим вроде 200к уже удалилось. думаю за сегодня пройдет)

Нормельное идет... когда писал 169 соощение было 1.020 миллиона.
Сейчас уже 920 тысяч. ;)

(4) > С чего вдруг запись в транзакции должна быть быстрее?
Платформа на commit'е выполняет некоторые действия.
Если писать X объектов каждый в своей транзакции - эти действия будут выполнены X раз, а если в одной - один.

(171) а подробней? что за действия?

(0) в файловой базе в транзакции сильно быстрее операции выполняются. ибо только в ОЗУ
в серверной - транзакция не влияет на скорость

(173) у нас серверная.
Не влияет на скорость, но хотя бы не уменьшает ее ?)

(174) чутка уменьшает ибо блокировочки то держатся до конца трпнзакции

(175) (173)  Получается сколько людей столько и мнений... так как в двух темах есть люди которые "за" транзакции...
но на сколько я понял они аппилируют во сновном... темой... из серии записи на диск..
можно 10к файлов, записывать на диск 10к раз
А можно эти 10к файлов, типо объеденить в 1 большой и записать 1 раз.
И в случаи с виндой это быстрее...
Банально если разархивировать 10к маленьких файлов или 1 файл такого же объема как 10к маленьких... то 1 файл разахивируется быстрее )) я образно . хотя объем у них одинаковый

Ладно вернемся к нашим баранам...
Собственно тесты продолжаются ;) сейчас запрос готов.
я там учел все что мне надо. и конкретные папки, и заполненные артикулы ну и прочие штуки которые нужны...

Конечный результат запроса
//тут еще запрос, но он не важен отбираю дубли.
|ВЫБРАТЬ
                 |    Дубли.Артикул КАК Артикул,
                 |    Дубли.Ссылка КАК Ссылка
                 |ИЗ
                 |    Дубли КАК Дубли";

Следовательно получаю список дублей(ссылок номенклатуры) которые реально дубли.

Осталось эти позиции проверить по РН ТоварыНаСкладахОбороты, то есть если эта номенклатура фигурировала там то следовательно пропускаем ее.

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

(176) тесты все решат. Но никто их не делает

(176) мс скуль - это вообще как  ос внутри ос. Там и управление памятью свое и диском

Конечно с проверкой номенклатуры по РН товаров, в разы дольше работает.... видимо если проверку по РН сделать в запросе в том же где дубли бдует быстрее

(180) ну так и сделай в конце
где НЕ ссылка в (выбрать из регистра)

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

Короче

из 1.122к позиций

1120096

1120439

в регистра меньше 300 штук.

Запрос на проверку с регистром и без. отраатывает практически одинаковое количество времени разница вообще не значительная ;)

я так понимаю если в первом варианте количества позиций меньше ) значит проверку по регистру в запросе я сделал верно)))

Я так добавил

ГДЕ НЕ Дубли.Ссылка в (ВЫБРАТЬ
                 |    ТоварыНаСкладахОбороты.Номенклатура КАК Номенклатура
                 |ИЗ
                 |    РегистрНакопления.ТоварыНаСкладах.Обороты(&Период1, &Период2, Авто, ) КАК ТоварыНаСкладахОбороты)

Реально думаешь что кто то набил миллион левых записей и потом из них юзал только 300. Есть смысл так сайт перегружать.

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

(185) Ни кто не набивал позиции. Номенклатура сливалась из двух других баз + прайсы поставщиков.
Ранее и я так понимаю не очень "удачно"..
Из 5 миллионов номенклатуры, по артикулам+ наименованию получился 1 миллион дублей.

А эти 300 позиций которые "УЖЕ" используются... в полне реально. Так как в было всего штук 20 поступлений и штук 10 реализаций. Организация новая

(186) Смысл в том что это все импорт и сроки доставки не 1 день ессесно и не 2-а. и на складе в 90% случаев товара нет. 50% юр лица 50% физ лица..
для физ лиц и сделали сайт. выкладывать туда только 300 товаров со склада нет смысла, потому что товар специфичный и кому надо готов ждать и неделю и две и три. так как цена дешевле чем на сайтах у кого есть в наличии грубо говоря.
Следовательно хотят сделать норм номенклатуру и вывалить на сайт для возможности оформлять заказ.. поэтому и такая ситуация как то так

(188) Тогда я бы вам рекомендовал смотреть ссылки не только в Товародвижении, а еще и в Заказах, а то покупатель Заказ сделает, товар еще не приедет, а вы ссылку на товар уже грохнули. Потом тяжко будет вспоминать, что и кому должны привезти.

(189) так заказов с сайта еще нет. сайт оффлайн

сейчас только поступление реализация и заказы. введеные руками в базе от юр лиц.
в общем сложности документов 100 наверное вместе. при этом все заказы закрыты ;)

а так то понятна логика ваша

Ну а установку цен я и не проверял. там реализована загрузку и из экселя и как угодно там ни кто руками не заполняет. если будут объекты не найдены. загрузят еще раз. на эти 300 позиций)

на сайте все равно 0 товара в данный момент и сайт офф

А таки удаление через свой код быстрее чем стандартное Удаление из программы?

(195) что за "Удаление из программы"

(196) Стандартная функция из Обслуживания - Удаление помеченных объектов.

(197) так она же все ссылки ищет.
Оно никак не может быстрее 1 запроса работать. Ибо все найденные сслыки со скуля возвращаются

(0) если бы семерка былабы там действительно быстрее в  транзакции

200!

(197)
Запрос на дубли (с отборами нружных папок в иерархии) со сравнением артикла и наименование
далее с проверкой на вхождение их в РН товары на складах
Все это в одном запросе
Далее результат.выгрузить
И далее в транзакции пакетами по 50к штук

Удалил 1.120.000 позиций, за пол дня.
Не так уж и плохо. "без Монопольного режима, но в базе был 1 человек который делал отгрузочные новые доки для контрагентов"

А стандартная функция удаление помеченны объектов это в любом случаи дольше.
Так как сначала нужно будет провести все те же манипуляции выше, только вместо удалить().. будет пометканаудаление.истина , записать().
то есть нужно будет 1кк номенклатуры прогнать, пометить и записать
А потом еще запустить стандартное удаление. которое будет проверять на ссылки (даже если их по факту нет) и далее еще удалять )