Отчет по размерам таблиц в базе данных как одно из средств анализа проблем
Зачастую, когда пользователи обращаются с жалобами на производительность, бывает полезно посмотреть на отчет по размерам таблиц базы данных.
Он может отчетливо показать ряд распространенных проблем, устранение которых даст существенный эффект.
Приведенная информация вряд ли покажется чем-то новым для опытных специалистов.
- Описание
- Подробнее
Описание
Посмотрим только с позиции размеров таблиц базы данных (количество записей и объем занимаемого места).
В общем случае, чем база меньше — тем лучше.
Избыточно большие базы данных приводят к дополнительным затратам ресурсов:
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) Либо в планах обмена с данными регистрами есть неиспользуемые узлы. Пользователи их часто помечают на удаление и оставляют в таком виде, но регистрацию изменений это не останавливает. Ненужные узлы планов обмена всегда надо удалять!
Буду признателен за комментарии с дополнениями и собственным опытом.
