8.х Неконтролируемый рост базы

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

Дано: платформа 8.1.15.14 в серверном режиме. Базой пользуются от 40 до 50 пользователей в рядовой будний день. Документооборот - около 2500 документов в день. Конфигурация: в девичестве была УТ 10.2, а ныне самописная злостная вещица, утерявшая свой изначальный облик и продолжает терять его ежедневно.

Конфигурация сервера в файле "конфа_1С.htm", прикреплённом к сообщению.

База данных зверски растёт ежедневно. Динамику, при желании можно посмотреть в прикреплённом изображении "Динамика роста.png".

Что пытались сделать:
А) Пользовали поиск, потому сразу отвечу на самые частозадаваемые вопросы:
1. Шринк не предлагать - не помогает.
2. Не предлагать покупать сервер по-круче.
3. Лог-файл, как-раз-таки, растёт весьма и весьма терпимо.
4. Помеченных на удаление объектов - полтора землекопа.
5. Удалять движения не предлагать - у нас рост базы начался в периоде, движения за который всё ещё актуальны (середина 2009 года. Сам момент начала разбухания базы профукали, не придав ему тогда значения, и теперь уже не знаем, какие события на это повлияли)

Как можно догадаться - ответа на интересующий меня вопрос я не нашёл.

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

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

Это только dt-шники. "Живая" база растёт (в среднем) на 500 Мб в день.

Отчёт в прикреплённом файле. (заархивированный экселевский документ)

Стоит обратить внимание на таблицы:
Посмотреть вложение 4510

Что говорит метод глобального контекста ПолучитьСтруктуруХраненияБазыДанных() про эти таблицы?

*шокированно пожёвывает чайную ложку*
Что же я раньше-то не знал про такую читерско-шикарную функцию?

Собственно, имеем следующие результаты: самым прожорливым оказался любимый начальством, в целом, и, в честности, мной (хоть я и не начальство) Журнал Изменений (про который, кстати, рекламировалось, что он ничерта не прожорливый - впрочем, это решается курением мануалов - там есть самопроизвольная выгрузка данных во внешнюю базу)
Reference7301.VT7318 = Справочник.bpЖурналИзменений.ТабличнаяЧасть.ИзмененияОбъекта

И далее, второй по прожорливости:

AccumRegTotals4229 = РегистрНакопления.ЗаказыПокупателей

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

AccumRegTotals4128 = РегистрНакопления.НДСРасчетыСПокупателями
AccumRegTotals4951 = РегистрНакопления.НДСНачисленный

У нас аккумулируется всё тем же заказом.

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

Как заметил BabySG, итоги у РН в ноль не выходят видимо, поэтому AccumRegTotals4229, AccumRegTotals4128, AccumRegTotals4951 имеют такой большой объём.
Примитивные данные в измерениях случаем, не храните?

Я так понимаю, Reference7301.VT7318 содержит много примитивных типов данных + возможно, индексирование по ним - отсюда его "пухлость".

Я-то эти регистры не дописывал... Но когда я пришёл, УТ уже УТ не являлось и было сильно изменено, потому за действия предшественника ручаться не могу.

Содержит-содержит, но это должно быть решаемо - изменил параметры архивации (кто-то мудрый выставил хранение записей в основной базе 30 дней), изменил на 7 дней (для начала) и запустил архивацию во внешнюю базу... В любом случае, там множество настроек и Reference7301.VT7318 вполне может быть уменьшена простым чтением мануалов (и грамотной настройкой, конечно же) без использования конфигуратора.

Вот этот вопрос мне ещё стоит рассмотреть, как дойдут до него руки (сейчас разбираюсь с Reference7301.VT7318, так как 1) она самая пухлая 2) я знаю, что с ней делать), и тогда уже я расскажу о результатах данного предприятия.

Извиняюсь, коллеги, а как вывести отчет по размеру таблиц SQL (2000)?

Например вот так:

Код:

USE [SQLNAME вашей БД]
DECLARE @tbl_tmp TABLE(  f_name NVARCHAR(128)
,f_rows NVARCHAR(128)
,f_reserved NVARCHAR(128)
,f_data NVARCHAR(128)
,f_index_size NVARCHAR(128)
,f_unused NVARCHAR(128)
)

DECLARE @name_table NVARCHAR(MAX)
DECLARE pay_cursor CURSOR LOCAL FOR
SELECT 
TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='BASE TABLE' AND TABLE_NAME<>'dtproperties'
OPEN pay_cursor
FETCH NEXT FROM pay_cursor 
INTO @name_table
WHILE @@FETCH_STATUS = 0
BEGIN
PRINT @name_table
insert @tbl_tmp exec sp_spaceused @name_table
FETCH NEXT FROM pay_cursor 
INTO @name_table
END
CLOSE pay_cursor

SELECT * FROM @tbl_tmp ORDER BY f_reserved

Ругается:

ХЗ. Под рукой нет 2000 сервака, в 2003 работает (им и пользуюсь)
Может для разнообразия открыть справку по скулю и почитать что этой ... ля ля ля не нравиться?
Может типа нет такого NVARCHAR? (лень лезть)
Скриншот, в котором была бы видна ошибка и текст запроса (как вы его перенесли) мог бы помочь.

Сорри, неправильно первую ошибку написал, та была после моего "колдовства":

Скриншот: Посмотреть вложение 4847

п.с. я почему-то думал, что это можно сделать стандартными срдствами, без использования запроса.

Стандартными можно - но посмотреть размер ОДНОЙ таблицы SQL (разворачиваем таблицы, првой кнопой мышы вызываем контекстное меню - зырим в свойства таблицы), а я так полагаю надо ВСЕ (а их даже в маленькой базе как то дофига)?

И да, ошибка то ЫЛЕМЕНТАРНАЙА - нет в 2000ом скуле ВАРЧАРА(МАКС) вместо МАКС напиши чтонить типа стопицотмильоновсто... хотя хватит и 300 (врядли у тебя в базе есть таблицы, с именем более 300 символов... ну поставь 305 -чтоб наверняка :unsure: )

Все равно ругнулось:

Нашел в просторах тырнета, отработало нормально:

Код:

DBCC UPDATEUSAGE (0);  
CREATE TABLE #t([имя таблицы] varchar(255), [строк] varchar(255), [зарезервировано] varchar(255), [всего данных] varchar(255), [размер индексов] varchar(255), [свободно] varchar(255));  

INSERT INTO #t  
exec sp_msforeachtable N'exec sp_spaceused ''?''';  

SELECT * FROM #t ORDER BY CONVERT(bigint, REPLACE([всего данных], ' KB', '')) DESC;  

DROP TABLE #t;