v8: Текст запроса SQL: быстрое удаление объектов #455245

Потребовалась быстрая удалялка объектов (объектов может удалятся более 10^7). Объекты: справочники, документы. Естественно в более - менее адекватное время эта задача решается если удалять средствами SQL. Пока задачу решал тупо выполнением через АДО текста SQL-запроса типа  "DELETE FROM .. WHERE _IDRRef IN (<список гуидов>) " уперся в ограничение что список определяемый конструкцией (v1,v2.....) по размерности не должен превышать 30000. Ну и собственно такая конструкция работает достаточно долго. Хочется поместить все гуиды во временную таблицу, а затем грохать (поскольку чистить нужно не одну таблицу, а таблицу изменений, таблицы табличных частей и т.д.). Собственно для большей части можно свести задачу к тому, что список удаляемых объектов можно определить результатом 1с-кого запроса. Идея писать конвектор 1с-кого в sql запрос меня не очень прельщает. (определение имен полей и передача параметров в списке - много кода) Есть две идее: 1. 1С -ким запросом получить ссылки поместить в запросе во временную таблицу. Обратится SQL- запросом к сгенерированной временной таблице 2. Создать 1с-кий запрос. определить как он транслируется в SQL. заменить SELECT на DELETE :) Собственно вопросы: как бы определить в какой запрос конвертнулся 1с-кий (программно) как определить имя созданной 1с-ким запросом временной таблицы.

MS SQL PROFILER

как определить имя созданной 1с-ким запросом временной таблицы. - если скуль 2005ый, то заипешься с этим. хотя нарабки есть)))

некоторые 1С-овские запросы реализуется несколькими SQL-запросами

простой селект напрямую транслируется.

ну самый простой да, но уже с использованием иерархии нет

НЕВЗЛЕТИТ

Не туда

Для примера: INSERT INTO #tt1 (_Q_000_F_000RRef) SELECT _Document45_Q_000_T_001._IDRRef AS _Q_000_F_000RRef FROM _Document45 _Document45_Q_000_T_001 WITH(NOLOCK)

#tt1 а не ##tt1

truncate table

Автор погугли - Enterprise Integrator тамма даже видео трассировки есть из 1с.

непонял??

Даже если узнаешь имя ВТ (из профайлера) - ничего с ней не сделаешь (хм.., может ADO только подцепить), так как 1С оперирует локальными ВТ, а не глобальными

Нет, коннект ADO будет считаться уже другим сеансом скорее всего

ну дык надо из под одного сеанса узнавать.

Точно другим.

Короче говорю что заипется, но выход найти можно ;))

запуск удаления может производится не обязательно на сервере БД. Потребуется профайлер ставит на клиента, права altertrace и т.д. хочется через адо. скуль - да 5-й. какие наработки? Думал над этим но думаю всегда можно сделать последний запрос - простеньким) ... не понял:) откуда такая уверенность:)

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

смотрел - автор пароль наложил:) - уважаю чужой труд - взламывать не буду

да кстати... пипец

Нука, подробнее

а ты её глобальной сделай что мешает?))

Тупо: 1) Создать справочник, туда залить в 1С ке все удаляемые ссылки В SQL- фильтр при удалении по этому справочнику. Потом его DROPнуть

Читай условие задачи

см

см

кстати интересный вариант!

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

тое есть генерить его часа 3 буду

+ не хочется типовую менять)

ну а если свою таблицу запросом сделать?

Кстати с регистром сведений может получится - он шустрее пишется и удаляется даже средствами 1с быстро. как?

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

я в sql не бум-бум

Как ты отделяешь "агнцев от козлищь" ?

Сидите уж. Я сам открою...

ну если восмерочный язык запросов знаешь то раберешься))

вопрос и был в том как получить транслированный запрос:)

MS SQL PROFILER

Шутник...

это не разово нужно сделать. процедурка должна быть. Вместо метода УдалитьОбъекты будет вывзываться

Кстати профайлер можно настроить на запись трассировки во временный текстовый файл, а 1с-ком запросе написать уникальный ключ. Время от времени парсишь файл профайлера, берешь запрос и вперед.))

Интересно вот, а 1С овцы используют локальные ВТ вместо глобальных чтобы не заморачиваться с коллизиями при многопользовательских подключениях? Так ведь сеанс Сервера Приложений - один. Не пойму...

Почему? СКЛ - очень простой язык.)) См в карточке достижения.))

Писать аналог УдалитьОбъекты да еще с контролем ссылочной целостности на SQL - нереально! Поэтому - в 1С ->РегСведений-> из него уже удаляем...

А почему локальные переменные лучше глобальных?

Я лучше на фотографию посмотрю :)

Сразу писали бы все нужные переменные в глобальнике и не парились бы))

Конфигурация то одна))

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

Вот и я непонимаю. Давай у спросим?

Он щас скажет: Потому что восьмерка фуфло!

Чего именно спросим? :) Ты знал!!!

