Ошибка «Could not continue scan with NOLOCK due to data movement» в 1С

Ошибка could not continue scan with NOLOCK due to data movement возникает в клиент-серверной 1С:Предприятие 8.3 на MS SQL Server. Платформа выполняет запрос с подсказкой NOLOCK (грязное чтение), а в этот момент страница данных таблицы сдвигается из-за параллельной транзакции — сканирование прерывается. В 9 случаях из 10 это симптом проблем с целостностью БД или регламентным обслуживанием.

Что означает эта ошибка

1С на уровне СУБД использует разные уровни изоляции. При чтении справочников и регистров без явных блокировок MS SQL применяет режим READ UNCOMMITTED. Если в момент сканирования таблицы другая транзакция перемещает страницы (split, reorganize, изменение кластерного индекса) — сервер не может гарантировать целостность результата и аварийно прерывает запрос с сообщением «could not continue scan with NOLOCK».

Сама по себе ошибка не означает потерю данных, но почти всегда указывает на повреждение страниц, фрагментацию или конфликт с антивирусом/бэкапом, который держит файлы БД.

Появляется в модальном окне 1С при открытии справочника, проведении документа, формировании отчёта или фоновых регламентных задачах. В журнале регистрации фиксируется как «Ошибка СУБД» с native code 601.

Причины появления

• Физическое повреждение страниц таблицы или индекса в файле .mdf.
• Сильная фрагментация индексов (более 30–50%), отсутствие регламентных операций.
• Устаревшая статистика — оптимизатор строит неверный план и упирается в движение страниц.
• Параллельная нагрузка: длинная транзакция перестраивает кластерный индекс во время чтения.
• Антивирус или агент резервного копирования сканирует файлы БД на лету.
• Сбой дисковой подсистемы (битые сектора, проблемы с RAID-контроллером).
• Аварийное завершение SQL-сервиса (отключение питания, kill процесса).

Способ 1: Проверка целостности через DBCC CHECKDB

Перед любыми действиями сделайте полный бэкап БД средствами MS SQL. Затем в SQL Server Management Studio выполните:

USE [имя_базы_1С];
GO
DBCC CHECKDB ('имя_базы_1С') WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO

Если команда выводит ошибки уровня consistency errors — нужно восстанавливаться. Самый щадящий путь:

DBCC CHECKDB ('имя_базы_1С', REPAIR_REBUILD);

Если не помогает, используется REPAIR_ALLOW_DATA_LOSS — но только из бэкапа, потому что возможны потери. Перед этим переводят БД в режим SINGLE_USER:

ALTER DATABASE [имя_базы_1С] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('имя_базы_1С', REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE [имя_базы_1С] SET MULTI_USER;

Способ 2: Реиндексация и обновление статистики

Если CHECKDB не нашёл ошибок, проблема в фрагментации. Запустите регламентное обслуживание:

1. В SSMS откройте «Maintenance Plans» (Планы обслуживания).
2. Создайте план с задачами: Rebuild Index, Reorganize Index, Update Statistics.
3. Запустите план вручную для проблемной базы.

Альтернатива — скрипт по всем таблицам:

EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (ONLINE = OFF)';
EXEC sp_updatestats;

Операция требует свободного места в логе и tempdb — закладывайте окно обслуживания ночью.

Способ 3: Тестирование и исправление в Конфигураторе

После работ на стороне SQL обязательно проведите тестирование информационной базы средствами 1С. Все пользователи должны выйти.

1. Запустите Конфигуратор от имени администратора.
2. Меню: Администрирование → Тестирование и исправление.
3. Включите флаги: «Реиндексация таблиц», «Проверка логической целостности», «Проверка ссылочной целостности», «Пересчёт итогов», «Сжатие таблиц информационной базы».
4. Режим: «Тестирование и исправление», действия при ошибках — «Не изменять».
5. Запустите и дождитесь окончания (на больших базах — несколько часов).

Способ 4: Рестарт SQL-сервиса и проверка дисков

Если ошибка появилась после сбоя питания или зависания сервера:

1. Остановите службу SQL Server (MSSQLSERVER) через services.msc.
2. Запустите chkdsk C: /f для диска с файлами БД (если это системный — потребуется перезагрузка).
3. Проверьте журнал Windows (Event Viewer → System) на ошибки диска и контроллера.
4. Запустите SQL-сервис. В журнале SQL (ERRORLOG) посмотрите recovery — все ли БД поднялись.

Способ 5: Восстановление из резервной копии

Если CHECKDB показывает неустранимые ошибки и REPAIR грозит потерями, разворачивайте предыдущий бэкап:

1. В SSMS: Базы данных → правой кнопкой → Restore Database.
2. Источник — последний валидный full backup, затем differential и transaction log backups в правильной последовательности.
3. После восстановления проверьте регламентными операциями 1С.
4. Информацию за период между сбоем и бэкапом восстанавливают повторным вводом.

Профилактика

Настройте план обслуживания MS SQL: ежедневно — обновление статистики и reorganize индексов, еженедельно — полный rebuild и DBCC CHECKDB. Ежедневный full backup + transaction log каждые 30–60 минут. Папки с файлами БД (.mdf, .ldf, .bak) добавьте в исключения антивируса. Используйте отдельные диски для данных, логов и tempdb. Не выключайте сервер кнопкой — только через корректный shutdown с предварительной остановкой служб 1С и SQL.

FAQ

Можно ли продолжать работу с базой при появлении этой ошибки?

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

DBCC CHECKDB ничего не нашёл, а ошибка всё равно появляется. Что делать?

Проверьте план обслуживания и статистику. Запустите rebuild всех индексов и sp_updatestats. Если повторяется — проблема в железе: диагностика SMART, RAID-контроллера, проверка памяти ECC.

Помогает ли отключение NOLOCK на стороне 1С?

1С не даёт прямого управления подсказками SQL — режим чтения зависит от уровня изоляции и кода конфигурации. Лечить нужно причину (повреждение/фрагментацию), а не симптом.

Как часто запускать DBCC CHECKDB на боевой базе?

Полный CHECKDB — раз в неделю в окно обслуживания. На очень больших БД (от 500 ГБ) допустимо разбивать на CHECKTABLE по группам таблиц или использовать PHYSICAL_ONLY в будни и полный — на выходных.

Чем отличается REPAIR_REBUILD от REPAIR_ALLOW_DATA_LOSS?

REPAIR_REBUILD пересобирает индексы и не теряет данные. REPAIR_ALLOW_DATA_LOSS удаляет повреждённые страницы — данные на этих страницах теряются. Второй вариант — крайняя мера, только если бэкапа нет.

Нужно ли тестировать ИБ в Конфигураторе после ремонта SQL?

Да, обязательно. SQL восстановит физическую целостность, но логическая целостность (битые ссылки, рассинхронизация итогов) — компетенция платформы 1С. Без тестирования ИБ возможны ошибки проведения.

Влияет ли антивирус на эту ошибку?

Прямо влияет. Если антивирус блокирует или сканирует файлы .mdf во время записи — SQL получает ошибки I/O, которые приводят к повреждению страниц. Исключения для путей БД обязательны.