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

Публикация № 380287

Администрирование - Администрирование данных 1С - Статистика базы данных

база данных размер оптимизация

53
Зачастую, когда пользователи обращаются с жалобами на производительность, бывает полезно посмотреть на отчет по размерам таблиц базы данных.
Он может отчетливо показать ряд распространенных проблем, устранение которых даст существенный эффект.
Приведенная информация вряд ли покажется чем-то новым для опытных специалистов.

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

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

 

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

 

53

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. webester 29 21.07.15 04:51 Сейчас в теме
Был бы к месту скрипт, указывающий на проблемные места.
Gr@nd@d; ffgnebel; yukon; ojiojiowka; +4 Ответить
2. ojiojiowka 21.07.15 08:00 Сейчас в теме
(1) webester, +1. А ещё обработка, в которой по имени таблицы можно определить конкретный объект метаданных. А то получается, что у новичков остаются вопросы, а профи и так всё это знают.
6. maddy 17 21.07.15 17:18 Сейчас в теме
По п.2 самая большая таблица это ТЧ справочника а не р/с, т.е. это не ВерсииОбъектов. Интересно что.

Не закрываемые итоги по регистру сведений это критическая ошибка в еще с 7-ки, такое нужно править в первую очередь.

(1) webester, Это стандартный отчет MSSQL Management Studio - Disk usage by top tables (на скрине)
9. lvictor58 129 22.07.15 15:09 Сейчас в теме
(6)
Не закрываемые итоги по регистру сведений


может, все же, - по регистру накопления или бухгалтерии? Часто устраняется перепроведением документов (восстановление последовательности). К сожалению бухгалтеры это обычно не делают. И по счетам взаиморасчетов, учета ТМЦ (особенно когда ведется партионный учет ФИФО/ЛИФО). А уж если не помогает, то это не ошибка, а конкретный косяк и возможно самих разработчиков.
3. DoctorRoza 21.07.15 08:56 Сейчас в теме
По большому счету, разве перечисленное тут является криминалом!? Ну есть огромная история версий объектов и что с того, если я не обращаюсь к ней, к этой истории? Например, в Документообороте у меня хранятся *.pdf файлы (счета, переписка с важными клиентами и т.п. ) и никак Вы их не сожмете.
Вся оптимизация, в итоге по сути, сводится только к работе с таблицами РН и РБ! Индексы, статистика, итоги и т.п.
ИМХО, уж на размер таблиц нужно смотреть если не в последнюю, то в предпоследнюю очередь.
4. Aleksey.Bochkov 3232 21.07.15 09:54 Сейчас в теме
(3) DoctorRoza,
Как раз таки, "криминалом" являются
1 скрин - "тормозит все". Большинство типов документов проводятся медленно.
2 скрин - блокировки при работе с таблицей. Влияет на всю систему.
3 скрин - большие файлы обмена, загружающиеся очень долго
4 скрин - блокировки на обменах данными.

И вы совершенно правы к чему сводится вся оптимизация. Но, видимо, не все это понимают.
5. vasyak319 132 21.07.15 10:16 Сейчас в теме
(3) DoctorRoza, не скажите, для меня было сюрпризом, что итоги регистра ЗаказыПокупателей занимают в несколько раз больше места, чем движения. Причём итоги там, по большому счёту, не нужны, потому что по каждому заказу-номенклатуре обычно две записи (первую делает заказ, вторую - реализация) и проще их выбрать из движений и сложить, чем искать ближайший итог и суммировать его с суммой (тут по-любому) движений. Итого: отрубаем итоги по этому регистру и получаем уменьшившуюся (в моём случае - на несколько гигов) базу, которая ещё и быстрее работает.
А отчёт, конечно, лучше делать вот этой штукой: http://infostart.ru/public/128362/
7. speshuric 1120 22.07.15 06:42 Сейчас в теме
Стандартные отчеты куцые очень. Проще скачать у Брента Озара или Гленна Берри. И там, и там всё разжёвано на английском. Для беглого анализа удобнее Гленн. Для встраивания в куда попало - Брент.
sashocq; ershz; AlX0id; Aleksey.Bochkov; +4 Ответить
8. rail21111991 22.07.15 13:28 Сейчас в теме
а где сам отчет скачать можно?
10. baton_pk 391 23.07.15 23:33 Сейчас в теме

В базе включено версионирование всех объектов метаданных, а история не очищалась. В итоге за 2-3 года база выросла до 350Гб, при этом 60% просто хлам, который никому особо не нужен.

Еще один пример - регистр сведений был самой большой таблицей в базе и занимал 15 Гб. Оказалась, что в типовом регистре "История обменов данными" были записи за 3 года.

Как видно на картинке - в базе под 100 миллионов записей в таблицах регистрации изменений.

знакомо до боли прямо. Самое забавное было с историей обменов, когда база крутилась на старом SQL Express с ограничением в 4 гига. Каждый месяц история прибавляла в весе 200 МБ и раз в три месяца база падала >_<
11. cheburashka 36 06.08.15 06:58 Сейчас в теме
О том, что "История обменов данными" разрастается нужно сообщить программистам 1С. Они, видимо, не в курсе, что он у них никак не очищается. Могли бы регламентное задание какое-нибудь для очистки сделать в типовой конфигурации 1С:Розница.
12. baton_pk 391 06.08.15 08:02 Сейчас в теме
(11) cheburashka,
ага, мы у себя в Рознице вставили чистку регистра от старых записей перед каждым обменом.
Светлый ум; +1 Ответить
13. cheburashka 36 06.08.15 12:41 Сейчас в теме
(12) baton_pk, тоже сделал у себя, только оставляю историю за небольшой период. На всякий случай.
14. Salexey 15.07.19 20:15 Сейчас в теме
15. Aleksey.Bochkov 3232 16.07.19 08:31 Сейчас в теме
(14) согласен, с доступом из 1С в БД можно более читабельные отчеты формировать.
Оставьте свое сообщение

