При обновлении платформы 1С:Предприятие на версии 8.3.17 и выше многие администраторы баз данных столкнулись с неожиданным явлением: параметр ALLOW_PAGE_LOCKS для всех таблиц и индексов в MS SQL Server переходит в состояние OFF. Давайте разберемся, почему это происходит, является ли это ошибкой и как правильно настроить регламентное обслуживание базы данных в таких условиях.
Начиная с версий платформы 1С 8.3.22 и выше, разработчики 1С внедрили архитектурное изменение в механизм взаимодействия с MS SQL Server. Суть его заключается в принудительном установлении значения ALLOW_PAGE_LOCKS = OFF для индексов базы данных. Это решение направлено на борьбу с проблемой эскалации блокировок.
Когда ALLOW_PAGE_LOCKS включен (ON), SQL Server может при определенных условиях переводить блокировку с уровня отдельной строки на уровень целой страницы данных. В высоконагруженных системах это часто приводило к тому, что транзакции, работающие с разными строками, попадали на одну и ту же страницу и блокировали друг друга, что вызывало снижение производительности. Принудительный запрет страничных блокировок заставляет SQL Server использовать блокировки на уровне строк, что повышает параллельность работы пользователей.
Главная сложность, с которой сталкиваются администраторы — это ошибки при выполнении стандартных планов обслуживания MS SQL Server. Операция ALTER INDEX REORGANIZE (реорганизация индекса) требует возможности блокировки на уровне страниц. Если этот параметр отключен, SQL Server выдает ошибку, и задание по дефрагментации прерывается. Посмотрим, какие пути решения этой задачи существуют.
Рассмотрим вариант, при котором мы программно возвращаем возможность страничных блокировок непосредственно перед запуском процедуры обслуживания. Вы можете подготовить T-SQL скрипт, который будет выполнять следующие шаги:
ALLOW_PAGE_LOCKS = ON.ALLOW_PAGE_LOCKS = OFF, как того требует платформа 1С.Однако, учитывая, что 1С принудительно возвращает этот параметр в OFF, данный метод требует тщательного тестирования на совместимость с фоновыми процессами платформы.
Разберем более радикальный, но эффективный подход. Вместо реорганизации (REORGANIZE) перейдем на полное перестроение индексов (REBUILD). Данная операция:
ALLOW_PAGE_LOCKS = ON.ONLINE = ON).Если ваши скрипты обслуживания настроены на использование REORGANIZE, рекомендуем изменить их логику так, чтобы при достижении определенного порога фрагментации (например, выше 30%) всегда выполнялось REBUILD.
Проанализируем ситуацию: большинство готовых решений (например, скрипты Ола Халингрена) позволяют гибко настраивать параметры дефрагментации. Мы можем модифицировать эти скрипты, чтобы они игнорировали параметры блокировок или выбирали только те методы, которые допустимы текущей конфигурацией платформы. Если вы используете сторонние планы обслуживания, обязательно проверьте настройки фильтрации объектов, чтобы они корректно обрабатывали таблицы с ALLOW_PAGE_LOCKS = OFF.
Важное примечание: Перевод блокировок на уровень строк может увеличить потребление оперативной памяти сервером СУБД. Это происходит из-за того, что системе требуется хранить больше записей о блокировках в памяти для управления параллельными процессами. Убедитесь, что объем доступной RAM на сервере достаточен для работы в новом режиме.
Таким образом, поведение платформы является штатным. Мы рекомендуем не бороться с самим фактом установки ALLOW_PAGE_LOCKS = OFF, а адаптировать процессы обслуживания (перейти на REBUILD), что обеспечит стабильную работу базы данных 1С и высокую производительность системы.