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