При эксплуатации систем на базе 1С:Предприятие в клиент-серверном варианте рано или поздно встает вопрос выбора лицензий для СУБД Microsoft SQL Server. Особенно остро эта проблема проявляется, когда текущая база «вырастает» из бесплатной версии Express, имеющей жесткое ограничение в 10 Гб на размер файла данных. В этой статье мы подробно разберем варианты лицензирования Standard версии, выясним причины внезапного роста базы после обновлений и рассмотрим альтернативные пути оптимизации и миграции на PostgreSQL.
Для небольших и средних внедрений 1С Microsoft предлагает две основные модели лицензирования версии Standard. Рассмотрим их подробно, чтобы понять, какая из них будет выгоднее в вашем случае.
1. Модель «Сервер + Клиентские лицензии» (Server + CAL)
В этой модели вы приобретаете одну лицензию на сам экземпляр сервера (физический или виртуальный) и определенное количество лицензий клиентского доступа (CAL — Client Access License).
Важный нюанс: В среде 1С действует правило мультиплексирования. Хотя к SQL-серверу технически подключается только один «пользователь» (служба сервера приложений 1С), Microsoft требует лицензировать каждого конечного пользователя или устройство, которые инициируют запросы через сервер 1С. Рассчитаем порог выгодности: обычно модель Server + CAL дешевле до тех пор, пока количество пользователей не превышает 30–40 человек. После этого рубежа стоимость CAL-лицензий начинает превышать стоимость лицензирования ядер.
2. Модель «По ядрам» (Per Core)
Здесь лицензируется вычислительная мощность сервера. Вам не нужно считать пользователей или устройства.
Многие администраторы сталкиваются с ситуацией: база весила 7 Гб, а после обновления конфигурации или платформы внезапно стала занимать 15 Гб. Разберем причины этого явления.
Во-первых, проанализируем структуру хранения конфигурации. Внутри SQL-базы 1С хранит не только данные, но и саму конфигурацию (таблица Config). При обновлении на современные релизы (например, переход с Бухгалтерии 2.0 на 3.0 или обновление Розницы) значительно увеличивается объем метаданных. Конфигурация поставщика может храниться в нескольких экземплярах, что существенно увеличивает размер LDF и MDF файлов.
Во-вторых, обратим внимание на режим совместимости. Повышение режима совместимости в свойствах базы SQL и настройках 1С может изменить механизмы версионирования. Если база переходит на использование Snapshot Isolation, это создает дополнительную нагрузку на tempdb и может приводить к росту основного файла данных из-за особенностей выделения страниц под новые версии строк.
Если ваша база превысила 10 Гб и работа в SQL Express заблокировалась, не спешите сразу покупать лицензии. Рассмотрим шаги по «сжатию» системы.
Шаг 1. Очистка конфигурации поставщика
Часто в базе хранятся избыточные данные о поддержке. Попробуем выполнить следующие действия:
.cf..cf обратно. Это часто удаляет «мусор» из служебных таблиц Config и ConfigSave.Шаг 2. Тестирование и исправление (ТИИ)
Проанализируем ситуацию с помощью встроенных инструментов 1С. Запустим «Тестирование и исправление» с включенными опциями «Сжатие таблиц» и «Реиндексация». Это позволит физически перестроить индексы и освободить неиспользуемое пространство внутри страниц данных.
Шаг 3. SQL-сжатие (Page Compression)
Рассмотрим продвинутый метод, доступный в версиях Standard и даже в Express (начиная с 2016 SP1). Мы можем включить сжатие данных на уровне страниц. Это позволит хранить больше данных в тех же 10 Гб. Выполним следующий скрипт для наиболее тяжелых таблиц (обычно это регистры накопления и сведений):
-- Пример сжатия конкретной таблицы
ALTER TABLE [Имя_Таблицы] REBUILD PARTITION = ALL
WITH (DATA_COMPRESSION = PAGE);
GO
Важно: Это увеличит нагрузку на процессор при чтении/записи, но может уменьшить объем базы на диске в 1.5–3 раза, что критично для лимитов Express-версии.
Если бюджет на MS SQL Standard отсутствует, рассмотрим переход на бесплатную СУБД PostgreSQL. Однако, как упоминалось в обсуждении, неудачный опыт часто связан с неправильной настройкой.
Проанализируем проблему RLS (Row Level Security). В аптечных сетях или рознице часто ограничивают права доступа на уровне записей (например, по складам или организациям). В старых версиях PostgreSQL и платформы 1С это приводило к катастрофическому падению производительности — чеки могли пробиваться по несколько минут.
Для успешной работы PostgreSQL выполним следующие рекомендации:
postgresql.conf установите jit = off. Для сложных запросов 1С время компиляции плана часто превышает время выполнения самого запроса.shared_buffers (рекомендуется 25% от объема ОЗУ) и effective_cache_size (75% от ОЗУ).Если решение о покупке Standard версии принято, необходимо правильно настроить сервер, чтобы оправдать вложенные средства. Рассмотрим ключевой параметр — MAXDOP (Maximum Degree of Parallelism).
Для 1С крайне не рекомендуется оставлять этот параметр в значении 0 (использовать все ядра для одного запроса). Это приводит к тому, что один тяжелый отчет может «подвесить» работу всех касс. Установите значение 1 (для малых баз) или равное количеству ядер в одном NUMA-узле процессора. Выясним причину: 1С строит запросы так, что параллелизм чаще вредит, чем помогает, из-за ожиданий на блокировках CXPACKET.
Также помните, что версия Standard ограничена использованием 128 Гб оперативной памяти. Если на вашем сервере установлено 256 Гб, SQL Server просто не увидит «лишнее», поэтому планируйте ресурсы сервера грамотно.
Таким образом, выбор между MS SQL и PostgreSQL — это баланс между стоимостью лицензий и стоимостью владения (затратами на высококвалифицированного администратора). Тщательная очистка конфигурации и использование механизмов сжатия данных помогут вам отсрочить дорогостоящую покупку или сложный переезд.