См. также

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С 90

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Статистика базы данных Производительность и оптимизация (HighLoad)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    6864    ivanov660    5       

Одна из причин медленной работы табеля (ЗУП 2.5, клиент-сервер, MS SQL Server) 61

Статья Системный администратор Программист Нет файла v8 ЗУП2.5 Россия Учет рабочего времени Бесплатно (free) Практика программирования Статистика базы данных Производительность и оптимизация (HighLoad)

В форме типового документа "Табель учета рабочего времени" было обнаружено не совсем очевидное и довольно узкое место, заметно влияющее на скорость интерактивной работы с ячейками табеля.

19.01.2016    19673    KAPACEB.AA    16       

Для чего НЕ нужны индексы 191

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Статистика базы данных Практика программирования

Индекс лишним не бывает? Чем больше индексов, тем лучше? А не проиндексировать ли это измерение на всякий случай? Если подобные вопросы иногда возникают в вашей голове, то эту статью прочитать было бы весьма полезно.

16.01.2016    40354    comol    93       

Статистика использования дополнительных отчётов и обработок 33

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Статистика базы данных

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

30.06.2015    11490    vasyak319    13       

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL 28

Статья Системный администратор Нет файла v8 Бесплатно (free) Статистика базы данных Производительность и оптимизация (HighLoad)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    38450    madmpro    32       

APDEX и оценка производительности стандартными средствами 1С 22

Статья Системный администратор Программист Нет файла v8 1cv8.cf Windows Бесплатно (free) Статистика базы данных Производительность и оптимизация (HighLoad)

В этом видеокурсе на примере конфигурации «1С:Комплексная автоматизация 8» мы покажем, как стандартными средствами 1С можно выполнить оценку производительности работы программы по методике APDEX.

09.10.2012    25793    ИТ-Терминал    6       

Хранимая процедура + job для сбора статистики о размере SQL БД на сервере 8

Инструменты и обработки Системный администратор Программист Компонента, плагин (dll, vbs,..) v7.7 v8 1cv8.cf 1cv7.md Windows Бесплатно (free) Статистика базы данных

Если требуется узнать как изменяются размеры SQL БД с течением времени и как на них влияет shrink, то эта процедура может пригодится.

16.09.2010    11480    62    dgonson    5       

Количество справочников и документов в любой базе (1с:8.1) 25

Инструменты и обработки Системный администратор Внешняя обработка (ert,epf) v8 1cv8.cf Россия Бесплатно (free) Статистика базы данных

Обработка для быстрого контроля содержимого базы данных, позволяет анализировать сколько каких справочников и документов заполнено. Можно перейти в список двойным кликом по строке. Удобно использовать при первом знакомстве с новой базой, например у клиентов.

02.05.2010    13080    675    Economist    13       

[DesktopGadget1C] - Гаджет для мониторинга активности баз 1С 8.х в клиент/серверном варианте 40

Инструменты и обработки Системный администратор Приложение (exe) v8 1cv8.cf Россия Бесплатно (free) Сервисные утилиты Статистика базы данных Администрирование данных 1С

Утилита мониторит серверы 1С 8.1 и 8.2, выводит список активных баз и количество пользователей и позволяет просматривать параметры/настройки кластеров.

27.11.2009    15447    344    Душелов    34       

Статистика информационной базы 144

Инструменты и обработки Системный администратор Внешняя обработка (ert,epf) v8 1cv8.cf Россия Бесплатно (free) Статистика базы данных

Обработка считает количество записей в таблицах базы. Не привязана к конкретной конфигурации, работает под любой конфигурацией платформы 8.1.

07.05.2009    24962    1098    YVolohov    43       

Статистика по конфигурации 34

Инструменты и обработки Системный администратор Внешняя обработка (ert,epf) v8 1cv8.cf Россия Бесплатно (free) Статистика базы данных

Универсальный отчет отображающий статистическую информацию по конфигурации (документы и справочники).

01.04.2008    14205    379    coder1cv8    8       

Статистика ИБ 8.1 SQL 238

Инструменты и обработки Программист Внешний отчет (ert,erf) v8 1cv8.cf Россия Бесплатно (free) Статистика базы данных

Статистика ИБ 8.1 SQL Собирает информацию о всех объектах конфигурации. Количество записей, размер данных и индексов. Количество записей в документах и регистрах за период. Максимальное и среднее количество записей в документах и регистрах за один день. Количество записей в табличных частях документа на 1 документ.

29.08.2007    40812    3545    IronDemon    88       

Статистика по количеству данных в базе 22

Инструменты и обработки Системный администратор Внешняя обработка (ert,epf) v8 1cv8.cf Россия Windows Бесплатно (free) Статистика базы данных

Обновил. Время сборы статистики увеличено в ХХХ раз. Спасибо, anqro. Обработка показывается информацию о количестве данных в информационной базе: - количество документов за период по каждому виду документа и общее; - количество строк в документе по каждому виду документа и общее; - среднее количество строк в документе; - можно собрать статистику только по проведенным, по не помеченным на удаление, по всем.

23.10.2006    15042    360    z-alexey    28