Тормозит вогбит

Здравствуйте!

Чтобы база данных работала без потери производительности, её необходимо периодически обслуживать.

1. Выполнять пересчёт статистики. Если один человек работает и не интенсивно, то можно и раз в несколько недель или даже реже. Если работа с базой интенсивная, то можно хоть каждый день.

2. Очищать рабочую базу данных от устаревшей подробной истории всех действий пользователей (чистить "сеансы"). Это при интенсивной работе хорошо бы делать несколько раз в год хотя бы.

3. Очищать рабочую базу данных от устаревшей подробной информации о ходе производства (удалять задания по старым заказам, чистить расписание старое). Это раз в год хорошо бы делать при интенсивной работе.

Перед пп.2 и 3, естественно, в обязательном порядке делать резервную копию базы данных. Это вообще настоятельно рекомендуется делать регулярно. Каждый день можно, если реально программа для управления производством используется.

После массового удаления чего-либо (пп.2,3) нужно обязательно проводить в определённой последовательности определённые регламентные действия с базой (иначе резко (вплоть до нуля) снизится эффект от этого удаления):
- почистить базу от информации связанной с логом массового удаления;
далее на SQL сервере:
- выполнить процедуру пересчёта зависимостей;
- выполнить сжатие базы;
- выполнить пересчёт статистики.

Если все эти действия по обслуживанию базы выполнять, то как показывает опыт, можно годами (пока статистика есть за 5 лет примерно) очень интенсивно работать, и производительность особо не падает.
Если обслуживанием базы не заниматься, то постепенно размер её будет увеличиваться, и увеличиваться, а производительность падать, и падать. Всё больше и больше...
Теоретически, можно, конечно, всё решить наращиванием мощностей сервера, но зачем? Достаточно просто поддерживать базу в "здоровом" состоянии.

Разница может быть очень большой.
Пример из реальной жизни:
Недавно "чистили" с клиентом одну "замусоренную" за пару лет интенсивной работы базу. Причём п.1 и 2 регулярно выполнялись. п.3 - нет.
В качестве SQL сервера для измерений использовали мой слабенький компьютер 8-ми летней давности с 6GB RAM. Разница во времени отклика при выполнении некоторых функций до и после "чистки" базы: было - 5-7мин, стало - около 1 сек*.

Это, как раз, косвенное свидетельство. Возможно, дело было так:
Базу долго не обслуживали. За счёт хранения всей истории за всё время, огромных разросшихся логов, "дефрагментации" и т.п. она постепенно разрослась до пределов в разы (или на порядок) больше разумных. Серверу при работе с этой базой тупо не хватает физической памяти. Он начинает использовать диск вместо RAM. Результат - ОС на сервере начинает отчаянно крутить HDD, всё начинает дико тормозить.
Рецепт спасения выше.


*Не ко всем действиям, безусловно, относится. Есть некоторые не очень быстрые сами по себе по определению. Например, создание заданий.

P.S.
На форуме, если поискать, по разным темам разбросано множество обсуждений и советов на эту тему. Тут я просто всё собрал в одном месте.

https://vogbit.ru/forum/forum15/topic799/

я так понимаю большинство пунктов рассмотрено в этой теме, я только не понял как статистику пересчитать, вот это оно?


А вот этот параметр подходит(автообновление статистики)? или это лучше делать вручную?




И еще хотелось бы понимать как сделать перерасчет зависимостей

P.S.
Если реально используете программу в производстве, то очень заметный (в разы) прирост производительности даёт чистка ненужной подробной истории по старым заказам (удаление заданий по старым заказам из рабочей БД - п.3). Особенно, если используется "высокий" или "максимальный" уровень учёта.

Нужно вот это только учитывать в данном случае.

У которых в колонке "Время выхода" пусто.
выделите, чтобы не было среди выделенных ни одного, у которого "время выхода" пусто. И будет активна.

10 минут, конечно, многовато...
Но так, в целом, нормально, что небыстро удаляются. Тем более, что, я так понимаю, до этого момента вообще никто не чистил сеансы не разу.

Скорость удаления ещё зависит и от количества событий за время сеанса. Если вы что-то удаляли массово перед этим, то эти последние сеансы - десятки тысяч событий могут быть. А они, как раз, наверное, первые среди выделенных были.

Дальше быстрее пойдёт

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