1С 8.1 на SQL Server 2005: перевели 80 пользователей с файлового режима и получили 10x к скорости

Клиент - производственная компания, бухгалтерия плюс оперативный учёт, около 80 активных пользователей 1С. База жила в файловом режиме на сетевой шаре уже пару лет, и какое-то время это даже работало. Потом перестало.

Симптомы были классические: проведение накладной на 20 позиций занимало 35-40 секунд, в конце дня когда все одновременно закрывали смену - могло и подвиснуть насовсем. Бухгалтера ругались, директор ругался, ИТ-отдел клиента пожимал плечами и звонил нам.

Почему файловый режим кончается именно так

Файловая база 1С - это по сути один большой файл на сетевом диске, к которому клиенты обращаются напрямую через SMB. При 5-10 пользователях это терпимо. При 80 - блокировки на уровне файла, конкуренция за сетевой ресурс, и никакого способа оптимизировать запросы. Масштабироваться некуда.

Клиент-серверный режим - это другая архитектура: 1С-сервер (кластер приложений) принимает соединения от клиентов и сам ходит в СУБД. SQL Server видит нормальные транзакции, умеет их оптимизировать, строить планы запросов, держать индексы. Файловый режим ничего этого не умеет по определению.

Что делали

Работы было три больших блока.

Первое - миграция базы. 1С умеет выгружать базу в dt-файл и загружать обратно уже в клиент-серверную конфигурацию. Звучит просто, на практике - несколько часов на базе приличного размера плюс обязательная проверка целостности до и после. Делали в выходной, чтобы пользователи не висели в воздухе в момент переключения. Параллельно подняли сервер 1С 8.1 на отдельной машине, развернули SQL Server 2005 SP2, создали базу через консоль кластера.

Второе - индексы. Это заняло больше всего времени и принесло основной эффект. У 1С 8.1 есть встроенный механизм создания индексов, но он не всегда угадывает что нужно конкретному клиенту с конкретным набором документов. Мы включили SQL Server Profiler, погоняли типичные операции - проведение накладной, формирование оборотки, закрытие месяца - и посмотрели на планы запросов. Несколько таблиц регистров накопления сканировались полностью при каждом обращении. Добавили недостающие индексы вручную - аккуратно, чтобы не мешать штатным механизмам 1С.

Один нюанс: индексы в базе 1С лучше не называть в нотации самой 1С - при реструктуризации конфигурации платформа может их затереть. Держим отдельный скрипт, который накатывается заново после обновления.

Третье - регламентные задания через SQL Agent. Файловая база не знала что такое обслуживание индексов - там вообще понятия такого нет. SQL Server знает, но сам по умолчанию ничего не делает. Настроили три задания:

• Перестройка и дефрагментация индексов - ночью, каждую неделю. После интенсивного проведения документов фрагментация нарастает быстро.
• Обновление статистики - каждую ночь. Без актуальной статистики оптимизатор строит кривые планы.
• Бэкап - полный раз в сутки, дифференциальный каждые два часа, журнал транзакций каждые 30 минут. Модель восстановления Full - файловая база такого не умела, теперь есть point-in-time recovery.

Что получили

Проведение типовой накладной - 3-4 секунды против прежних 35-40. Закрытие смены перестало быть ритуалом с молитвой. Формирование оборотно-сальдовой ведомости за квартал ускорилось примерно вчетверо.

Параллельная работа 80 человек теперь не создаёт видимых проблем - SQL Server держит блокировки на уровне строк, а не файла, и умеет их разруливать. Несколько раз в первые недели ловили дедлоки - смотрели в трассировку, разбирались какие операции конфликтуют, слегка подкручивали порядок обращения к таблицам в регламентных обработках клиента.

Что не очевидно снаружи

Клиент-серверный режим 1С выглядит как «просто поменяли базу», а по факту это смена платформы хранения со всеми вытекающими. SQL Server требует ухода: мониторинга места на диске, контроля роста журнала транзакций, проверки что регламентные задания действительно выполняются а не падают молча. Мы это берём на себя в рамках сопровождения инфраструктуры - иначе через полгода клиент снова придёт с «база стала медленнее».

Ещё один момент: памяти SQL Server нужно давать с умом. По умолчанию он забирает всё что есть, и если на том же сервере крутится 1С-сервер приложений - они начнут конкурировать. Выставили max server memory вручную, оставив сколько нужно процессу 1С-сервера.

В целом перевод с файлового на клиент-серверный режим - это не разовая акция, это переход на нормальную СУБД с нормальными инструментами. Профилировщик, планы запросов, статистика ожиданий - всё это теперь доступно и даёт понять что происходит внутри, а не гадать почему медленно.