Помогает ли реально упаковка базы? и стоит ли вообще её делать? #16447

Помогает ли реально упаковка базы из Тестирования и Исправления?И стоит ли вообще её делать?//проводил эксперимент по упаковке вроде уменьшилась, по перед этим все помеченные удалил и протестировал ТиИ баз

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

Это я знаю(так и The Bat с письмами делает)я про работоспособность базы после этого хочу узнать, а то я представляю что будет когда я база в ТиИ загоню, может и не взлететь(боюсь человечского фактора от фирмы 1С)

упаковку базы делаю раз в год при переходе на следующий. пока все ок :)

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

2 Давайте не будете говорить про то, что не знаете... Никто не спорит о том, что упаковка базы не нужна. Мысль моего поста была в другом : не всегда упаковка базы приносит существенное уменьшение размера БД. И причина этого в том, что 1с-кий движок доступа к ДБФ использует механизм повторного использования удаленных записей.Проводим простой опыт : Берем стандартную демо-базу ТиС. Выгружаем Доки через XML.Помечаем доки на удаление. Удаляем. Загружаем обратно Доки . А теперь посмотрите, сколько в дбф у нас помеченных на удаление записей. И окажется, что их практически нет (я насчитал их с десяток).А следуя вашей логике, этих записей должно быть около половины.

размер файлов DBF 3.72ГБ. Сделал упаковку. Результат - 0. Поможет только в том случае, если ты делаешь закрытие периода и удаляешь немеряно информации

Вместо упаковки лучше сделать Выгрузку-Загрузку...Кучу мусора смоет точно. И базу упакует.....P.S. вот только на 3-х гектарах загрузка будет небыстрой...

делал на базе 1.2 метра после загрузка-выгрузка подрасла на 1 метр, что на это скажешь?

сорри база 1.2 гб подросла на 1 мб

А ХЗ... У меня всегда реально меньше получается....

база уменьшилась, МЛГ распух....:)))))

Вообще-то канечно 1С-овцы сделали лажу с повторным использованием удаленных строк в дбф-ах. При каждой вставке новой записи в таблицу - 1Сина сначала ищет по индексу (она держит специальный тэг в cdx для этого дела) удаленные записи - и если находит - то вместо вставки перезаписывает эту строку. В итоге - скорость вставки записей падает, и, имхо, не кисло. Хотелось бы иметь возможность отключать этот механизм, а в идеале - отключать по конкретным таблицам...

с 600 метров до 550 уменьшилась

действительно, может, считаем по разному... Я смотрел размер только ДБФ.... Сделав такой механизм, 1с-Овцы ликвидировали регламентную операцию - сжатие базы, которая была во всех фокс-подобных системах... В общем, ориентация на глЮпого юзера... Для массовой системы и небольших контор с достаточно темными юзерами - наверное, правильное решение....

Народ я упаковывать не пробывал. А вот с SQL базой работал, когда моя малютка достигла 6 гигов и даже продвинутый SQL сервер на на 2-ч процессорном ксеоне стал подтормаживать, я её выгрузил и загрузи (полная выгрузка) она уменьшилась на полтора гига.

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

В SQL-базе нет "записей, помеченных на удаление"...

2 Имхо не факт.. Думаю скорость тут очень сильно зависит от размера базы и особенностей движка. Всяко Изменение записи быстрее чем вставка. Плюс теоритически при вставке новой строки надо блокировать всю таблицу, а при изменении только одну строку.Спорить о особенностя движка не буду, но в бытность мою прогом на фоксе под дос (лет 12 назад) стандартным решением для увеличения быстродействия самописных прог, работающих в разделенном режиме при большом размере дбф считалось добавление n-го количества пустых записей в базу (с установленным каким-нибудь флагом). И насколько я помню, такое решение действительно давало прирост производительности

А моё мнение такое, что если база стала больше гига, её нужно переводить под SQL, структура ДБФ, сама по себе в этом случае начинает гонять и тормозить. Как я понимаю весь сыр бор с уменьшение размера, идет из-за скорости работы. Чем меньше база, тем быстрее скорость, но для ДБФ стакими объёмами данных 50 метров уменьшения, как мертвому припарка./ почитайте маленикие хитрости, может кому полезно будет.

ага, вспоминаю (Fox)... scatter memvar blank, gather memvarа потом при добавлении set order to code, go top,if !empty(code) - > append blank. Ностальгия прям по быстрой скорости работы с базой.