Как перевести «1С:Управление торговлей 10.3» с файловой базы на MS SQL Server?

Переход с файлового варианта работы на клиент-серверный — это важный этап в жизни любой растущей информационной системы. Когда объем базы данных Управление торговлей 10.3 достигает критических отметок (в нашем случае — 14 Гб), производительность и надежность файловой системы начинают вызывать серьезные опасения. В данной статье мы подробно разберем, как осуществить этот переход, выберем наиболее стабильную связку системного ПО и рассмотрим нюансы тонкой настройки MS SQL Server для работы с платформой 1С.

Выбор стабильной версии платформы и MS SQL Server

Проанализируем практический опыт специалистов, работающих с конфигурациями на обычных формах. Основной вопрос при переходе: стоит ли гнаться за новейшими версиями платформы 8.3 или остаться на проверенной временем 8.2?

Для типовой конфигурации УТ 10.3 «золотым стандартом» стабильности считается связка платформы 8.2.19.130 и MS SQL Server 2012. Рассмотрим преимущества этого выбора:

1. Отсутствие избыточности: УТ 10.3 не использует управляемые формы и новый функционал платформы 8.3. Использование 8.2 позволяет избежать лишних затрат ресурсов на поддержку неиспользуемых механизмов.
2. Стабильность: Данная связка проверена годами эксплуатации на базах объемом свыше 25-50 Гб.
3. Совместимость: Отсутствуют проблемы с протоколами безопасности (TLS 1.2) и новыми оптимизаторами запросов, которые характерны для более свежих версий SQL.

Однако, если ваша ИТ-инфраструктура требует использования новых ОС (Windows Server 2019/2022) или параллельно работают базы на 1С:Бухгалтерия 3.0, мы рекомендуем использовать платформу 8.3.10 или выше в режиме совместимости 8.2.17. Это позволит использовать один сервер 1С для разных баз, сохраняя при этом работоспособность старой конфигурации.

Решение проблем с оптимизатором запросов (Cardinality Estimator)

Выясним причину возможного падения производительности при использовании современных версий SQL (2014 и выше). Начиная с версии 2014, MS SQL использует новый алгоритм оценки количества строк (Cardinality Estimator), который часто некорректно работает со структурой запросов старых версий 1С.

Если мы выбираем SQL 2014, 2016 или 2019, нам необходимо принудительно заставить сервер использовать старую логику оптимизатора. Разберем по шагам, как это сделать:

1. Установим Compatibility Level базы данных в значение 110 (соответствует SQL 2012).
2. Включим флаг трассировки 9481 на уровне всего сервера SQL. Это критически важно для корректного построения планов запросов в 1С.

Настройка режима блокировок и RCSI

Посмотрим на специфику работы УТ 10.3 с блокировками. По умолчанию эта конфигурация работает в режиме автоматических блокировок. В клиент-серверном варианте это часто приводит к «взаимным блокировкам» (Deadlocks) и ожиданию на транзакциях.

Чтобы существенно повысить комфорт работы пользователей без переписывания кода конфигурации под управляемые блокировки, мы рекомендуем включить режим Read Committed Snapshot Isolation (RCSI). Проанализируем, что это дает: пишущие процессы (например, проведение документа) перестают блокировать читающие процессы (формирование отчетов). Это достигается за счет использования версионности строк в базе TempDB.

Для включения этого режима выполним следующий скрипт в консоли SQL Management Studio:

ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;

Оптимизация производительности: Диски и TempDB

Разберем технические аспекты настройки серверного оборудования. При переходе на SQL критически важно распределить нагрузку на дисковую подсистему:

1. Разделение файлов: Обязательно разместим файл базы данных (MDF) и файл журнала транзакций (LDF) на разных физических дисках. Для журнала транзакций крайне желательно использовать быстрые SSD/NVMe накопители.
2. Настройка TempDB: Системная база TempDB активно используется 1С для построения временных таблиц при формировании тяжелых отчетов. Рекомендуем разделить TempDB на несколько файлов (количество файлов должно соответствовать числу ядер процессора, но не более 8).
3. Лимиты памяти: SQL Server склонен поглощать всю доступную оперативную память. Если сервер приложений 1С и сервер SQL находятся на одной машине, необходимо жестко ограничить Max Server Memory, оставив ОС и процессам rphost минимум 4-8 Гб.

Обслуживание базы данных после перехода

Выясним, почему простого резервного копирования недостаточно для стабильной работы. После миграции на SQL необходимо настроить регулярные регламентные операции:

• Обновление статистики (Update Statistics): Без актуальной статистики SQL начнет выбирать неэффективные планы запросов, что приведет к резкому замедлению работы (особенно в отчетах). Рекомендуется настроить ежедневное обновление.
• Реиндексация и дефрагментация: Помогает поддерживать структуру индексов в оптимальном состоянии. Для базы объемом 14+ Гб это обязательная еженедельная процедура.
• Использование скриптов: Мы рекомендуем использовать бесплатные и высокоэффективные скрипты Олы Халленгрена (Ola Hallengren) для настройки планов обслуживания вместо стандартных мастеров SQL.

Важное замечание: Будьте готовы к тому, что после перехода из файлового режима размер базы на диске увеличится в 1.5–2 раза. Это связано с особенностями хранения индексов и служебных данных в MS SQL Server. Заранее убедитесь в наличии свободного места на дисках.

Подводя итог, можно сказать, что переход на SQL — это не просто перенос данных через dt-файл, а комплексная настройка среды. Выбрав связку 8.2.19.130 + SQL 2012 или грамотно настроив 8.3 + SQL 2014+ с использованием флагов трассировки и режима RCSI, вы обеспечите стабильную и быструю работу вашей системы Управление торговлей 10.3 на долгие годы.