Обслуживание базы 1С: из чего оно состоит
Обслуживание базы 1С идёт на двух уровнях, и путать их не стоит. Первый уровень - сама 1С: регламентные задания конфигурации, удаление помеченных объектов, тестирование и исправление информационной базы (оно требует монопольного режима, поэтому живёт в отдельном окне). Второй уровень - СУБД под базой: резервные копии, индексы, статистика, проверка целостности и журнал транзакций. На клиент-серверной базе основная работа приходится на второй уровень, и именно его обычно никто не настраивал: мастер планов прощёлкан по умолчанию, а восстановление из бэкапа ни разу не пробовали. Мы начинаем с аудита обоих уровней и составляем регламент под нагрузку и ночное окно конкретной базы, а не по общему шаблону.
Что входит в план обслуживания SQL для 1С
Типовой “мастер планов обслуживания”, прощёлканный по умолчанию, для боевой базы 1С не годится: он либо делает лишнее (полная перестройка всех индексов каждую ночь), либо не делает нужного (никто не проверяет восстановимость бэкапов). Рабочий регламент выглядит так:
- Резервное копирование - полные, разностные и журнальные копии по схеме, дающей нужную точку восстановления; хранение на отдельном хранилище; регулярное пробное восстановление. Хотя бы одна копия должна лежать там, куда не дотягивается сеть: после шифровальщика сетевые бэкапы оказываются зашифрованы вместе с базами.
- Индексы - дефрагментация или перестройка по фактической фрагментации, а не “всё подряд”; поиск отсутствующих и неиспользуемых индексов.
- Статистика - обновление с учётом массовых загрузок и закрытий периода, чтобы планы запросов не “слетали”.
- Проверка целостности - регулярная, на копии, чтобы не грузить продуктив.
- Журнал транзакций - правильная модель восстановления и контроль роста вместо бесконечного шринка.
Пробное восстановление удобно совместить с тестовой базой: задание по расписанию каждую ночь поднимает тест из свежего бэкапа рабочей, и восстановимость проверяется сама.
MS SQL и PostgreSQL
Исторически 1С в СНГ живёт на MS SQL, но всё больше компаний переходит на PostgreSQL - из-за лицензий и санкционных рисков. Мы обслуживаем оба варианта: для PostgreSQL это vacuum/autovacuum, bloat таблиц, контрольные точки и специфичные для 1С настройки. Помогаем и с самой миграцией MS SQL → PostgreSQL: перенос, настройка, сравнение производительности до/после. Что в базе сломается при переезде, заранее показывает проверка перед миграцией на PostgreSQL.
Обновление платформы
Смена версии платформы - отдельная работа со своей подготовкой: список изменений, требующих правок в конфигурации, копится от версии к версии, а объём работ определяется режимом совместимости, а не свежестью релиза конфигурации. Мы проверяем готовность базы до обновления, сверяем требования к версиям СУБД и операционных систем и прогоняем переход на копии. Что именно проверяется на переходе к 8.5, разобрано в статье “Переход на 1С 8.5: что проверить в конфигурации и на серверах”. Конфигурацию можно проверить и самим, ещё на текущей платформе: помощник перехода на 8.5 работает на 8.3.20 и старше и показывает, что в конфигурации изменится.
Кейсы: как это выглядит на живых базах
- Кассы тормозили из-за соседней базы - розничная сеть в трёх странах, общий SQL-сервер на несколько баз: проведение чека висело 20 минут, за пять дней разобрали параллелизм, статистику и зависшие транзакции.
- Сопровождение страховой компании - 400 часов и 46 работ за четыре месяца, от расхождения в учёте до выписки, которая вешала базу.
- Журнал регистрации в ClickHouse - журналы уехали с боевых серверов на отдельный, поиск ошибок за сутки занимает 0,11 секунды.
Разовая наладка или сопровождение
Можно разово: мы наводим порядок, ставим регламенты, отдаём документацию - дальше ваша команда справляется сама, регламенты под контролем мониторинга. Можно на сопровождении: мы следим за базами, реагируем на алерты и раз в месяц отчитываемся о состоянии. Выбираете вы; никакой искусственной привязки к нам не будет.
