1С и SQL Server: ошибка «невозможно реорганизовать, страничная блокировка отключена»

Ошибка «невозможно реорганизовать индекс, так как страничная блокировка отключена» возникает в клиент-серверных базах 1С, работающих на Microsoft SQL Server, при попытке выполнить реиндексацию или реструктуризацию. Платформа 1С обращается к механизму перестроения индексов SQL Server, а тот отказывает в операции, потому что для конкретного индекса параметр ALLOW_PAGE_LOCKS установлен в OFF.

Проблема почти всегда появляется после ручного вмешательства в индексы: администратор или сторонний скрипт обслуживания отключил страничные блокировки «для оптимизации», руководствуясь советами из интернета, не учитывая, что 1С при тестировании и исправлении, реструктуризации или обновлении конфигурации выполняет ALTER INDEX ... REORGANIZE, которому страничные блокировки необходимы.

Хорошая новость: ошибка полностью устранима штатными средствами SQL Server и не приводит к потере данных сама по себе. Нужно найти индексы с отключёнными страничными блокировками и включить их обратно. Ниже — диагностика, готовые запросы, порядок исправления и меры, чтобы ситуация не повторилась.

Что означает эта ошибка и почему она появляется

SQL Server поддерживает несколько уровней блокировок: строка (ROW), страница (PAGE) и таблица. Страничные блокировки — промежуточный уровень, который используется при обслуживании индексов. Операция ALTER INDEX ... REORGANIZE физически невозможна без страничных блокировок: движок SQL Server должен перемещать и уплотнять страницы данных, а для этого ему нужно их блокировать.

Когда администратор или скрипт устанавливает ALLOW_PAGE_LOCKS = OFF, SQL Server прямо сообщает: «The index cannot be reorganized because page locks are disabled». Платформа 1С транслирует эту ошибку пользователю, и операция прерывается. Типичные точки возникновения: тестирование и исправление информационной базы с включённой реиндексацией, обновление конфигурации с реструктуризацией таблиц, регламентные задания обслуживания, запущенные из 1С.

Откуда берётся отключённый параметр? Чаще всего источники такие: скрипты «оптимизации» индексов, скопированные из статей по тонкой настройке SQL Server; миграция базы скриптами, где свойства индексов были заданы явно; ручные эксперименты администратора, о которых забыли. Важно понимать: штатная установка 1С создаёт индексы с настройками по умолчанию, то есть страничные блокировки включены. Если они выключены — кто-то это сделал осознанно или по шаблону.

Как найти индексы с отключёнными страничными блокировками

Прежде чем что-то менять, нужно получить полную картину: какие индексы и в каких таблицах имеют ALLOW_PAGE_LOCKS = OFF. Для этого используется системное представление sys.indexes в контексте вашей базы 1С.

Подключитесь к SQL Server через SQL Server Management Studio (SSMS), откройте новый запрос, выберите нужную базу и выполните запрос:

SELECT OBJECT_NAME(i.object_id) AS TableName, i.name AS IndexName, i.allow_page_locks FROM sys.indexes i WHERE i.allow_page_locks = 0 AND i.index_id > 0 ORDER BY TableName, IndexName;

Результат покажет список таблиц и индексов с отключёнными страничными блокировками. Если список пуст, а ошибка в 1С сохраняется — проверьте, не работаете ли вы с другой базой (например, запрос выполнялся в контексте master), и убедитесь, что база 1С именно та, с которой работает сервер 1С.

Дополнительно стоит проверить параметр ALLOW_ROW_LOCKS: он тоже влияет на обслуживание индексов. Запрос выше легко расширить, добавив колонку i.allow_row_locks, чтобы зафиксировать оба параметра одним проходом.

Как включить страничные блокировки: пошаговое исправление

Исправление выполняется командой ALTER INDEX с перестроением индекса. Обратите внимание: изменить параметр без REBUILD нельзя — SQL Server применяет настройку именно при перестройке. Поэтому операция потребляет ресурсы сервера и время, пропорциональное размеру таблицы.

Для одного индекса команда выглядит так:

ALTER INDEX [ИмяИндекса] ON [ИмяТаблицы] REBUILD WITH (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON);

Если индексов много, удобнее сгенерировать команды автоматически:

