v7: Обрезание регистров. Удаление документов: что быстрей ? #604082

За четыре года надо почистить дбф - базу. Остатки готовы, теперь думаю как быстрей удалить проведенные документы.

Сколько их там примерно ?

Откатить ТА назад, до первого документа.

если пересчета итогов не будет то всеравно. иначе 2

80 тысяч

быстрее прямым запросом

Откатываем ТА в самое начало. Дальше в транзакциях удаляем порциями по 100+ документов, в зависимости от железа. Дальше восстанавливаем ТА со всеми вытекающими.

Если остатки готовы - ВВЕСТИ ДОКУМЕНТЫ ОСТАТКОВ. потом тупо прибить файлы документов и регитсров. ТИИ с правильными действиями по неразрешенным ссылкам. провести документы ввода остатков.

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

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

Гы. Присоединяюсь к Мне надо > 800 000 удалить 1. Прямым запросом update ISMARK = 1 в Журнал 2. Delete движения в регистрах 3. Delete в DT, DH Что упустил?

в журнале значится ismark, а в dt и dh delete? )

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

А он там есть? )

Замётанно

Ну периодику можно не документом. Из Wrap.ert можно взять кусок переноса периодики на дату.

делете в  в DT, DH не надо, раз ты просто помечаешь документ на удаление.. + должен занулить все флаги по регистрам + аппкоде + счетчик движений.. + прибить периодику, установленную этим документом + прибить проводки нет

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

Сначала ввод остатков, потом . Более скоростного варианта не бывает.

Что - записи в DT, DH останутся? Или ТИИ их чикнет?

?

останутся

какая детская наивность

+ флаг последовательности еще в 0

Дык чикнуть надо. Нафига они? Ещё видимо 1SBLOB прошерстить надо.

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

Что штатно делает 1С с DT, DH: 1. При пометке на удаления дока 2. При удалении помеченных ?

1.ничего 2.удаляет

разве в ДБФ удаляет?

Вопрос с DT, DH снят. Ступил малешко.

Ну физически нет. Ставит признак в служебное поле. Удаляет физически при сжатии таблиц.

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

например: режем на 31-12-2011 док отгрузка товаров был 25-12-2011 а выписка по нему 20-01-2012 и на что будет ссылаться выписка?

кстати, у меня еще есть связанные между собой доки например Акт на слив ГСМ и Приходная в пути - приходные в пути сидят в декабре, а акты приняли в феврале, и те и те сделали движения и по регистрам и по счетам - делаю на последнем дне дока приходные в пути сторнирующие доки ввода остатков по счету и по регистру. ну и оставляю все доки протоколов цен аж с сентября чтоб периодику не трогать, а в последнюю резку ваще выкинул модуль  удаления периодики - меньше мороки.

читай внимательнее - документы метятся на удаление, не удаляются

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

На док, помеченный на удаление. Ещё вопрос к гуру Скуля: 2005-й База сначала упала в Suspect. После перезагрузки оказалась In Recovery. Что делать, кроме как убить её и восстановить с бекапа?

проще действительно транзакциями по сотке доков.

Сколько времени штатно будет удалятся под лям доков:?

Да не, на его объеме застрелится ждать. Лучше как и планирует. Пометить доки прямыми запросами плюс по максимуму удалить некритические данные, а потом штатное удаление помеченных. Правда тут тоже вопрос сколько будет идти.

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

Мозг включать не пробовал?

подождать, пока восстановится.

Я на копии ждать не стал. Вопрос был на будущую соломку. Вдруг на рабочей будет тоже. Сисы не в курсах.

И так: 1. Прямым запросом update ISMARK = 1 APPCODE, ACTCNT, DS4302, RF* = 0 в  Журнал 2. Delete движения в регистрах Что сделать с 1SCONST ? DOCID = "" ?

база какая у тебя ? Тис ? Комплексная? Бухня ? Пуб ? ЗЫ:еще флаг последовательности надо занулять

Тогда уж проще создать пустую базу и занести остатки. Только историю откуда взять?

На самом деле тема обрезания возникает постоянно, с обострениями под конец и начало года. Воспользоваться поиском и найти 99% ответов на еще непоставленные глупые вопросы. Потом определится с религией - резать самому или найти денег и пусть кто-то сделает. Все. Больше ничего придумать нельзя.

ТиС обезображенная до неузнаваемости. F=DS4302    |DocStream flag      |N   |1     |0     Оно?

для периодики так будетс |delete

ага.. тока это, проще об этом не думать - писать запрос из 1с с использованием 1cpp, там есть метапарсер имён

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

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

1.формируещь ввод остатков. 1.1 попутно формируешь список документов, которые в этих остаках фигурируют 2. формируешь список документов, устанавливающих значения периодики на дату обрезки. 2.1. если есть документы рагьше даты обрезки - добавляешь их в список 1.1 3. проверяешь ссылкидокументов после даты обрезки - если есть ссылки на документыы раньше даты - добавляешь их в список 1.1 4. удаляешь движения всех документов до даты обрезки, и итоги регистров до этой даты. 5. документы раньше датыобрезки - удаляешь, если они не входят в список  1.1. если входят - снимаешь флаг проведенности, но устанавливаешь признак архивности (чтоб не провели). все это не требует ни монопольной работы, ни каких-то особых решений. вставил в шедулер, и пусть пыхтит в часы наименьшей нагрузки базы... впрочем, даже это можно распределить во времени (чтоб еще больше снизить текущую нагрузку), только мне было лениво... И так работает...