Отчет по размерам таблиц в базе данных как одно из средств анализа проблем

Посмотрим только с позиции размеров таблиц базы данных (количество записей и объем занимаемого места).
В общем случае, чем база меньше - тем лучше.
Избыточно большие базы данных приводят к дополнительным затратам ресурсов:

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) Либо в планах обмена с данными регистрами есть неиспользуемые узлы. Пользователи их часто помечают на удаление и оставляют в таком виде, но регистрацию изменений это не останавливает. Ненужные узлы планов обмена всегда надо удалять!

 

Буду признателен за комментарии с дополнениями и собственным опытом.

 

Полная версия

© ООО "Инфостарт", 2006-2023 www.infostart.ru