Почистить скульную базу #382278

С праздником, уважаемые! Прошу подсказать, всё ли я сделал правильно. Имеется большая нетленка на скуле (~12 гБ). Возникла необходимость урезать ее. Решили удалить все документы до 2008 г. Удаление документов за 3 года штатными средствами оказалось делом унылым и долгим. Решил залезть в SQL. Дабы не нарушать целостность базы, остановился на следущем варианте: В SQL распровести и пометить все документы на удаление за выбранный период, а затем уже штатными средствами удалить помеченные на удаление. Для начала сдвинул ТА поближе к Рождеству Христову. Первым запросом распровожу и помечаю: UPDATE _1sjourn SET ismark=1,closed=0 WHERE date_time_iddoc <= 20071230 Дальше, удаляю изменения периодических элементов, сделанные документом DELETE FROM _1sconst WHERE objid <> '     0   ' AND date <= '2007-12-30' and docid <> '     0   ' И наконец, удаляю движения этих документов: DELETE FROM ra99 FROM _1sjourn WHERE ra99.iddoc = _1sjourn.iddoc AND _1sjourn.closed = 0 (и так по каждому регистру) Подскажите, я ничего не упустил? Ах, да! Уточню, что база построена на регистрах.

Удалит и после ТА тоже. Тренируйся на копии

Хотя миль пардон, у тебя ж при снятии пометки date_time_iddoc <= 20071230, вот только сработает ли условие...

В общем вроде бы все путем, только после этого ТиИ надо будет сделать. Чтобы таблица перекресных ссылок пересчиталась. Ее структура до конца не расписана, а после таких вмешательств бывает, например, что док из журнала изчезает, хотя в общем есть ))

ОК. Спасибо. Меня просто смутило то, что в таблица RG* есть какие-то строки, хотя до ТА нет ни одного провденного документа. Видимо, это просто мусор, который исчезнет после пересчета итогов

ТА не имеет отношения к rg, это для ra актуально. Итог на ТА рассчитывать не надо, а до ТА = ra на предыдущий месяц + движения по rg. В твоем случае пофик где она.

итог на ТА: . а это с расчетом: .

О, спасибо! очень полезная инфа. буду изучать

Только rg с ra местами перепутал :) Ну, короче для итогов она актуальна, для движений нет. ЗЫ: При переходе по ссылкам последняя точка не подхватывается, ставь руками, чтобы увидеть на какой пример ссылка.

А остатки не надо переносить?

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

Да это элементарно, переносишь ТА в начало базы, затем в конец, они сами пересчитаются. Там проблемы есть посерьезнее итогов. См. , нарывался я...

Каждую неделю одна и та же тема - как почикать базу в несколько гиг. В итоге все почему то начинаеют лезть в таблицы... Рецепт "без химии, и вредных для печени антибиотиков": 1. Откатываем ТА и БИ (при наличии) далеко взад. 2. Удаляем доки в транзакции по 100-200 штук. На 10 Гиг уйдет не больше 2 часов. На хорошем серваке вообще в час можно уложиться. Но наши люди легких путей не ищут...

+100

-100 :( через 10-20 транзакций выходим-заходим в 1С, патамушта есть такой прикол у скуля +1 все верно, только перед "сверткой" хорошо бы зафиксировать остатки регистров и бух итогов на дату "свертки" служ. или стандартными документами, чтоб потом ручками не вносить остатки. Итоги можно очистить все - Пересчет итогов делать прейдется все равно    ТекстЗапроса = "          |update

+ сорри - это старая метода. тут удаляются и движения. после необходимо пеерситать итоги + перепровести документы от даты свертки

+ пеерситать = пересчитать

+ 1 по первому абзацу, остальное лень читать :) Думается что штатное удаление растянется на долгие часы и займет времени больше чем резка + ТиИ Откуда у людей 2 часа непонятно если напрямую режется часа полтора-два на примерно такой базе

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

Пробовал штатно (и с транзакциями тоже), за сутки 1 год пометился на удаление. Потому и полез в скул. А Вы говорите 2 часа тут всплыла проблемка другая. Я еще забыл сказать, что это распределенка. Но она решилась просто - пересозданием переферийных баз. А при простом обновлении (которое заняло около 20 часов) эти документы остались.

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

А зачем ты режешь такую маленькую базу?

Понятие "маленькая" и "Большая" - относительны :-) и у каждого - свои...

с какого объема начинается большая база в Вашем понимании?

Гигов хотя бы 150-200.

Это для самописок, написаных прямыми руками :-) Для штатных - 10Г уже ощутимо много. Ну а для написанных кривыми руками - и 1Г может оказаться пределом :-))

А разве не перевелись еще мазохисты, работающие под скулем на абсолютно типовых конфигах? :)

Ты не поверишь - дофига таких. Особенно умиляют типовые комплексные, особенно в которых считают з/п и ведут УСНО... песТня... Если остатки зафиксены, итоги пересчитывать не нужно.... ПОищи на инфостарте... Там была обработка от Вадимко - ей по сути пофиг, что сворачивать...

Задам тупой вопрос - а документы ввода остатков на 010108 сделал? А то как-то смутно написано, типа сначала удаляем а потом чешем репу по несостыковке сумм... Скульная база режется часа за 4 (в среднем). Режется спокойно и неспеша, с пивом (водочкой), рыбкой и пр. неизменными атрибутами ритуала обрезания.

всё сделано. тока на конец 2007. Ну, да не суть... Уверяю вас, всё работает нормально. Можете упрекать меня в дятловстве и криворукости, мне уже всё-равно :)

"через 10-20 транзакций выходим-заходим в 1С, патамушта есть такой прикол у скуля" Прикол знаю. Но блин, как я 30Гиг в свое время за 4 часа резал.... Наверное потому что сий эффект сильнее проявляется именно при выборке итогов в момент проведения документов, а не при удалении документов. А, знатоки-с?

через 10-20 транзакций выходим-заходим в 1С Зачем?

а я знаю? так есть. Если у Вас по другому на скуле - завидую молча :)

Не завидуй, а почитай про ReconnectNative :-)

спасибо. почитал. будем использовать.