Он может отчетливо показать ряд распространенных проблем, устранение которых даст существенный эффект.
Приведенная информация вряд ли покажется чем-то новым для опытных специалистов.
Посмотрим только с позиции размеров таблиц базы данных (количество записей и объем занимаемого места).
В общем случае, чем база меньше — тем лучше.
Избыточно большие базы данных приводят к дополнительным затратам ресурсов:
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) Либо в планах обмена с данными регистрами есть неиспользуемые узлы. Пользователи их часто помечают на удаление и оставляют в таком виде, но регистрацию изменений это не останавливает. Ненужные узлы планов обмена всегда надо удалять!
Буду признателен за комментарии с дополнениями и собственным опытом.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Был бы к месту скрипт, указывающий на проблемные места.
(1) webester, +1. А ещё обработка, в которой по имени таблицы можно определить конкретный объект метаданных. А то получается, что у новичков остаются вопросы, а профи и так всё это знают.
По большому счету, разве перечисленное тут является криминалом!? Ну есть огромная история версий объектов и что с того, если я не обращаюсь к ней, к этой истории? Например, в Документообороте у меня хранятся *.pdf файлы (счета, переписка с важными клиентами и т.п. ) и никак Вы их не сожмете.
Вся оптимизация, в итоге по сути, сводится только к работе с таблицами РН и РБ! Индексы, статистика, итоги и т.п.
ИМХО, уж на размер таблиц нужно смотреть если не в последнюю, то в предпоследнюю очередь.
(3) DoctorRoza,
Как раз таки, «криминалом» являются
1 скрин — «тормозит все». Большинство типов документов проводятся медленно.
2 скрин — блокировки при работе с таблицей. Влияет на всю систему.
3 скрин — большие файлы обмена, загружающиеся очень долго
4 скрин — блокировки на обменах данными.
И вы совершенно правы к чему сводится вся оптимизация. Но, видимо, не все это понимают.
(3) DoctorRoza, не скажите, для меня было сюрпризом, что итоги регистра ЗаказыПокупателей занимают в несколько раз больше места, чем движения. Причём итоги там, по большому счёту, не нужны, потому что по каждому заказу-номенклатуре обычно две записи (первую делает заказ, вторую — реализация) и проще их выбрать из движений и сложить, чем искать ближайший итог и суммировать его с суммой (тут по-любому) движений. Итого: отрубаем итоги по этому регистру и получаем уменьшившуюся (в моём случае — на несколько гигов) базу, которая ещё и быстрее работает.
А отчёт, конечно, лучше делать вот этой штукой:
По п.2 самая большая таблица это ТЧ справочника а не р/с, т.е. это не ВерсииОбъектов. Интересно что.
Не закрываемые итоги по регистру сведений это критическая ошибка в еще с 7-ки, такое нужно править в первую очередь.
(1) webester, Это стандартный отчет MSSQL Management Studio — Disk usage by top tables (на скрине)
Стандартные отчеты куцые очень. Проще скачать у или . И там, и там всё разжёвано на английском. Для беглого анализа удобнее Гленн. Для встраивания в куда попало — Брент.
а где сам отчет скачать можно?
(6)
может, все же, — по регистру накопления или бухгалтерии? Часто устраняется перепроведением документов (восстановление последовательности). К сожалению бухгалтеры это обычно не делают. И по счетам взаиморасчетов, учета ТМЦ (особенно когда ведется партионный учет ФИФО/ЛИФО). А уж если не помогает, то это не ошибка, а конкретный косяк и возможно самих разработчиков.
В базе включено версионирование всех объектов метаданных, а история не очищалась. В итоге за 2-3 года база выросла до 350Гб, при этом 60% просто хлам, который никому особо не нужен.
Еще один пример — регистр сведений был самой большой таблицей в базе и занимал 15 Гб. Оказалась, что в типовом регистре «История обменов данными» были записи за 3 года.
Как видно на картинке — в базе под 100 миллионов записей в таблицах регистрации изменений.
знакомо до боли прямо. Самое забавное было с историей обменов, когда база крутилась на старом SQL Express с ограничением в 4 гига. Каждый месяц история прибавляла в весе 200 МБ и раз в три месяца база падала >_<
О том, что «История обменов данными» разрастается нужно сообщить программистам 1С. Они, видимо, не в курсе, что он у них никак не очищается. Могли бы регламентное задание какое-нибудь для очистки сделать в типовой конфигурации 1С:Розница.
(11) cheburashka,
ага, мы у себя в Рознице вставили чистку регистра от старых записей перед каждым обменом.
(12) baton_pk, тоже сделал у себя, только оставляю историю за небольшой период. На всякий случай.
тут удобнее
(14) согласен, с доступом из 1С в БД можно более читабельные отчеты формировать.