Удаление нулевых записей из таблицы остатков регистра #516036

Доброго времени суток, уважаемые! Конфигурация ТиС 9.2 много раз переписанная. Имеется следующая проблема. Разросся регистр остатков - Заявки - вследствие того, что движения, сделанные Заявкой покупателя закрывались не полностью Реализацией, и при каждом последующем открытии периода незакрытые остатки все переносились и переносились. Возникла задача корректно закрыть этот регистр. Что было сделано: введен корректирующий документ, анализирующий не закрытые остатки с давних периодов. Табличная часть полностью соответствует набору измерений и ресурсов регистра. При проведении формируется минусовое движение. Т.о. остатки закрываются. Что делает 1С-ка в процессе проведения: пересчитывает итоги по каждому из периодов, и выводит их, соответственно в 0. Далее, я посредством t-sql делаю удаление записей, для которых значения ресурсов равны нулю. Все хорошо, количество записей в таблице сокращается, делаю shrink базы, ее объем уменьшается. А теперь, собственно, проблема! Как только я ввожу (провожу) последущий документ закрытия, размер базы сразу же откатывается к тому, который был до шринка. Не могу понять, в чем дело? Может, надо еще что-то подчищать, помимо записей в таблице остатков? Полный пересчет итогов сделать не получится - база огромная, такого количества времени просто нет.

раз t-sql'ем владеешь, то и посмотрел бы, что у тебя место жрет

"размер базы сразу же откатывается к тому, который был до шринка" это не размер базы откатывается, а sql выделяет место на величину указанную в свойствах серверах на закладке Data files в свойствах базы, если стоит флаг автоматически увеличивать файл. Ну я так примерно предполагаю из твоего описания.

Так что это нормально.

Этой операцией ты особо рзмер текущей базы не уменьшишь. Просто на будущее замедлится рост размера таблицы остатков по этому регистру.

А как тогда можно уменьшить размер самой БД? Просто в таблице сейчас порядка 130 млн. записей + с каждым открытием периода (декада) кочует порядка 1,5 млн записей, + их количество, соответственно, все увиличивается. ?

Резать, не дожидаясь перитонита.

1. "огромная база" - это скока в граммах? 2. Почему не пользуешься имеющимися и "широко известными в узких кругах ограниченных людей" обработкам  по пересчету, удалению нулевых итогов ит.п. 3. почему, с конца-то на конец, не закрываются регистры?

если спешить некуда - грохни все индексы

Огромная - 60 Гб. На самом деле взя беда в том, что на сервере приходится одновременно держать 3 копии этой базы. 2. Обработки и т.п. по пересчету, удалению - если честно, не знаю про такие, но есть мнение, что будут работать не очень быстро 3. С конца на конец не закрываются, т.к. нет движений, их закрывающих :) А незакрытые остатки обязаны переноситься с периода на период. А как грохать индексы? o_O Вроде разобрался с увеличением размера. Поставил в свойствах базы file grow не 20%, как было, а 1 MB. Вроде, перестала расти. Сижу, проверяю...

Насчет 1 MB это ты как-то резко. Поставь хотя бы 5 %. А то она у тебя постоянно тыркать этот файл базы будет. Что не есть хорошо. Можно не грохать, а переиндексировать. Конфигуратор -> Администрирование -> Тестирование и исправление. Или поищи скрипты для SQL. Может еще немного полегчать. Но основная проблема это "С конца на конец не закрываются, т.к. нет движений, их закрывающих". Там ж е по идее должен быть документ "снятие заказа покупателя" или что-то в этом роде. Надо чтоб закрывалсиь, а то будешь каждый раз любовью заниматься.

так в том-то и дело, что аналог этого документа я сделал, он закрывает "висяки", но при проведении сам не грохает записи с нулевыми ресурсами. приходится это скулем делать. Да, насчет 1МБ, действительно, погорячился :) ТИИ не вариант... начал было делать... так у меня скулевские логи все свободное место на серваке сожрали и база полегла. благо, это у меня тестовая.

Забудь вообще про shrink ( У тебя что самый ценный ресурс на sql сервере дисковая память ? ) >>>Вроде разобрался с увеличением размера. >>>Поставил в свойствах базы file grow не 20%, как было, а 1 MB. >>>Вроде, перестала расти. Сижу, проверяю Если не понимаете что делаете то лучше вообще не трогайте ничего. Операция по увеличинию файла данных и файла журнала очень дорогостоящая в терминах sql сервера. 1мб мало для любой базы и это приведет к замедлению работы sql сервера в целом и это дорогостоещее приращение будет делаться слишком часто. Вот вам простейший пример оцените во что обойтеться с таким приращением перестроение одного индекса. Какие значения ставить для приращения это творческая задача однозначного ответа нет. Поставь например так  для данных от 50 до 100 Мб для журнала от 10 до 30 Мб

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

