← На главную

Обновление крупных конфигураций, таких как 1С:Документооборот, часто сопровождается выполнением тяжелых транзакций на уровне сервера баз данных. Ошибка с кодом HRESULT=80040E14 и описанием Could not continue scan with NOLOCK due to data movement говорит о том, что в процессе чтения данных SQL Server столкнулся с их физическим перемещением. Это происходит, когда структуры таблиц или индексов меняются в момент выполнения запроса к ним. Рассмотрим по шагам, как выявить причину и устранить эту неприятность.

Шаг 1: Подготовка среды перед обновлением

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

1. Блокировка регламентных заданий: Обязательно выполните команду по отключению регламентных заданий. Это можно сделать через консоль администрирования серверов 1С:Предприятие, установив флаг блокировки в свойствах информационной базы.
2. Запрет новых сеансов: Убедитесь, что никто из пользователей не работает в системе. Установите блокировку соединений, чтобы предотвратить случайный вход пользователей во время процесса.
3. Остановка внешних процессов: Если на уровне SQL Server настроены планы обслуживания (Maintenance Plans), которые выполняют дефрагментацию или перестроение индексов, их необходимо временно отключить на период обновления.

Шаг 2: Оптимизация состояния базы данных

Если блокировки установлены, но ошибка сохраняется, проблема может быть в накопленной фрагментации индексов или устаревших планах выполнения запросов на сервере Microsoft SQL Server.

Рекомендуем выполнить следующие действия:

• Реиндексация таблиц: Выполните полную реиндексацию базы данных средствами SQL Server или через конфигуратор 1С. Это приведет структуру индексов в порядок, что снизит вероятность конфликтов при перемещении данных.
• Перезапуск служб: В некоторых случаях критически важно выполнить перезапуск службы SQL Server и службы Агента сервера 1С:Предприятие. Это очистит кэш и освободит зависшие ресурсы памяти.
• Очистка кэша планов запросов: На сервере SQL выполните команду DBCC FREEPROCCACHE. Это заставит сервер перекомпилировать планы запросов, что поможет избежать выполнения операций по «битым» или неоптимальным путям доступа к данным, которые могли остаться после предыдущих попыток обновления.

Шаг 3: Проверка соответствия платформы

Опыт показывает, что в 90% случаев причиной конфликта блокировок при обновлении 1С:Документооборот является несовместимость версии платформы с требованиями релиза конфигурации. Логика реструктуризации таблиц жестко привязана к возможностям движка платформы.

Что нужно сделать:

1. Откройте файл Readme.txt или v8upd11.htm, который идет в комплекте с файлом поставки обновления вашей версии 1С:Документооборот.
2. Найдите строку «Версия платформы, необходимая для работы».
3. Если у вас установлена более новая версия платформы (например, 8.3.19), а рекомендована более ранняя (например, 8.3.16), необходимо установить именно ту версию, которая рекомендована производителем.

Понижение версии платформы — это стандартная практика для исправления подобных критических ошибок при обновлении. Платформа 8.3.16.1502 часто фигурирует в рекомендациях для стабильного обновления версий 2.1. Разберем, почему это важно: алгоритмы 1С для управления транзакциями в разных версиях платформы ведут себя по-разному при работе с Microsoft SQL Server Native Client 11.0. Используя рекомендованную версию, вы обеспечиваете корректную трансляцию команд 1С в запросы T-SQL, что исключает конфликт NOLOCK.

Шаг 4: Поэтапное обновление

Если вы пытаетесь совершить «прыжок» через много версий сразу, риск возникновения ошибки возрастает кратно. Объем реструктуризации таблиц при пропуске релизов становится огромным, транзакции длятся слишком долго, и вероятность наложения data movement становится практически неизбежной.

Рассмотрим стратегию безопасного перехода:

1. Проанализируйте цепочку обновлений, рекомендованную фирмой 1С.
2. Обновляйтесь небольшими шагами (например, с 2.1.10 на 2.1.12, затем на 2.1.15 и так далее).
3. На каждом этапе проверяйте целостность базы данных командой DBCC CHECKDB, чтобы убедиться, что аппаратная часть сервера функционирует корректно и нет логических ошибок в структуре БД.

В завершение, если даже после смены платформы и выполнения всех рекомендаций ошибка не уходит, проверьте дисковую подсистему сервера. Ошибки типа data movement иногда являются индикаторами проблем с «железом» или нехватки места в логах транзакций SQL Server. Убедитесь, что на диске с логами .ldf достаточно свободного пространства.