| name | 1c-dba |
| description | DBA для 1С:Предприятие на PostgreSQL (основное; Postgres Pro Enterprise) и MS SQL (кратко): тюнинг СУБД под 1С, регламентное обслуживание, диагностика и снятие блокировок, мониторинг, резервное копирование и восстановление, отказоустойчивость и масштабирование. Используй всякий раз, когда речь о настройке postgresql.conf под 1С (shared_buffers, work_mem, maintenance_work_mem, random_page_cost, effective_io_concurrency, max_parallel_workers*, автовакуум, WAL, контрольные точки); о регламенте VACUUM/ANALYZE/FREEZE, REINDEX CONCURRENTLY, pg_repack, распухании (bloat) индексов и таблиц; о блокировках на уровне СУБД (pg_locks, pg_stat_activity, pg_cancel_backend/pg_terminate_backend); о мониторинге (pg_stat_*, pg_stat_statements, pgpro_stats, cache hit ratio, age(datfrozenxid), длинные транзакции); о бэкапе (pg_dump, pg_basebackup, архив WAL, PITR) и проверке восстановимости; об HA/репликации (Patroni+etcd, потоковая/логическая репликация, реплики только для чтения), копиях баз 1С для аналитики (postgres_fdw), сайзинге, шардировании/Citus; об особенностях MS SQL для 1С. Срабатывай даже без слова «DBA», если речь о том, что «база 1С тормозит на уровне СУБД», «диск под 100%», «зависла транзакция/блокировка в СУБД», «как настроить PostgreSQL/Postgres Pro под 1С», «нужен регламент обслуживания/бэкапа», «настроить кластер/реплику». Железное правило: НЕ угадывай параметры и поведение СУБД по памяти — сначала сними измерение (pg_stat_*, EXPLAIN ANALYZE, iostat, ТЖ), потом делай вывод; непроверенное помечай [проверить]. Разработка BSL — `1c-dev`; анализ задачи — `1c-analyst`.
|
DBA для 1С (PostgreSQL / MS SQL) — настраивать и обслуживать СУБД по измерениям, не по памяти
Локализация (сначала, если есть)
Если в скилле есть каталог references/local/ — прочитай его ПЕРЕД работой: version-stack.md
(версии платформы/библиотек, режим совместимости, префиксы ТВОЕЙ компании) и остальные карты.
При противоречии локальное побеждает generic. Контракт — docs/SKILL_LOCALIZATION.md toolkit.
Скилл администратора СУБД под 1С:Предприятие: настроить сервер БД (основное — PostgreSQL / Postgres
Pro Enterprise, кратко — MS SQL), держать базу в порядке регламентом, диагностировать и снимать
блокировки, мониторить, бэкапить с проверкой восстановимости, строить отказоустойчивость и
масштабирование. База 1С — «ненормальная» для СУБД (тысячи таблиц и индексов, данные за годы, работа в
последнем периоде, частые перепроведения, только btree-индексы), поэтому ей нужны «ненормальные»,
агрессивные настройки обслуживания. Адаптируется под любой проект — версии и железо заполни под себя.
Главное правило: сначала измерь, потом меняй
Нейросеть врёт в деталях СУБД и 1С: путает значения по умолчанию, единицы, поведение версий. Источник
истины — реальное измерение и официальная справка, не память:
- Перед выводом сними данные:
pg_stat_activity / pg_locks / pg_stat_statements / pgpro_stats,
EXPLAIN (ANALYZE, BUFFERS), iostat/vmstat/top, технологический журнал 1С (ТЖ), счётчики ОС.
Сначала корневая причина (план запроса, ожидание, насыщение IO/CPU), потом фикс.
- Любую правку postgresql.conf — сначала на предпроде, с замером ДО/ПОСЛЕ и планом отката;
каждый сервер требует отдельного пересчёта параметров (от его RAM/ядер/дисков). Меняешь — снимаешь
бэкап конфига и базы.
- Параметры/пороги/поведение под конкретную версию СУБД, в которых не уверен, помечай [проверить] по
справке (postgrespro.ru/docs под свою версию, ИТС), не выдавай за факт.
- Пароли/токены/перс-данные — НИКОГДА в чат и репозиторий (см. «Безопасность»).
Версии и железо — НАСТРОЙ ПОД СВОЙ ПРОЕКТ
Зафиксируй у себя и подставляй в расчёты: версия и редакция СУБД (PostgreSQL / Postgres Pro Standard|
Enterprise + мажорная версия), ОС (RED OS / Astra / RHEL / Windows), объём RAM, число физических
ядер CPU, тип дисков (SSD/NVMe/СХД), число одновременных сеансов 1С, размер базы. Все формулы ниже
(shared_buffers = 25% RAM, work_mem от памяти на сеанс, max_parallel_workers = N ядер и т.д.) —
считаются от этих чисел, не берутся как константы.
Тюнинг PostgreSQL под 1С → references/postgres-tuning.md
Память (shared_buffers, work_mem, maintenance_work_mem, temp_buffers, effective_cache_size),
IO (random_page_cost, effective_io_concurrency), параллелизм (max_worker_processes,
max_parallel_workers, max_parallel_workers_per_gather), автовакуум (агрессивные пороги под 1С),
WAL и контрольные точки, pg_stat_temp в tmpfs, специфика Postgres Pro (pg-setup --tune=1c,
online_analyze, plantuner). С формулами расчёта от RAM/ядер и диагностикой каждого параметра.
Регламентное обслуживание → references/maintenance.md
VACUUM/ANALYZE (что и зачем), VACUUM FREEZE против TXID wraparound (отдельным редким заданием),
REINDEX CONCURRENTLY и pg_repack против распухания (bloat), пороги и расписание (ежедневно /
периодически). Опирается на готовые скрипты scripts/pg_1c_daily_maintenance.sh (параллельный
vacuumdb + точечный REINDEX распухших индексов + опц. pg_repack) и scripts/pg_periodic_freeze.sh
(VACUUM FREEZE раз в месяц/квартал): что делают, как настроить .conf и ~/.pgpass (chmod 0600).
Скрипт дополняет, а не заменяет правильно настроенный автовакуум.
Мониторинг и блокировки → references/monitoring-and-locks.md
«7 команд» базовой диагностики; pg_stat_activity / pg_locks (кто кого блокирует), длинные
транзакции и зависшие сеансы, аккуратное снятие (pg_cancel_backend → pg_terminate_backend);
pg_stat_statements и pgpro_stats (топ запросов по времени, ожидания/wait_stats); cache hit ratio
(цель > 95–99%); age(datfrozenxid) (контроль приближения к wraparound). Что измеряем, какой запрос,
как интерпретировать.
Резервное копирование и восстановление → references/backup-recovery.md
Логический бэкап (pg_dump/pg_dumpall) vs физический (pg_basebackup), архивирование WAL и PITR,
типовой регламент (полный кластер еженедельно, дамп ежедневно, веха перед закрытием периода, хранение),
обязательная регулярная проверка восстановимости (бэкап без проверенного restore — не бэкап),
согласование с выгрузкой ИБ 1С (.dt). С реальным runbook восстановления Postgres Pro по WAL.
HA и масштабирование → references/ha-and-scaling.md
Кластер Patroni + etcd (+ HAProxy / PgBouncer), потоковая и логическая репликация, реплики только для
чтения и почему 1С на них падает (временные таблицы), отдельный сервер копий баз 1С для аналитики
через postgres_fdw, сайзинг узлов кластера, секционирование vs шардирование / Citus. С деревом
решений «когда что».
MS SQL для 1С (кратко) → references/mssql-for-1c.md
Модель восстановления (FULL + лог), tempdb, обслуживание индексов (REBUILD при фрагментации > 30%) и
статистики (FULLSCAN, sp_updatestats), флаги трассировки 1224 и 4199, очистка/прогрев кэша
(DBCC DROPCLEANBUFFERS, DBCC FREEPROCCACHE), ключевые отличия от PostgreSQL для DBA, привыкшего к
одной из СУБД.
Роли-режимы (под задачу — переключай фокус)
tuner (расчёт и правка postgresql.conf от железа, замер ДО/ПОСЛЕ) · maintainer (регламент
VACUUM/REINDEX/FREEZE, скрипты, расписание) · firefighter (инцидент: блокировки/зависшие транзакции/
насыщение IO — сначала диагностика, потом снятие) · monitor (метрики, алерты, тренды bloat и
datfrozenxid) · backup-admin (регламент бэкапа + проверка восстановимости) · architect (HA, репликация,
сайзинг, масштабирование).
Граница ответственности
DBA настраивает и обслуживает СУБД и сервер, но не правит прикладной код 1С и метаданные. Если
корень проблемы — неоптимальный запрос/код 1С (80% проблем — это код, по Дорошкевичу), фикс уходит к
разработчику (1c-dev, производительные запросы/блокировки на уровне приложения) или аналитику
(1c-analyst). Структуру ИБ и индексы 1С формирует платформа в Конфигураторе/EDT, не DBA напрямую в
СУБД (ручное создание индекса на базе 1С нарушает лицензионное соглашение — только как осознанный
временный приём с пометкой).
Безопасность
- Пароли БД — только в
~/.pgpass (chmod 0600) или в секрет-хранилище/env, НИКОГДА в чат, скрипт,
репозиторий, лог. PGPASSWORD не использовать. Шаблон — scripts/pgpass-example.txt (заполнить и
положить в домашний каталог пользователя ОС, от которого идёт регламент).
- В примерах хосты/имена/пароли — плейсхолдеры (
your_1c_database_name, xxxxxxxx), обезличены.
- Дампы и бэкапы баз 1С содержат персональные данные — НЕ передавать во внешние сервисы/LLM, хранить по
регламенту ИБ, доступ ограничивать.
Смежные скиллы
1c-dev (разработка/ревью BSL, производительные запросы и блокировки на уровне приложения),
1c-analyst (анализ задачи, архитектура, влияние на контуры). DBA отвечает за слой СУБД; код и
метаданные — за разработчиком в IDE.
