Приветствуем вас! В реальной практике администрирования систем на платформе «1С:Предприятие 8» часто возникает классическая проблема: на одном физическом сервере или виртуальной машине под управлением MS SQL Server развернуто несколько информационных баз. Одна из этих баз является критически важной (например, база оперативного учета ERP, УТ или КА), а остальные выполняют второстепенные функции (бухгалтерия, подготовка отчетности, расчет зарплаты или архивные копии).
Периодически пользователи или регламентные задания в менее важных базах запускают тяжелые запросы, которые полностью утилизируют процессорное время (CPU), оперативную память (RAM) или дисковую подсистему. В результате критически важная база начинает работать с сильными задержками, что напрямую влияет на бизнес-процессы компании. Сегодня мы подробно разберем, как решить эту проблему, распределить ресурсы сервера СУБД и расставить правильные приоритеты.
Один из наиболее надежных и проверенных временем методов — поднятие второго независимого экземпляра MS SQL Server на том же оборудовании. Давайте детально проанализируем этот подход, его плюсы и минусы.
Суть метода заключается в том, что мы устанавливаем на сервер еще один экземпляр СУБД. Важную базу мы оставляем на основном экземпляре, а все второстепенные базы переносим на второй. После этого мы можем жестко разграничить ресурсы между ними средствами настроек самих экземпляров SQL Server.
Разберем по шагам, на какие параметры настроек следует обратить внимание:
Minimum server memory и Maximum server memory. Это исключает ситуацию, когда один экземпляр полностью вытесняет из оперативной памяти кэш данных другого экземпляра..mdf) и журналов транзакций (.ldf) разных экземпляров необходимо физически разместить на разных дисковых массивах (например, на разных SSD- или NVMe-накопителях), как это и предлагается в практическом опыте администраторов.Главный минус этого подхода: Негибкость распределения ресурсов. Если мы жестко закрепили за второстепенным экземпляром 4 ядра из 12, то даже в моменты полного простоя второстепенных баз основной экземпляр не сможет задействовать простаивающие мощности. Он всегда будет ограничен своими 8 ядрами. Также следует учитывать нюансы лицензирования СУБД по ядрам (Core-based) при развертывании нескольких инстансов на одном хосте.
Более гибким и современным решением является использование встроенного механизма СУБД — Resource Governor (Регулятор ресурсов). Он позволяет управлять распределением вычислительных ресурсов динамически на уровне одного экземпляра SQL Server.
Долгое время этот инструмент был доступен исключительно в дорогой редакции Enterprise, что существенно ограничивало его применение в среднем и малом бизнесе. Однако, начиная с версии SQL Server 2025, Resource Governor стал доступен и в редакции Standard, что делает его применение массовым решением.
Давайте разберем, как настроить Resource Governor для разделения ресурсов по базам данных. В основе настройки лежит классифицирующая функция (Classifier Function), которая определяет, к какому пулу ресурсов направить текущую сессию СУБД.
Пошаговый алгоритм настройки выглядит следующим образом:
ORIGINAL_DB_NAME() и возвращает имя группы рабочей нагрузки, к которой должен быть привязан сеанс.Рассмотрим пример SQL-скрипта для реализации такой схемы:
-- 1. Создаем пул ресурсов для важной базы (высокий приоритет)
CREATE RESOURCE POOL HighPriorityPool
WITH (
MIN_CPU_PERCENT = 50,
MAX_CPU_PERCENT = 100,
MIN_MEMORY_PERCENT = 50,
MAX_MEMORY_PERCENT = 100
);
-- 2. Создаем пул ресурсов для неважных баз (низкий приоритет)
CREATE RESOURCE POOL LowPriorityPool
WITH (
MIN_CPU_PERCENT = 10,
MAX_CPU_PERCENT = 40,
MIN_MEMORY_PERCENT = 10,
MAX_MEMORY_PERCENT = 40
);
GO
-- 3. Создаем соответствующие группы рабочей нагрузки
CREATE WORKLOAD GROUP HighPriorityGroup USING HighPriorityPool;
CREATE WORKLOAD GROUP LowPriorityGroup USING LowPriorityPool;
GO
-- 4. Создаем классифицирующую функцию в базе master
USE master;
GO
CREATE FUNCTION dbo.DatabaseClassifier()
RETURNS sysname
WITH SCHEMABINDING
AS
BEGIN
DECLARE @GroupName sysname;
-- Проверяем имя базы данных, к которой идет подключение
IF ORIGINAL_DB_NAME() = 'Important_1C_DB'
SET @GroupName = 'HighPriorityGroup';
ELSE
SET @GroupName = 'LowPriorityGroup';
RETURN @GroupName;
END;
GO
-- 5. Регистрируем функцию в Resource Governor и применяем настройки
ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.DatabaseClassifier);
ALTER RESOURCE GOVERNOR RECONFIGURE;
GO
Важный нюанс с базой TempDB: Настраивая лимиты через Resource Governor, важно помнить, что системная база tempdb является общей для всего экземпляра СУБД. Если тяжелые запросы из второстепенных баз начнут активно писать временные таблицы в tempdb, это может перегрузить дисковую подсистему и вызвать задержки метаданных (ожидания PAGELATCH) для важной базы. Для решения этой проблемы в современных версиях SQL Server (начиная с 2019/2022) оптимизированную для памяти базу метаданных временных таблиц (Memory-Optimized TempDB Metadata) также можно привязывать к отдельным пулам ресурсов.
Борьба с нагрузкой на стороне СУБД — это зачастую устранение симптомов, а не причины. Платформа «1С:Предприятие 8» уровня КОРП позволяет решать такие проблемы на уровне сервера приложений 1С, предотвращая перегрузку SQL-сервера.
Проанализируем два ключевых механизма платформы 1С КОРП:
rphost). Мы можем настроить требования так, чтобы важная база обслуживалась одними рабочими процессами (или даже выделенным сервером приложений), а все неважные базы — другими. Это исключает ситуацию, когда ресурсоемкий запрос в неважной базе приводит к утечке памяти или зависанию общего процесса rphost, обслуживающего пользователей важной базы.Для выбора оптимальной стратегии сопоставим все варианты:
rphost через требования назначения функциональности в сочетании с лимитами на потребление ресурсов сеансами 1С.ORIGINAL_DB_NAME().