SELECT 'ALTER INDEX [' + i.name + '] ON [' + OBJECT_NAME(i.object_id) + '] REBUILD WITH (ALLOW_PAGE_LOCKS = ON);' FROM sys.indexes i WHERE i.allow_page_locks = 0 AND i.index_id > 0;

Скопируйте сгенерированные строки в новое окно запроса и выполните. Для больших баз удобнее запускать перестройку порциями, контролируя нагрузку на сервер.

1. 1
   Сделайте резервную копию базы средствами SQL Server
2. 2
   Найдите индексы с allow_page_locks = 0 через sys.indexes
3. 3
   Сгенерируйте и выполните команды ALTER INDEX ... REBUILD WITH (ALLOW_PAGE_LOCKS = ON)
4. 4
   Повторите проверочный запрос — список проблемных индексов должен стать пустым
5. 5
   Повторите операцию в 1С, которая вызывала ошибку
6. 6
   Найдите и отключите скрипт или регламент, изначально отключивший параметр

Безопасность операции и нагрузка на сервер

REBUILD индекса — ресурсоёмкая операция. На больших таблицах (регистры накопления, журналы документов) она может занимать заметное время и активно использовать журнал транзакций и tempdb. Планируйте работу на период минимальной нагрузки: ночь или выходные.

Если у вас редакция SQL Server Enterprise, доступна опция ONLINE = ON, позволяющая перестраивать индекс без долгой блокировки таблицы. В редакции Standard онлайн-перестройка ограничена, поэтому таблица на время операции может быть недоступна пользователям 1С — предупредите их заранее.

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

Чем отличаются REORGANIZE и REBUILD и почему это важно для 1С

REORGANIZE — облегчённая операция дефрагментации: она упорядочивает листовой уровень индекса, работает всегда в онлайн-режиме и потребляет мало ресурсов, но требует страничных блокировок. Именно её использует 1С при реиндексации в типовых сценариях обслуживания.

REBUILD — полная перестройка индекса с нуля. Она возможна и при отключённых страничных блокировках, поэтому иногда в качестве «обходного пути» предлагают заменить реорганизацию на перестройку. Для разовой задачи это допустимо, но как постоянная практика — плохое решение: REBUILD тяжелее, дольше и при отключённых страничных блокировках проблема с 1С всё равно останется, потому что платформа вызывает именно REORGANIZE.

Вывод простой: не подгоняйте обслуживание под сломанный параметр, а верните параметр в штатное состояние. Для баз 1С рекомендуемое и ожидаемое платформой состояние — ALLOW_PAGE_LOCKS = ON и ALLOW_ROW_LOCKS = ON для всех индексов.

Как предотвратить повторение проблемы

После исправления самое важное — найти источник. Проверьте планы обслуживания SQL Server (Maintenance Plans), задания SQL Server Agent, сторонние скрипты дефрагментации и документацию, по которой настраивался сервер. Если найдёте в скриптах конструкцию WITH (ALLOW_PAGE_LOCKS = OFF) — уберите её или замените на ON.

Будьте осторожны с универсальными рекомендациями по «ускорению» SQL Server: совет отключить страничные блокировки для снижения конкуренции за блокировки встречается в старых статьях, но для баз 1С он прямо вреден. Платформа 1С рассчитана на стандартные настройки индексов, и любое «улучшение» на уровне SQL Server нужно проверять на тестовой копии базы.

Полезно добавить периодический контроль: раз в месяц или после любых работ по обслуживанию выполняйте проверочный запрос к sys.indexes. Пустой результат — подтверждение, что настройки индексов в штатном состоянии.

Типичные ошибки при устранении

Первая ошибка — исправление только одного индекса из текста ошибки. Обычно параметр отключён у многих индексов сразу, и после исправления одного ошибка всплывёт на следующем. Всегда работайте с полным списком из sys.indexes.

Вторая ошибка — попытка изменить параметр без перестройки, например через ALTER INDEX ... SET. Эта команда не поддерживает изменение ALLOW_PAGE_LOCKS: только REBUILD. Третья — выполнение работ без резервной копии и в разгар рабочего дня, что превращает плановую операцию в аварийную ситуацию с блокировками.

Частые вопросы