ут 11, уже 46 гиг, с 2004 года
скорость не страдает, dt где то час делвется, тии давно не делал, предполагаю что за ночь уже не уложится, и вот стали мысли такие посещать а не пора ли?

Свертку регистра / регистров - когда захочется / когда потребуется

Файловая что ли?

(0) Ответьте для начала самим себе на простой вопрос: А зачем?

В 95% свёртка не нужна. В остальных 5% необходимость связана каким-либо административными причинами - скрыть/спрятать данные, либо методическими - обрезать косячные данные для перехода на другие методики ведения учета.
Ну еще пожалуй бывают чисто технические причины - подготовительный этап для переноса данных в другую систему или на новую редакцию. Хотя это можно отнести к методическим причинам.

Ну и ещё. Учтите, что сильной выгоды от свёртки не получите. Даже если свернёте до 2015 года (3 года надо оставить для анализа динамики, аудиторский след, возможности нормально вносить корректировки реализации и поступления), то сокращения базы не будет в 4 раза (скратить с 12-ти лет до 3-х).

Короче я против свёртки. Особенно, когда не знаете, зачем она вам нужна.

дт - это не архив

(4) может человек себе копию в другой субд делает и разрабатывает там... или в файле...

(0) Когда делать нечего.
Особено если "скорость не страдает".

P.S. Зависимость от времени выгрузки .dt — признак непрофессионализма.

(3) "В 95% свёртка не нужна. В остальных 5% необходимость связана каким-либо административными причинами - скрыть/спрятать данные, либо методическими - обрезать косячные данные для перехода на другие методики ведения учета" // Все с точностью до наоборот - ни одной причины делать свертку регистра нет, кроме как технической - уменьшить занимаемый этим регистром объем на диске

(7) Тут все от объемов зависит, в данном случае 46 гиг за 14 лет - ниочем, а в остальном - (3) +1, только руководству это объяснить сложно

не ну скульные архивы каждый день делаются, .dt просто как то перед правкой конфы спокойней что ли, да места на диске (sas) не резиновое, копия для разработки полюбому есть, просто вопрос чем руководствоваться, когда "ПОРА".

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

(0) УТ11 с 2004 8-O ? Это сколько же было переходов на новые редакции. С УТ10 на УТ11 переходили уже с огромным объемом данных, получается?

Давно уже пора

(11) УТ10 вышла в 2003, в 2004 вышла УТ10.1, УТ11 в 2012

Как они могли в 2004 вести учет на УТ11?

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

переход был с 7.7 в 2012, потом свертка и обновление на новые редакции ибо в 2012 было все с ут 11 плохо, сейчас сидим на редакции января 2014 года, руководство все устраивает, мне хотелось бы конечно но когда просят минимум лям за обновление на текущую версию ут, без гарантий,  никто не выдерживает.. я сам тоже не хочу быть крайним

(13) да сорри, с 2014

2(0) Если файл, то когда одна таблица достигнет 4Гб база накроется (ну не совсем, а просто запись в таблицу будет не возможен), а что за таблица только тебе оценивать. Вот тогда и нужна будет свертка.
Думаю бардак у тебя в УТ, оценивай прирост в месяц и поймёшь что будет завтра с базой.

(17) У него скуль если чё

Причины когда бы я рассматривал свертку:
1. Долгое восстановление из бэкапа.
2. Не хватает места на диске.
3. Проблемы с регламентами скуля.

Возможно, надо делать не свертку, а какой-нибудь жирный справочник присоединенных файлов грохнуть (или вынести в отдельную базу / место)

ИМХО Когда к данным из обрезаемого периода обращаются менее 3 раз за год. Если сильно затянуть то потом окажется что за то время когда базу можно спокойно обрезать обрезается катастрофически мало. А при переносе данных в новую базу успеваешь перенести слишком мало. и потом в старую базу народ вынужден по несколько раз в месяц заходить чтобы получить нужные данные. или рисовать отчеты которые будут их тянуть из старой базы.

Тоже задаюсь вопросом о свертке.

Есть 2 базы: Дописанная УПП и почти полностью переписанная Управление хлебозаводом (ОБД).

Между ними обмен. Файлы данных : УПП - 490гиг, ОБД - 176.

Размеры sql Бэкапов : 44 и 29 соответственно.
Время бэкапа (полного) - 12минут и 22 минуты.
Обновление статистики : в районе 15 минут.

Итоги считаю периодами (годами или кварталами).
Дисковое пространство имеется.
Базы ведутся с 2012 года.

Подскажите пожалуйста, стоит ли заниматься "резкой баз" или оставить все как есть?

(22) Можно еще исходить из того, есть ли куда развернуть базу если боевой сервер загнется.

(23) Да есть. В той же стойке стоит абсолютно зеркальный сервер , на котором развернуты тестовые аналогичные базы для доработок.

(0) Если хотите потерять обороты в регистрах за прошлые годы - вперёд. Нет снижения быстродействия - нечего париться.

Правда на нем еще висит терминал сервер на 30 пользователей, но в случае краша основного сервера, терминал повинится или временно устранится вообще.

подвинется

(24) Тогда срочности нет. ИМХО.

(28) Тоже думаю, по моим наблюдениям дисковой подсистемы хватит еще на 3-5 лет, потом сделаем апгрейд либо приобретем новые сервера.

46 Гб это мало. у заказчика база под 1Тб. без свертки тяжело им сейчас.

а когда накрылись быстрые диски медным тазом, которые нигде не купить, тогда вообще все ИТ на уши поставили.

а потом и вовсе реорганизацию ИТ затеяли :)

По опыту использования БП КОРП 2.0 в 450++Гб могу сказать, что лучше все же сворачивать до 3-5 лет. Типовой переход подразумевает перелопачивание всех документов в базе и чем их больше, тем дольше будет крутиться процесс. Может занять дни.

Даже если использовать перенос своими силами через свертку и КД все равно времени уйдет до дури, а уж трудозатрат тем более. Один перенос свернутых данных через xml чего стоит. На файле в несколько Гб я сбросил процесс.

(4) +1

(7) > уменьшить занимаемый этим регистром объем на диске

Нет такой потребности. Эта маструбация со свёртками ради сокращения объема базы данных была актуальна для клюшек.
На снеговике конечно тоже такое иногда возникает, но это либо какая-то совсем уж безумная особенность учета (например, десятки и сотни тысяч отгрузок ежедневно), либо что-то не так с проектировкой регистра, когда он не закрывается в "0" и растут таблицы итогов.