З.Ы. А РС лучше чем справочник - так как 1) Нет 3-х индексов по умолчанию присутствующих у справочника 2) Нет контроля уникальности кода 3) Нет генерации ГУИДа

Вообщем вопрос из разряда: Почему нельзя писать SELECT * FROM... в рабочих базах.

Почему 1С использует локальные а не глобальные ВТ?

Непонятно?

Поясни

а приколись 2 8ные базы на одном сервере. и обе создали временные таблицы и...

Для того что бы не парится с уникальностью имен таблиц.

Блиииин, вот я дятелъ. Слона не заметил. :-)

Вот хоть тресни - не помню, как 1С временные таблицы обзывает - GUID или нет?

я так понимаю сейчас больше всего людей интересует почему локальные, а неглобальные. Я воспринимаю такое положение как данность:). Задачу мне нужно решить в таких ограничениях, а решать ее в предположениях вот если бы были глобальными - не носит прикладной характер

Вообще, если допустим число удаляемых записей из таблицы намного больше оставляемых, то проще выполнить truncate + insert оставляемых. При операции DELETE лучше использовать INNER JOIN -  тогда не надо заморачиваться с ограничениями IN

просто #tt1, #tt2 и тд

Имя+номер сеанса

нет удаляем порядка ^6-^7 остается еще порядка ^7

Поместите интрересующие вас ссылки в физическую таблицу. И потом delete from ОткудаУдаляем where Поле IN (select Поле from ВашаТаблица).

Случаем не надо удалить все помеченные на удаление, без контроля ссылочной целостности?

Это так, для инфо.

, Жэсть...

Включи технологический журнал и посмотри.

Как это соотносится с #tt1, #tt2 ?

+ delete не быстр. Т.к. пишется инфа еще в лог транзакций. А у Truncate нет условия. Без транзакций но всю таблицу целиком. Так штааааа.

Смотря о каких в/т идет речь, я про те, которые сама платформа генерит

Я про МенеджерВТ

нужно же еще поместить в физ таблицу - это тоже потеря времени. сейчас 1000000 элементов конструкцией DELETE FROM WHERE _IDRref in (v1,v2...) удаляются приблизительно 20 минут. Нужно бы сократить раз в 5 - 10

У вас не будт ограничений как в конструкции  IN ('','','','','',''..........)

Как увидеть реальное имя временной таблицы: where id = (select  object_id('tempdb..#tt1'))

Спасибо..., но как еще 1с-ку заставить выполнить такой код - поскольку нужно то именно из ее сеанса, а не АДО:)

Спасибо

Все сделано до Вас:

...открыл смотрю. - вроде сам транслируешь в сиквел. Я побоялся с этим связываться:)

и почему-то условие по списку значений не работает.

сделано на основе SQLPlus там есть свои ограничения

убить все индексы кроме кластерного и удалять. "Собственно для большей части можно свести задачу к тому, что список удаляемых объектов можно определить результатом 1с-кого запроса." нафига тогда во временную таблицу помещать? пищите сразу delete с запросом. если скуль 2005, то там можно delete top 10000 from bla-bla-bla

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

преобразовать к виду delete from ОткудаУдаляем inner join (select Поле from ВашаТаблица) on IN поле = поле.

посмотрел транслятор. Не работает когда разыменовываешь более чем на одно поле. Например: Запрос: ВЫБРАТЬ    Номенклатура.Ссылка ИЗ    Справочник.Номенклатура КАК Номенклатура Транслируется в: Select     Nomenklatura._IDRRef From     _Reference30 As Nomenklatura А так удаление 1000000 заняло 5 минут. - приемлимый результат.

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

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

проблема в том что временной таблицы нет. ее нужно генерировать запросами - а как менее накладно ее сгенерировать это для меня БОЛЬШОЙ вопрос. мне нужен не разовый запрос... а процедурка УдалитьМногоОбъектов заменитель метода УдалитьОбъекты.

1. менее накладно ее не генерировать. а удалять порциями. 2. разово ты узнаешь откуда все удаляется. а потом уже этот запрос тянуть в продолжение.

ну вот не совсем так. В обработке насколько я понял получается временная таблица и потом данные херятся по конструкцией delete from ... where _iddref in (select _iddref from #table1) результат 3-5 минут если херить порционно: 333 раз по delete from ... where _iddref in (v1,...v30000) то 20 минут. (больше 30000 размер списка сделать нельзя - оптимизатор просит упростить запрос)

а IN использовать нельзя. потому как индексы не используются. нужно как в

Смотрю план запроса вроде впорядке все Cluster Index Seek выполняется ровно 1 раз на 30000 порцию.

delete top 3000 from ОткудаУдаляем t1 inner join (select _iddref from #table1) t2 on IN t1._iddref = t2._iddref только на таблицу #table1 навесить индекс по полю _iddref

а как его съедает оптимизатор? вызов на каждую строку @p1 or @p2 or @p3 и т.д. 30000 раз, и вызов на каждую строку.