"У тебя что самый ценный ресурс на sql сервере дисковая память" - получается, что немаловажный. По крайней мере админ ругается на нас (программистов), что допустили разрастание базы до таких размеров. И отчасти он прав - зачем таскать весь этот мусор Но более критична, на самом деле, производительность. Время на проведение документов - по 8-15 секунд. С учетом не малого объема документооборота в день получаются очень большие потери на "перекуры" между проведениями...

60Г - немало. Сколько из этого занято реальными данными? :-) 3 копии базы - извините, задам ТрадиционныйКитайскийВопрос™ обаботки - работают реально быстро. Причем в разделенном режиме. Причем "по кусочкам" (например, можно пересчитывать "на лету" какой-либо регистр по какому-либо измерению) удобно же? Ну, или переиндексировать по одному индексу с паузой. (удобно в режиме 24*7) Ну и регистр _должен_ закрываться.  иначе его смысл теряется.

реальных данных, думаю, где-то на 20 ГБ. не больше. 3 копии - рабочая, игрушка бухгалтерская, игрушка разрабов нельзя ли поподробнее насчет обработок?

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

И что "поподробнее насчет обработок"?

Увеличь период до месяца - итоги похудеют раза в 3. Правда проводка задним числом будет медленнее. А чо там за остатки - аж 1,5 ляма записей?

я бы сделал просто - в принципе я эту задачу обсуждал (у меня тоже скуль). как бы сделал я. ЕСЛИ ВАМ НЕ ВАЖНА ИСТОРИЯ ЗАЯВОК и РЕЗЕРВОВ и ЗАКАЗОВ ПОСТАВЩИКАМ. 1. бэкап 2. составить список действительно актуальных заявок и заказов. 3. дропнуть (прибить) все таблицы регистров Зявки, Заказы, ЗаказыЗаявки, Резервы. 4. пометить на удаление все заявки и заказы кроме п.2 5. вычистить упоминания помеченных заявок и заказов как документов-оснований: - удалить все доки "Снятие резерва", "отмена заявок" - обнулить доки-основания в реализация, поступлениях, выписках, пко/рко (если докоснование.вид = заявка/заказ - посмотреть на документы сторно, если надо - прибить. 6. штатно удалить помеченные, если все по предыдущим пунктам подчистили правильно - удалиться дествительно все. 7. упаковать базу. 8. перепровести базу (или отдельные цепочки дово) по актуальным заявкам/резервам. - и все ок!!! буквально недели две назад сделал все у себя так. потому ка кне знал как дропать таблицы в скуле - выгрузил в дбф (благо база немонстр), сделал весь объем работы, загрузил в скуль. основное время заняла загрузка выгрузка. на действительно содержательную работу ушло где-то с час. и 2-3 обработки в 10-15 строк. все.

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

документ, который закрывает висяки - это хорошо, но плохо. не дай бог придется откатить базу в ТА на предыдущий месяц (мало ли что, хотя на базе в 60 гиг вряд ли это будут делать, скорее база чисто для оперативной работы) - пойдет пересчет итогов и все снова впадет в ступор... . после приведенной выше операции база с 32 гиг всяким шринканьем и подчисткой в результате превратилась в 8 гиг, при этом свободное место еще присутсвует... . реально если много висяков базу можно ужать ОЧЕНЬ СИЛЬНО. не удивлюсь, если после всех операций объем базы уменьшиться процентов на 50 как минимум. Даже на мелких базах в особо запущенных случаях эффект очень значительный. . Еще обязательно надо смотреть регистр партий. и Регистр по банку/кассе - особенно по кассе - если много кассовых операций - релдко кто с кассы списывает - все в основном бабло принимают и на этом стоп...

Ему просто-напросто надо закрывать полностью регистр. Если система - "одна заявка-одна реализация" - то принудительно закрывать в ноль. Если "возможны варианты" - в реализации галка "последняя отгрузка", по которой в ноль. Или отдельным документом это делать.

также рекомендую если не ведете книгу продаж/прокупок в торговой базе - "заремить" регистры этих книг. Делается двумя операторами в коде. Регситры - прибиваются просто безо всяких затей дропами соответсвующих таблиц. . потому как в одну сторону книги покупок продаж ведутся ВСЕГДА при штатных алгоритмах, а в другую закрываются только регламентными документами, которые надо делать по концу месяца - что никто не делает..

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

сомневаюсь... надо опираться на соотношение размеров таблиц итогов и движений. . +  для отмены телодвижений по регистрам книг ищем в конфигурации ОБЪЯВЛЕНИЯ ПРОЦЕДУР типа с параметрами ...имяпроцедурыкакоето(РегВзаим,РегКнига, . и после . так как ниже по коду идет формирование движений по регисрам книг

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

вам бы хирургам все резатть.. не надо ничего РЕЗАТЬ! таблеточку из - лишнее само отвалится

у мну например за время отсутсвия умудрились так засОРДА базу, что блин трындец - коматоз.. лечить смысла нет.. буду резать...

Хорошо, если хирург поможет, а то ж может только прозектору работа и останется :).

- Я врач, работаю с людьми в тесном контакте. - а специальность? - паталогоанатом...

Начиная с п.4 уже не подойдет. На базу тесно завязан ОЛАП, а он всю инфу берет из документов. Знаю, что не правильно, но это - не мое решение. Поэтому прибивать документы - чет не хочется - себе потом дороже выйдет - хрен его знает, что в этом ОЛАПе передернеца. Именно поэтому и хотелось просто "корректно" (в кавычках, потому что все равно не штатно получается) закрыть регистры. С партиями, кстати, тоже беспредел твориться, но немного получше - всего 50 млн. записей :)

