1c Dba

---
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.