v7: ТиИ с предварительно удаленными rg*.* файлами #577104

Собственно кто нибудь так делает, что нибудь плохое происходит? Самая долгая операция это Пересчет итогов. В поисках чудо винтов для ускорения перепробовал кучу всего и ССД и RAM. Удалось сократить время пересчета до 6 часов А тут недавно грохнул этот файл и .... пересчет итогов занял 50 минут. Как бы разница в 7 (!) раз внушает, но остался червячок сомнения. Интуитивно я понимаю что от удаления хуже не будет, только лучше (удалится "мусор"). Поэтому решил поинтересоваться может кто знает какие грабли могут быть?

только если по запарке ещё и ra* грохнешь

Ну с RA понятно

Т.е. я так понимаю все будет хорошо

Лучше иметь базу в SQL и пересчитывать прямыми запросами только по необходимым (проблемным) измерениям...

Спасибо, ненадо

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

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

Это у вас что-то в консерватории не то....

Это повод офф-топа?

Это, собственно, оффтоп и есть.... :-) собственно, еще возникает ТКВ насчет ТиИ с пересчетом....

Со скольки сбросил до 6ти часов?

По выходным делаем ТиИ, иногда не успевает за отведенное время. поэтому ищем те педали которые ускорить ТиИ (скуль не предлагать)

Там разные компы. На работе на серваке считается за 18 часов. Дома - порядка 8 часов

как-бы ТИИ не помню когда приходилось делать кстати скуль

Отнесем скуль к разделу "религия". И предлагаю здесь пока его не предлагать (ну не прежился у меня скуль. Быстро не получится переписать под скуль)

И все-таки, ответь на ТКВ...

Озвучь его

Т.е. чем тебе ответ в не нравится

такие педали пробовал? 1. 1cv7.exe /t - с путем к RAM-диску ? 2. Диспетчер устройств - Disk Drives - нужный винт - Политика - Включить повышенную производительность. (Ускорение обычно в 2-3 раза) осторожно - второй способ требует батарейки и бекапов.

Все темпы пользователей на серваке на рам диске лежат

"Анахуа?"©

Что зачем? Зачем делать ТиИ?

Именно. Тем более, с пересчетом регистров. Тем более, каждые выходные.

холивар по поводу скуля? Может не надо А делаем ... чтобы проблем с базой меньше было. Причем с переходом на скуль не уверен что проблемы решатся. Например. Данные из 7-ки выгружаются в 8-ку и иногда выгрузка откашивает по причине недопустимый символ, который юзверы обычно заносят с помощью копипаста. Такая ошибка лечится с помощью банального ТиИ

Бывает такое. Только с пересчетом итогов это не связано, не так ли? а контроль правильности итогов можно организовать и без пересчета. Даже на файловой версии... И выборочное исправление - тоже...

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

Это только один из аспектов

И все-таки, объясни необходимость столь регулярного пересчета итогов (против проверки логической целостности я пока не возражаю... :-D)

99% - для профилактики. А 1% это или ошибки проектировании базы. Просто при определенных условиях слетают итоги по одному регистру. Ошибка редкая, а вот исправлять ее намного сложнее. Или просто слетели итоги по непонятной причине

Так я и говорю - сделай  контроль итогов, и если сбоя нет - не насилуй базу.

А если сбой есть? Т.е. сейчас если сбой произошел в будни - это достаточно проблемотично, ибо за 8-9 часов (когда никого нет) она не успеет пересчитаться

а если сбой есть - пересчитывай хотя бы только сбойный период передвиганием ТА. (это тупое решение "в лоб"), либо пересчитывай "более интеллектуально"

у меня контроль ежедневный, пересчет в случае необходимости - тоже (база 24*7, есличо)

Т.е.? как на скуле минуя 1С пересчитать итоги - я видел. А как на дбф?

Принципиальной разницы нет...

Инсерт в дбф уже работает нормально? Без проблем с индексами?

А зачем тебе инсерт? по моей статистике, необходимость инсерта не упомню. Чаще просто апдейт ресурса нужен... а он на индексы никаким боком...

Грохнул на копии базы файлы и запустил на серваке ... 2 часа, т.е. в 9 раз быстрее, так что в принципи на ближайшее время этот вопрос можно считать закрытым

ёпта, грохни rg и пересчитай в самом Преприятии, а не в ТиИ - и ты удивишься, итоги пересчитаются еще быстрее.

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

ТА на первый, ТА на последний? Или как правильно

ага. Можно и через операция - управление оперативными итогами, можно и через любой ощий журнал.

только вот нафига их все пересчитывать - хз, когда достаточно 2-3 периода максимум или итого меньше

Я ему предлагал... но человек любит "мазо..." Тем не менее, такое тоже сделано.

Что ты предлагал? Писать свою обработку?

Вниматочно читай

Ну ты как то с далека начал

ну я ж говорю, есть "тупой путь" - двигать ТА по периодам (менее тупой, конечно, нежели полный пересчет). И есть более другой - там, конечно, надо поработать, но оно окупается....

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

+ Не, если база ночью стоит, да еще и мелкая, (да и не заплатят) - то тупые решения вполне себе имеют право на жизнь. Но если чуть глыбже копнуть (база немелкая, работа круглосуточная и т.п.) - приходится извращаться :-)