Вопрос перехода с файловой базы данных 1С на клиент-серверный вариант (SQL) рано или поздно встает перед любой растущей организацией. В этой статье мы проанализируем типичную ситуацию: наличие десяти активных пользователей, нескольких баз объемом от 3 до 12 ГБ и старого серверного оборудования. Разберемся по шагам, почему "правило 2 Гб" является критическим и какие преимущества дает SQL в реальности.
Существует распространенное мнение, что файловая база 1С (файл 1CD) может расти бесконечно, пока хватает места на диске. Однако мы должны выяснить причину технических сбоев, которые часто возникают при достижении определенного объема. На самом деле ограничение в 2 Гб в файловом варианте относится не к общему размеру файла базы, а к размеру одной внутренней таблицы. Рассмотрим подробнее: в 1С данные хранятся в различных таблицах (движения регистров, итоги, справочники). Как только любая из этих таблиц (например, _InfoRegP123) перешагнет порог в 2 Гб, система выдаст критическую ошибку Memory allocation error или Ошибка СУБД: Превышен максимально допустимый размер таблицы.
В ситуации нашего автора, где базы имеют размер 12 Гб, риск того, что одна из таблиц (особенно в тяжелых конфигурациях типа ЗУП 3.1 или ERP) приблизится к этому лимиту, крайне высок. При использовании SQL-сервера такие ограничения на размер таблиц отсутствуют, что позволяет базе расти до терабайтных значений.
Когда с базой работают 10 пользователей, посмотрим, что происходит в момент проведения документа в файловом режиме. Файловая СУБД 1С использует табличные блокировки. Это означает, что если один бухгалтер проводит накладную, система блокирует всю таблицу движений для записи. В этот момент второй бухгалтер, пытающийся провести другой документ, будет ждать завершения первой операции. На 10 пользователях это субъективно воспринимается как "тормоза" интерфейса.
Переход на SQL позволяет использовать управляемые блокировки (строчные). Разберем механизм: SQL-сервер блокирует не всю таблицу, а только те конкретные строки, которые изменяются в данный момент. В результате 10 и более человек могут работать одновременно, практически не мешая друг другу. Это ключевой фактор повышения производительности при параллельной работе.
Ситуация, описанная автором (пользователи трижды теряли данные и перебивали документы за месяц), недопустима для профессиональной ИТ-инфраструктуры. Рассмотрим, как SQL-сервер меняет подход к безопасности:
LDF-файл). Если сервер упадет, при перезапуске SQL-сервер сам "откатит" незавершенные операции, сохранив целостность базы.1CD (обычно раз в сутки). С SQL мы можем настроить бэкап лога транзакций каждые 15-30 минут. Проанализируем ситуацию: при сбое в 16:00 вы сможете восстановить базу на 15:45, потеряв всего 15 минут работы, а не весь день.Важно понимать, что переход на SQL — это не просто смена формата хранения. Мы переходим на трехзвенную архитектуру:
Рассмотрим вопрос стоимости. Для реализации этой схемы требуются лицензия на Сервер 1С:Предприятие и клиентские лицензии. Если бюджет ограничен, мы рекомендуем обратить внимание на PostgreSQL. Это бесплатная альтернатива MS SQL, которая официально поддерживается фирмой 1С и позволяет получить все преимущества клиент-серверного режима без затрат на лицензии Microsoft.
Проанализируем аппаратную часть. Процессоры Xeon серии 5300 являются устаревшими для современных конфигураций 1С. При переходе на SQL нагрузка на процессор и дисковую подсистему возрастет, так как добавятся процессы rphost (сервер 1С) и sqlservr (СУБД).
Чтобы минимизировать замедление, разберем по шагам настройку протокола Shared Memory. Если сервер 1С и SQL-сервер находятся на одной физической машине, этот протокол позволяет им обмениваться данными через оперативную память, минуя медленный сетевой стек. Это критически важно для производительности на старом "железе".
После перехода на SQL недостаточно просто оставить систему работать. Для сохранения скорости необходимо настроить регламентные задания внутри СУБД. Выделим основные:
Учитывая, что базы автора достигают 12 Гб и в них работают 10 пользователей, наш вердикт однозначен: необходимо планировать переход на SQL. Файловый режим в таких условиях — это "бомба замедленного действия". Риск потери данных из-за нарушения целостности структуры гораздо выше, чем затраты времени на настройку сервера приложений. Если лицензии на MS SQL уже есть, как в случае автора, то единственным препятствием является время администратора, которое многократно окупится отсутствием необходимости восстанавливать базу после очередного сбоя.