Удаление записей из таблиц 1С прямым SQL запросом #594165

гениально. Бекап сделал?

и чо?

))))))))))  Извиняюсь не дописал, случайно отправил  )), собственно текст запроса выше. У меня вопрос: при выполнении этого запроса когда период не большой, запрос как бы выполняется , но данные не меняются,т.е как было 100 регистраторов так и остаётся. когда делаю период около года, тогда запрос начинает отрабатывать нормально и всё чистит, в чём проблема может быть??

а ты рисковый...

агась, база 600 гигов  )))

drop table пиши сразу, не ошибешься

Зачем тебе 1с тут... открывай квери и вперед..

это не решает проблему, в qa результат тот же

запрос как бы выполняется, это как?

т.е Выполняется, нормально отрабатывает, в исключение не попадает, только очень быстро, такое ощущение, как будто для пустой таблицы отрабатывает, хотя за это период выборку делаю, всё ок

интересно, если это РН, то как быть с итогами?

И где там  в запросе ограничение на период? там только на дату

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

Бли, с начала года по эту дату 100 доков например, потом прибавляю к дате 6 месяцев, получается 10000 доков, вот когда 10000 начинает чистить, когда меньше фиг ( это утрированно)

я итоги отключил, а какие ещё зависимые???

ну регистры, наприемр "Списанные товары" для РТУ  и т.д.

К слову - будет сильно разбухать файл лога (при модели фул). Для сокращенияМожно делать - select во временную табличку по условию. Дропаешь старую, переименовываешь временную в старое наименование. + проверь конец периода. P.S. Имхо - лучше использовать штатные механизмы.

А чем штатная обработка не катит?

Штатными 14 дней чистилось всё, и мы забили

Зависит от очищаемой таблицы. Здесь нет контроля ссылочной целостности. Например, грхнешь счет, а наклданые оставишь - появятся битые ссылки.

мож кто нить знает как побыстрому очистить РН кроме как с отбором по регистратору?

Гм.Например чистишь таблицу документов заказ покупателя. А на основании заказа  вводидтся  реализация товаров.  (В ут типовой такое есть) То если удалить заказ, в док-те реализация будет ссылка на несуществующую запись. Собственно в этом есть минус - надо все связи проработать.

Вместо Формат(КонецПериода,"ДЛФ=DT") я бы для уверенности сделал так "CONVERT(datetime, '" + Формат(Дата, "ДФ='yyyy-MM-dd HH:mm:ss'") + "' , 120)"

да и фиг сними , перетяну из копии если что по уиду

Тебе вообще весь надо грохнуть?

так пробовал, выдаёт ошибку что то типа неподдерживаемый system type

может лучше перетянуть в пустую базу то что надо оставить?

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

ну да, или проще нав все доки грохнуть, тогда и РН потруться

А лицензию 1С нарушать кто учил?

Сделай в квари аналайзере SELECT вместо DELETE и посмотри, какие записи возвращает.

у меня так работает

Ага. И обработка удаления табличных частей у документов тоже сделана?

воткни OUTPUT DELETED.* ..увидишь записи, которые удалил.. А так, вот готовая поделка, к примеру:

Про журналы не забудь, а то весело будет.

вместо delete подставь select * и посмотри результат

Отважные вы люди как я погляжу

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

то что нужно ))

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

неее, удаляю все то что ты написал )

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

шо, никто не знает чтоль?? тогда ещё один вопрос: если я сделаю "SELECT * INTO _MyTable FROM _MyTable AS T WHERE T.PERIOD >= '01012012' Таблица перезатрётся, если такая уже есть в базе??? или будет ошибка на неуникальность имени???

вот здесь есть выкладки по массовой загрузке или удалению в SQL

заменить сами таблицы - никак, а вот залить данные из одной в другую - смотри пост выше. А если кратко, то в старой TRUNCATE, и затем INSERT INTO стараяТаблица WITH (TABLOCK) SELECT * FROM новаяТаблица

зависит от ограничений накладываемых на таблицу

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

Дропаешь старую drop table 'имя таблицы' И переименовываешь временную exec sp_rename 'старое имя', 'новое имя' Но сие работает, если временная таблицу у тебя физически таблица, а не с #

