УТ 10.3: резко вспух файл выгрузки
 

УТ 10.3. Добавил в документ Событие масенький реквизитик (Подразделение).
После этого файл выгрузки (dt) резко увеличился в размере. Был 1,5 ГБ, стал 5,7 ГБ.
В чём причина, как лечить?
Событий конечно в базе много, но не настолько, чтобы база вспухла в 4 раза.

ну глянуть какая таблица больше занимает

2(0) У меня был аналогичный случай, оказалось манагеры в хранилище значений закачали наискучнейшие рекламные ролики от поставщика на 3 Гб (лучше бы немецкой порнухи... веселее бы было удалять).

а зачем удалять? 1С уже почти как ОС

браузер нормальный надо под 1С токо

расследование выявило, что распухание по времени произошло в период с 24 по 28 сентября.
проверил - никто в этом интервале фильмов в хранилище не закачивал.
тут что-то другое.

у нас база 17 тыс. документов (всё за 7 лет работы), занимает уже 45 мб. Исполняемый файл - 7 мб. (добавили конфигурацию Сервисный Центр, втиснули 10 справочников, 4 документа, 3 отчета (пока 2;-), несколько печ. форм., в общем на 2 мб вырос экзешник).

а есть для серверной базы какой-то аналог chdbfl.exe ?

(7) 1cv8a.exe ?

(7) а почему не 1?

(8) что это? у меня в Program Files такого нет.
(9) у нас разделение. Есть админ БД (это я), есть системный админ. SQL-сервером рулит системный админ. Его не будет до понедельника, поэтому посмотреть на SQL-сервере ничего не получится.

10-Ирли Бёрд > [em]что это?[/em]
в гугл. например:
[url]http://www.forum.mista.ru/topic.php?id=450483[/url]

10-Ирли Бёрд > [em]у меня в Program Files такого нет.[/em]
на users.v8.1c.ru лежит.
крайняя версия для 8.2.13.219, кажется.

да, и естественно, сначала режим просто тестирования, без тестирования [b]и исправления[/b].

Это хит года. Сисадмин приглядывающий за сиквелом еще куда ни шло, но вот админ баз данных не имеющий доступа к сиквелу - это определенно нанотехнологии.

(13) а по делу есть что сказать?

[quote=angro;27040523] ну глянуть какая таблица больше занимает [/quote]

[img]http://s017.radikal.ru/i433/1210/de/101c8c64ae68.jpg[/img]

_AccumRgT4229 - это РегистрНакопления.ЗаказыПокупателей
Итоги
_InfoRg3924 - РегистрСведений.СобытияКалендаряПользователя
_AccumRgT4128 - РегистрНакопления.НДСРасчетыСПокупателями Итоги

По ходу, видимо придётся делать пересчёт итогов. С регистрами накопления проблема должна уйти.
Но что делать с регистром сведений СобытияКалендаряПользователя ???

(17) так первая колонка это резервед, sql сервер всё равно потом сколько надо зарезервирует. Сортировать тогда уж по датакб надо.
кстати а тии делал?

(18) ТиИ ещё не делал
вчера не рискнул, побоялся что не успеет домолотить к утру.
Сегодня вечером видимо придётся запустить, других вариантов не вижу. Хотя бы с одной галкой "пересчет".
Понять бы, почему dt-файл выгрузки резко распух на 4 гига?
Эти 4 гига нужно найти, где приросло.
Щас наверно попробуем поднять старый бэкап недельной давности, посмотреть какие таблицы распухли за неделю.