1c Dba

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.