Например, отбираешь с отбором во временную без #. Дропаешь старую, переименовываешь временную.

Если _MyTable уже есть, то ругнется - 100%.

кто мешает удалять штатными методами? запускаешь 31 сеансов и в них начинаешь штатно удалять в разных периодах.... в первом сеансе все документы первого числа каждого месяца, во втором второе число... если база не кривая, никаких блокировок не будет :)

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

кстати можно 31 регламентных задания, запустить, думаю это будет самое быстрое и правильное, у регламентного задания есть параметр, это будет номером дня в месяце... надо будет попробовать :)

+ Кстати, только за счет перевода операции на сервер скорость возрастает раза в 2 (один и тот же алгоритм работы)

запускали в 10 сеансах на 64 разрядном серваке, 14 дней, окончания не дождались

ой,

С отключенным пересчетом итогов и ОбменДанными.Загрузка = истина?

да

конечно не в обиду, но все-же удивляюсь как в 24 года доверили базу в 600 гигов. лично у меня нет опыта работы с такими базами... 30 - это нормально, а тут 600 :)

))) у меня тож нет, а у них вариантов не много, пользователи кричат целыми днями на it отдел, что 1С тупит, документы 30 мин проводится. у них рарус год на аутсорсе работал, и чёт толку ни хрена, тольк косяки

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

сделай фоновое задание и пусть полгода удаляет.... а вообще что-то у тебя не правильно там, за 14 дней в 10 потоков можно черта лысого удалить, что-то у тебя СОВСЕМ не так!!! удаление идет быстрее записи, на среднем оборудовании запись ляма записей в регистр сведений идет примерно 40 минут (штатной обработкой) сколько у тебя строк в этом регистре?

связь только по шапке.

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

не путай регистр сведений и накопления

o_O есть такое слово Транзакция....

сведений чистится за 3 минуты, накопления в день 150 тысяч регистраторов где то

уже сообразил

ничем не отличается если расчет итогов отключен

в регистре 2300000 регистраторов

удаляй сначала ТЧ. если доки уже удалил, удаляй тч для которых нет шапок документов. соединяй таблицу тч с основной таблицей и по нулл грохай.

150тыс документов - это детские обьемы, максимум минут 30... обнови статистику, отключи итоги

итоги отключены

это ДЕТСКИЕ обьемы, даже 7.7 нормально тянет... интересно от куда у тебя 600 гиг???

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

т.е если в документе 1000000 строк то это вообще не важно???

и в регистре на 1 док милион записей тоже все равно?

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

в документе может быть максимум 100000 строк. это на заметку.

2 таб части, в одной контрагенты, в другой номенклатура, контрагентов 500 номенклатуры 5000, движения делаются так: на каждого контрагента выбирается вся номенклатура, итого 2500000 записей

мда.... такого я еще не видел... тому кто это сделал руки оторвать нафиг... теперь я понимаю от куда размеры базы :) переделывай все... 1. документ на 1 контрагента (в шапку) 2. нафига регистр накоплений? это класический регистр сведений... 3. индексы в порядок приводить...

ну да, документ мне тоже изначально понравился,про индексы х.з, слышал админы пытались переиндексацию запустить, она часов 20 идёт, столько времени соответственно никто не даёт

т.е год с базой точно не делалось никаких регламентов

а что за движения? надо смотреть можно ли перепроектировать, что бы не было кросс-джойна.

обнови SQL статистику, скорость возрастет раз в 200

а это как и чего?

спасибо, а насколько долгая эта процедура?

на 100 гигах минут 20, но пользователи могут работать в это время

я думал разбить на 2 регистра просто, в один контрагентов , в другой номенклатуру,ну или  как на одного контра 1 док, но меня съедят, это им 500 доков придётся делать, они же не привыкли

да не надо 500 доков делать. в движениях что пишется?

500 документов должны делатся из одной обработки

как вариант, контрагент , номенклатура

в ресурсах что хранится?

булево

типа принадлежность номенклатуры контрагенту?

запрет

И это храниться в регистре накопления?