15 пользователей, файловая база, утро понедельника — 1С открывается три минуты. Знакомо? Бухгалтерия пьёт кофе. Менеджеры переключаются на телефоны. Руководитель звонит айтишнику. Айтишник перезагружает сервер. Помогает на час.
Файловая база 1С — это один файл на общем сетевом диске. Она проста, как кувалда. И так же точна. Пока пользователей меньше пяти и база легче двух гигабайт, файловый режим работает нормально. Но бизнес растёт. И в какой-то момент файловая база перестаёт справляться. Не потому что она плохая — потому что она не для этого.
Файловый vs клиент-серверный: в чём разница
В файловом режиме вся база — один файл 1Cv8.1CD. Он лежит на сетевом диске или локально. Каждый клиент 1С обращается к этому файлу напрямую. Нужны данные — клиент читает файл. Нужно записать — блокирует часть файла, пишет, отпускает. Вся логика работы с данными выполняется на стороне клиента.
Когда клиент один — всё быстро. Когда их пять — терпимо. Когда десять — начинаются очереди на блокировки. Клиенты ждут друг друга. Файл по сети передаётся целыми страницами, даже если нужна одна строка.
Клиент-серверный режим устроен иначе. Между клиентом 1С и данными появляются два посредника: сервер 1С (кластер) и SQL Server. Клиент отправляет запрос серверу 1С. Сервер 1С формирует SQL-запрос и отправляет его SQL Server. SQL Server читает данные с диска, обрабатывает и возвращает результат. Клиент получает только нужные строки, а не страницы файла.
Разница принципиальная. SQL Server оптимизирован для параллельного доступа. Он держит данные в кэше оперативной памяти — горячие таблицы считываются с диска один раз, а потом отдаются из памяти. Он использует индексы — вместо полного сканирования таблицы находит нужные строки за миллисекунды. Он управляет блокировками на уровне строк, а не страниц. Два пользователя проводят разные документы — никто никого не ждёт. SQL Server создан для этой работы.
Когда файловый режим работает нормально: до 5 пользователей, база до 2 ГБ, все в одной локальной сети, нет тяжёлых отчётов, нет регламентных заданий в фоне. Если хотя бы одно условие нарушено — пора думать о переходе. Отдельно про регламентные задания: в файловом режиме они выполняются в одном из клиентских сеансов. Пока задание работает — оно блокирует те же ресурсы, что и обычный пользователь. В клиент-серверном режиме регламентные задания выполняются на сервере 1С, не мешая клиентам.
Пять сигналов, что пора переходить
Больше 10 пользователей. Это не жёсткий порог, а зона, где файловая база начинает задыхаться. Два менеджера одновременно проводят документы — один ждёт другого. Три бухгалтера формируют отчёты — файл по сети не успевает отдавать данные. 10 пользователей — граница, за которой файловый режим из «работает» превращается в «работает, но медленно».
База больше 4 ГБ. Файл 1Cv8.1CD растёт. С каждым месяцем документов больше. 4 ГБ — точка, после которой производительность падает нелинейно. Файловая СУБД 1С не умеет эффективно работать с большими объёмами. Нет полноценных индексов, нет кэширования в памяти, нет оптимизатора запросов. Всё это даёт SQL Server.
Блокировки и ошибки «данные были изменены или удалены». Пользователи видят это сообщение, когда два сеанса пытаются записать один и тот же объект. В файловом режиме блокировки грубые — на уровне таблицы или страницы. Один проводит документ — остальные ждут. В клиент-серверном режиме SQL Server блокирует отдельные строки. Конфликтов в разы меньше.
Отчёты формируются минутами. Оборотно-сальдовая ведомость за год — три минуты. Анализ продаж — пять минут. В файловом режиме каждый отчёт сканирует файл. Нет индексов — нет быстрого поиска. SQL Server формирует тот же отчёт за секунды, потому что использует индексы и план запроса. Об этом подробнее в статье 1С тормозит — и это не код, где мы разбираем инфраструктурные причины медленной работы.
Удалённые офисы. Если часть сотрудников работает не в основном офисе — файловый режим по VPN становится пыткой. Каждая операция гоняет данные по сети. Задержка 30 мс на каждый пакет. Открытие формы — десятки пакетов. В клиент-серверном режиме по сети передаются только результаты запросов, а не сырые страницы файла.
Пошаговый план миграции
Переход — не кнопка «сделать хорошо». Это проект на один-два дня, если всё спланировано, и на неделю мучений, если нет. Вот шесть шагов, по которым мы переводим базы клиентов.
Шаг 1. Подготовить сервер. Нужна машина (физическая или виртуальная) под SQL Server и сервер 1С. Минимальные требования для 10-20 пользователей: 4 ядра, 16 ГБ RAM, SSD от 100 ГБ. SQL Server Standard или PostgreSQL. Сервер 1С — лицензия на платформу с серверной частью. Если сервер и SQL будут на одной машине — закладывайте больше памяти.
Шаг 2. Установить и настроить SQL Server. Не оставляйте настройки по умолчанию. MAXDOP = 1, Cost Threshold for Parallelism = 50, tempdb — столько файлов, сколько ядер (до 8). Модель восстановления — Full, если нужна точка восстановления, или Simple для начала. Коллация — обязательно Cyrillic_General_CI_AS. Это критично. Мы видели базы, которые после миграции не могли правильно сортировать кириллицу, потому что при установке SQL Server оставили Latin1_General_CI_AS.
Шаг 3. Установить сервер 1С. Поставить платформу той же версии, что и на клиентах. Зарегистрировать кластер. Проверить, что служба запускается и порты открыты (по умолчанию 1541, 1560-1591). Создать пустую информационную базу в кластере — именно её мы будем наполнять данными.
Шаг 4. Выгрузить файловую базу. В конфигураторе: Администрирование — Выгрузить информационную базу. Получится файл .dt. Перед выгрузкой — выгнать всех пользователей, выполнить тестирование и исправление базы. Если база большая (больше 10 ГБ), выгрузка может занять час. Планируйте окно простоя.
Шаг 5. Загрузить в серверную базу. Открыть конфигуратор серверной базы. Администрирование — Загрузить информационную базу. Указать файл .dt. Загрузка создаст все таблицы в SQL Server и заполнит их данными. После загрузки — запустить обновление конфигурации базы данных, если конфигуратор предложит.
Шаг 6. Настроить клиентские подключения. На каждой рабочей станции изменить строку подключения: вместо пути к файловой базе указать сервер 1С и имя базы. Формат: Srvr="имя_сервера";Ref="имя_базы". Проверить работу каждого пользователя. Особое внимание — внешним обработкам и отчётам, печатным формам, обменам с банком. Обмен данными между базами (если есть) тоже нужно перенастроить: адреса информационных баз изменились.
Типичные ошибки при переходе
Неправильная коллация SQL Server. Устанавливают SQL Server с дефолтной коллацией Latin1_General_CI_AS. Для 1С нужна Cyrillic_General_CI_AS. Если ошиблись — придётся переустанавливать SQL Server целиком. Коллацию экземпляра нельзя изменить после установки. Не «сложно» — невозможно без переустановки.
SQL Server Express на production. Бесплатно — не значит бесплатно. Ограничение в 1 ГБ оперативной памяти для SQL Server Express означает, что при базе в 5 ГБ каждый запрос будет ходить на диск. 10 пользователей — и система медленнее файловой. Мы видели это трижды за последний год. Люди переходят на клиент-серверный режим, ставят Express, и становится хуже, чем было.
Нет бэкапа перед миграцией. Файл .dt — это хорошо. Но нужна ещё копия исходного файла 1Cv8.1CD. И копия базы SQL Server после загрузки. Три точки восстановления. Если что-то пойдёт не так на шаге 5 — возвращаетесь к файлу. Если на шаге 6 — к бэкапу SQL. Без бэкапов каждая ошибка — катастрофа.
Не тестируют после миграции. Загрузили, подключили, «вроде работает» — и разошлись. А через неделю выясняется: регламентное задание по обмену с банком падает с ошибкой. Печатная форма счёта-фактуры не открывается — внешняя обработка лежала на сетевом диске, путь изменился. Отчёт для директора выдаёт ошибку — в нём была прямая ссылка на файловую базу. Нужен чек-лист приёмки: провести документ каждого типа, сформировать ключевые отчёты, проверить обмены, запустить регламентные задания вручную. Мы обычно закладываем на тестирование полный рабочий день. Лучше потратить день на проверку, чем неделю на авральное исправление.
Не обновляют файлы подключения на рабочих станциях. На каждом компьютере пользователя есть файл .v8i (или список баз в реестре), где прописан путь к информационной базе. После миграции строка подключения меняется: вместо File="\\server\share\base" нужно Srvr="имя_сервера";Ref="имя_базы". Если на части машин .v8i не обновить, пользователи будут открывать старую файловую базу и работать в ней, пока остальные работают в серверной. Данные расходятся, документы дублируются, выясняется это через неделю при сверке. Решение: перед миграцией собрать список всех рабочих станций, после переключения — удалить или переименовать файл старой базы на сетевом диске, чтобы попытка подключения к файловой базе сразу выдавала ошибку, а не молча открывала пустую или устаревшую копию.
Забывают про обслуживание SQL Server. Перешли на клиент-серверный режим — и забыли, что SQL Server требует ухода. Через полгода индексы фрагментированы, статистика устарела, логи транзакций съели диск. Производительность падает до уровня файловой базы. Регулярное обслуживание — не опция, а обязательное условие. Подробнее об этом — в разборе закрытия месяца в 1С:ERP, где мы показываем, как устаревшая статистика и фрагментация влияют на тяжёлые операции.
Что вы получите
Цифры из наших проектов. Не средние по рынку — конкретные замеры до и после миграции на трёх базах разного размера.
Время открытия 1С. Файловая база 6 ГБ, 12 пользователей: 45-180 секунд (зависит от нагрузки). Клиент-серверная: 8-12 секунд. Стабильно, независимо от того, сколько людей уже работает.
Проведение документа «Реализация товаров» (500 строк). Файловая: 12-25 секунд. Клиент-серверная: 2-4 секунды. В шесть раз быстрее.
Формирование ОСВ за год. Файловая: 90-120 секунд. Клиент-серверная: 5-8 секунд. В пятнадцать раз быстрее.
Одновременная работа. Файловая база на 12 пользователях регулярно выдавала ошибки блокировок — в среднем 3-5 раз в день. На клиент-серверной за месяц — ноль ошибок блокировок при тех же операциях.
Стабильность. Файловая база раз в два-три месяца «ломалась» — требовалось тестирование и исправление. Иногда с потерей последних транзакций. SQL Server за два года — ни одного повреждения данных. При условии, что настроены бэкапы и обслуживание.
Долгосрочные преимущества для IT-отдела. Клиент-серверный режим открывает возможности, которых в файловой базе нет в принципе. Резервное копирование средствами SQL Server выполняется без остановки пользователей. Дифференциальные и инкрементальные бэкапы: полный бэкап раз в сутки, дифференциальный каждый час, бэкап журнала транзакций каждые 15 минут. При сбое — восстановление на любую точку во времени (point-in-time recovery), а не откат к вчерашней копии с потерей дня работы. Мониторинг через штатные средства SQL Server: Activity Monitor, Dynamic Management Views, оповещения SQL Agent при росте очереди или падении производительности. Всё это зрелые инструменты с двадцатилетней историей, документацией и сообществом. Файловая база не даёт ничего из этого — только ручное копирование файла при выгнанных пользователях.
Отдельно стоит сказать про восприятие пользователей. После перехода на клиент-серверный режим мы обычно слышим одну и ту же фразу: «1С стала другой программой». Это не преувеличение. Когда документ проводится за 3 секунды вместо 20, а отчёт формируется за 5 секунд вместо двух минут — ощущение от работы меняется кардинально. Люди перестают бояться «нажать не ту кнопку и ждать». Начинают использовать аналитические отчёты, которые раньше запускали раз в квартал, потому что ждать было невозможно.
Переход с файловой базы на клиент-серверную — не модернизация ради модернизации. Это устранение архитектурного ограничения, которое тормозит работу всей компании. Файловая база — инструмент для малого масштаба. Когда масштаб вырос — инструмент нужно менять. Чем раньше, тем дешевле: и по деньгам, и по нервам.
