Посмотрим только с позиции размеров таблиц базы данных (количество записей и объем занимаемого места).
В общем случае, чем база меньше - тем лучше.
Избыточно большие базы данных приводят к дополнительным затратам ресурсов:
1) требуется больше дискового пространства для хранения продуктивных, тестовых баз и их бэкапов;
2) требуется больше вычислительных ресурсов для выполнения запросов к избыточно большим массивам данных;
3) увеличивается время на регламентное обслуживание (реиндексация, обновление статистики, бэкап, выгрузка в dt, восстановление базы);
Конкретные примеры:
1) Большие таблицы итогов на первых позициях.
На картинке видно, что первые 5 строк (и еще 2 строки чуть ниже) - это таблицы итогов регистров накопления. При этом количество записей в них существенно больше, чем в таблицах движений. Это верный признак того, что в базе давно пора пересчитать итоги.
Если после пересчета итогов на первых позициях остались некоторые таблицы итогов, число записей в которых существенно больше, чем в таблицах движений - скорее всего, в данных регистрах не закрываются итоги по всем измерениям - это уже проблема в конфигурации, которую также очень желательно решить.
2) Одна большая таблица с большим числом записей.
Варианты возможны разные, но в данной ситуации администратор базы данных вообще не удосужился посмотреть почему же его база такая большая.
В базе включено версионирование всех объектов метаданных, а история не очищалась. В итоге за 2-3 года база выросла до 350Гб, при этом 60% просто хлам, который никому особо не нужен.
Еще один пример - регистр сведений был самой большой таблицей в базе и занимал 15 Гб. Оказалась, что в типовом регистре "История обменов данными" были записи за 3 года.
3) Одна большая таблица с малым числом записей, но большим объемом занятого места.
Если в базе хранятся файлы, то это "нормально".
Я сталкивался с двумя проблемами:
1) Регистр сведений хранил структурированные данные (большие таблицы значений) в хранилище значений без сжатия. После добавления параметра "Новый СжатиеДанных(9)" и сжатия данных по всем строкам, размер регистра уменьшился в 100 раз, уменьшив базу на 75%.
2) В типовой ЗУП 2.5 XML выгрузки регламентированной отчетности хранятся в строковом виде. На 1000 выгрузок получилось около 20 Гб, заняв при этом 50% базы. При этом обращений в запросах к этим строкам всего несколько, т.е. вполне можно изменить логику и хранить данные в Хранилищах значений в сжатом виде, существенно уменьшив размер базы.
4) Большое число записей в таблицах регистрации изменений.
Как видно на картинке - в базе под 100 миллионов записей в таблицах регистрации изменений.
Это таблицы не будут показаны вверху отчета, т.к. их размеры достаточно скромные.
А вот негативный эффект может быть существенным - замедление обменов данных, блокировки..
Причины две:
1) Либо обмен не проводится давно с каким-то узлом.
2) Либо в планах обмена с данными регистрами есть неиспользуемые узлы. Пользователи их часто помечают на удаление и оставляют в таком виде, но регистрацию изменений это не останавливает. Ненужные узлы планов обмена всегда надо удалять!
Буду признателен за комментарии с дополнениями и собственным опытом.