это я и без программулек могу, напрямую скулем, собственноручными запросами. изначально просто проблема была в неуменьшающемся размере самой БД, несмотря на прибитые нулевые записи.

не вариант увеличивать период - тогда документы будут проводиться не по 8-15 сек, а по все 20-30...

Что занимает основное время при проведении? и бухподсистема - есть?

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

фигассе. А это основной вопрос, в общем-то...

:) Ну, если честно, да. Просто по факту вижу, что проводятся очень долго. И чувствую, что если почистить регистры, должно стать получше. Т.к. кроме регистра заявок и партий больше особо ничего не заср... загажено, то начал с них. Попутно, пытаясь высвободить несколько лишних ГБ места на диске.

Не с той стороны заходишь. Запусти отладчик в режиме замера времени и проведи несколько документов. Посмотри на результат - будешь сильно удивлён.

заинтриговал. сейчас проверю.

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

ну посмотри в олап.. реши кардинальный вопрос: нужжна истори заявок/резервов или нет. если олап написан хоть немного грамотно (кактиповые 1С) то корректно отработает и при наличии заявок и при их отсутсвии... . а затыкание дыр путем закрытия "висящих" итогов... ну да, можно сказать что в этой ситуации и это является решением. но скорее всего в такой ситуации если ТАКАЯ работа идет постоянно - существует куча "потерь" в заявках/заказах из-за их корявости. и народ тратит определенную ТОЛИКУ ВРЕМЕНИ на борьбу с ними. можно с высокой вероятностью предположить что юзвери активно используют свои ежедневники для ведения своего "правильного" учета...

аа.. это ж 8-ка.. хз чего у них там унутре...

а, нет! 7-ка!!!

ну, закрытие заявок я и так собираюсь переделать - просто сейчас доходит до полного абсурда - количество закрывается, сумма остается висеь - из-за того, что сумма по заказу берется не из заявки, а пересчитывается в соотвествии с типом цен... короче, дурдом. , - проверил. 44.30% времени - обращение ко временным итогам - это на примере проведения одного документа. По факту - работы в ТА практически нет

вот и ответ. Переписывай этот кусок. Хотя бы на прямых запросах. Или проверь фильтры перед расчетом.

поставь на перепровдение день доков. и засеки еще раз. цифру в студию.

+ Может там и остальные 65 % можно тоже оптимизировать.

прямые запросы - выход конечно, тем более на них уже пол конфы переписано, но! прямые запросы в данном случае, на мой взгляд, зло. они нужны при больших объемах данных, несущих информационный смысл. а когда 90% записей регистра - просто мусор, то использование прямых запросов просто позволяет не замечать проблемы. собственно, так и получилось с данной конфой - стала тормозить - перевели на прямые - а база продолжала замусориваться. часть из оставшихся 65% точно не получится переписать - это уже в самой платформе заложено, по каким алгоритмам выполняется движение по регистрам. хотя, абсолютно точно, что выполняется update итогов. и здесь, опять же, логично предположить, что проще сделать update на таблице с меньшим количеством записей. упираетмся все в ту же необходимость чистки таблицы итогов регистра.

Решай вопрос в а потом режь как я выше описал.