Нуждаются ли базы 1С Предприятия на СУБД PostgreSQL в обслуживании ?
Конечно!
Особенно базы «среднего» и «большого» размера, с которыми интенсивно работают пользователи в 1С.
В этой статье мы подробно разберем этот вопрос, и дадим конкретный ответ на него!
Хорошо, что весь процесс по обслуживанию баз 1С на PostgreSQL, можно выполнять с помощью утилиты pgAdmin 4.
Используя утилиту, мы экономим много времени, новички не «парятся» командами, передачей нужных параметров, ничего не пишут «руками» в консоли.
Конечно, данная тема также подымается и на курсе: Администратор 1С!
pgAdmin 4 существенно упрощает этот процесс!
(К слову вот первая и вторая часть статьи).
Где искать инструменты по обслуживанию баз данных в pgAdmin 4 ?
Открываем консоль и правый клик мышкой по той базе которую мы хотим «Обслужить» — «Обслуживание…»
Перед нами откроется окно в котором нам доступны различные настройки по обслуживанию базы данных.
Вверху мы видим «Операции» по обслуживанию, а ниже переключатели (они же параметры) по очистке.
«Операции по обслуживанию» — VACUUM, ANALYZE, REINDEX, CLUSTER соответствуют командам и приложениям которые физически можно найти в папке Bin (Там где установили PostgreSQL).
pgAdmin 4, как и в случаи с резервным копированием и восстановлением баз, также лишь запускает эти команды на выполнение с нужными параметрами. (другими словами, упрощает новичку процессы по обслуживанию баз данных).
Но прежде, чем мы подробно разберем все эти инструменты по обслуживанию баз в pgAdmin 4, стоит дать ответ на такой вопрос:
«Зачем заниматься обслуживанием баз 1С на PostgreSQL?»
Если взять среднюю базу 1С в ~30 Гб которая работает на сервере PostgreSQL и посмотреть так сказать на нее из «внутри», то мы увидим многие избыточные записи их еще называю «мусорные».
Откуда они берутся и что это за записи?
1. «Мусор»
Дело в том, что PostgreSQL самостоятельно не блокирует при изменении данных таблицы и записи от читающих транзакций, этим занимается сам сервер 1С «Кластер серверов».
Вместо этого создаётся копия изменяемой записи, которая становится видна последующим транзакциям, действующие же продолжают видеть данные, актуальные на начало своей транзакции. И в результате, в таблицах скапливаются устаревшие данные — предыдущие версии измененных записей.
Эти записи лишь «мусор», который скапливается в базе и зря расходует дисковое пространство.
На больших базах, с которыми интенсивно работают пользователи (где много транзакций) это хорошо заметно, базы «распухают» и падает производительность.
Как от него избавится ?
Здесь нам поможет операция VACUUM!
VACUUM способна эффективно очистить базы от всего лишнего!
Простая операция VACUUM (без параметра FULL)
только высвобождает пространство (как на картинке выше) и делает его доступным для повторного использования. Эта форма команды может работать параллельно с обычными операциями чтения и записи таблицы, так как она не требует исключительной блокировки.
Другими словами если мы используем лишь команду VACUUM (без параметра FULL) пользователи могут продолжать работать в 1С, а если используем параметр VACUUM + FULL, тогда выполняем ее, когда в базе 1С пользователи не работают. (Очень рекомендую делать именно так!).
Если мы говорим с Вами об обслуживании баз 1С Предприятия.
Тогда в приоритете будет использование команды VACUUM + FULL!
Иначе если использовать просто команду VACUUM освобождённое место не возвращается операционной системе (в большинстве случаев так и происходит).
Оно просто остаётся доступным для размещения данных этой же таблицы.
VACUUM + FULL переписывает всё содержимое таблицы в новый файл на диске, не содержащий ничего лишнего, что позволяет возвратить неиспользованное пространство операционной системе. Эта форма работает намного медленнее и запрашивает исключительную блокировку для каждой обрабатываемой таблицы.
А вот еще несколько причин, по которым мы должны использовать VACUUM:
- Для высвобождения или повторного использования дискового пространства, занятого изменёнными или удалёнными строками.
- Для обновления статистики по данным, используемой планировщиком запросов PostgreSQL.
- Для обновления карты видимости, которая ускоряет сканирование только индекса.
- Для предотвращения потери очень старых данных из-за зацикливания идентификаторов транзакций или мультитранзакций.
Можно с уверенность сказать, что основная команда, которая позволяет улучшить производительность 1С в PostgreSQL это VACUUM + FULL!
2. «Планировщик запросов»
На СУБД PostgreSQL как впрочем, и в MS SQL, есть такая вещь (механизм) как «Планировщик запросов» (или «оптимизатор» как его еще называют), именно он занимается выбором плана для наиболее быстрого выполнения SQL запроса.
Какими данными руководствуется «Планировщик запросов» ?
«Планировщик запросов» для этих целей использует информацию о распределении данных в таблицах и уже на основе этой информации строит наиболее оптимальный план выполнения SQL запроса.
Вот этому «Планировщику» мы и должны помогать!
Чтоб он смог строить оптимальные планы запросов, информация в таблицах наших баз данных должна быть актуальной то-есть обновленной!
И здесь нам на помощь приходит команда ANALYZE
ANALYZE также стоит выполнять вместе с VACUUM + ANALYZE! (Если мы говорим о базе 1С).
Выполнив ее, мы тем самим обновим информацию о распределении данных в таблицах.
Чем собственно и поможем «Планировщику запросов» строить свои оптимальные «Планы выполнения SQL запросов».
Иногда меня спрашивают, что же такое этот «План выполнения SQL запроса» ?
План выполнения SQL запроса — это такая последовательность применения операторов реляционной алгебре к исходным и промежуточным отношениям, которое для конкретного текущего состояния БД (её структуры и наполнения) может быть выполнено с минимальным использованием вычислительных ресурсов.
3. «Порча индекса или постоянное увеличение его в размерах»
Довольно часто в базах 1С «портятся» индексы или увеличиваются в размерах.
Операция REINDEX используется для перестройки существующих индексов.
Реиндексация — переразмещает и переназначает номера записей, тем самым удаляя некоторый мусор который остаётся в файле, (но уже не нужен базе), упорядочивает, удаляет ошибки.
Почему «распухает» индексная таблица ?
Индекс, он как таблица, содержит блоки со старыми версиями записей. PostgreSQL не всегда может заново использовать эти блоки, и поэтому файл с индексом постепенно увеличивается в размерах. Если данные в таблице часто меняются, то вырасти он может очень быстро.
Следует учитывать, что команда REINDEX, как и VACUUM+FULL, полностью блокирует таблицу, поэтому выполнять её надо только тогда, когда в базе 1С никто не работает.
4. Бэкап и восстановление.
Начинающие администраторы 1С считают что «бэкап» созданный консолью pgAdmin 4 делает лишь копию базы и все.
Конечно это не так!
Выполняя резервное копирование и восстановление баз данных 1С средствами pgAdmin 4.
Вы тем самым делаете одну из самых важных операций, по обслуживанию баз данных на СУБД PostgreSQL!
Что происходит во время создания и восстановления «бэкапа» средствами СУБД ?
Создание резервной копии базы средствами PostgreSQL (выгрузка в dump)- скидывает все записи и структуры базы в файл, оставляет только самое нужное без «мусора».
Восстановление из бэкапа средствами (СУБД) restore — создаёт новый чистый файл базы и аккуратно по порядку укладывает все записи одновременно нумеруя их, соответственно без пустых пространств.
В итоге:
- Dump и Restore занимает меньше времени чем операции VACUUM и REINDEX!
- Делает дело качественнее, ускорение работы ощутимее (даже по сравнению с VACUUM!).
- Иногда значительно сокращает размер самой базы за счёт аккуратной укладки.
К сожалению, при помощи pgAdmin 4 нельзя автоматизировать весь этот процесс по обслуживанию баз.
И новичкам для выполнения любой операции по обслуживанию баз данных, нужно запускать, вручную «операцию» отметив соответствующий «чекбокс» в pgAdmin 4 .
Специалистам нужно использовать либо “cron” или планировщик Windows, использовать набор команд и параметров, писать скрипт, создавать «батники».
Когда и какую операцию выполнять ?
Для примера: На средних базах ~30 гб и 100 пользователей.
Делаем:
- ANALYZE (БЕЗ VACUUM!) — каждый день (Например, утром, еще до начала работы пользователей в 1С).
- DUMP (Резервное копирование) – исчисляется в зависимости от того сколько времени работы в 1С Вы не можете позволить себе потерять.
- REINDEX – Делаем раз в неделю для профилактики (Не обязательно, если индексы не «распухают» и делаете часто Dump / Restore).
- VACUUM + FULL + ANALYZE – Раз в неделю (лучше всего делать в конце рабочей недели например: пятница).
Так выполняя эти простые действия по обслуживанию баз данных в PostgreSQL, Вы обеспечите стабильную работу пользователей в 1С, улучшите производительность и исключите возможные ошибки.
P.S. (CLUSTER и FREEZE для администрирования баз данных 1С, использовать не стоит).
Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>
Здравствуйте, отличный цикл статей, спасибо!
Хотелось бы статью о настройках быстродействия, так как настройки от 1С помогли улучшить ситуацию, но со временем, опять стали наблюдаться тормоза у пользователей.
А еще, как заставить PG кушать оперативную память, отдельные процессы еле дотягивают до 150 мб, а в общем не больше 1000 мб и это при 100 пользователях?