gifts2017

Could not continue scan with NOLOCK due to data movement в 1С:Предприятие

Опубликовал Вячеслав Гилёв (Gilev.Vyacheslav) в раздел Администрирование - Тестирование и исправление

Скорее всего с этой ошибкой вы не сталкиваетесь, но если что, то будьте "вооружены" этой заметкой...

Что говорит производитель MS SQL Server:

http://msdn.microsoft.com/ru-ru/library/bb326281.aspx
SQL Server Database Engine не удается продолжить выполнение запроса, поскольку приложение пытается считать данные, обновленные или удаленные другой транзакцией. Очередь использует подсказку блокировки NOLOCK или
уровень изоляции транзакции READ UNCOMMITTED.
Как правило, доступ к данным, которые изменяются другой операцией, запрещен из-за наложенной на них блокировки.
Однако подсказка блокировки NOLOCK и уровень изоляции транзакции READ UNCOMMITTED позволили запросу считать данные, заблокированные другой транзакцией. Это называется «грязным» чтением, поскольку таким образом можно считать значения, которые еще не были зафиксированы и могут быть изменены.
Эта ошибка отменяет запрос. Отправьте запрос повторно или удалите подсказку блокировки NOLOCK.

Есть небольшая вероятность того, что дело в конфигурации.

Пример на скриншоте.

Could not continue scan with NOLOCK due to data movement

Но здесь есть ключевое НО: Обратите внимание, что речь идет о конфликте блокировок и запрос на чтение вне тразнакции.

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

В ОСТАЛЬНЫХ СЛУЧАЯХ, применительно к 1С:Предприятие скорее дело не в этом.

Проблемы с диском!!! Ошибка появляется при разрушении данных.

Проверьте БД  с помощью DBCC CHECKDB. Обязательно сделайте резервную копию!

Попытайтесь с помощью все той же DBCC CHECKDB восстановить данные (если жесткий диск "не умирает").

ALTER DATABASE [Ваша база] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO

DBCC CHECKDB ([Ваша база],REPAIR_ALLOW_DATA_LOSS)
GO

ALTER DATABASE [Ваша база]SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO

Если повреждения несерьезные, то все будет хорошо. Если нет, то используйте бэкапы.

 

Или это ошибка платформы

Такое уже было раньше

http://downloads.v8.1c.ru/content/Comm/Platform/Err_8_2_9_356.htm

10036291  Ошибка СУБД: Microsoft OLE DB Provider for SQL Server: Could not continue scan with NOLOCK due to data movement.

Проблема:
В клиент-серверном варианте информационной базы с использованием MS SQL Server при возникновении ошибки

Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Could not continue scan with NOLOCK due to data movement.
HRESULT=80040E14, SQLSrvr: Error state=3, Severity=C, native=601, line=1

происходит аварийное завершение работы программы.
Дата публикации: 2009-11-16

На момент написания статьи такой ошибки не было зарегистрировано, но это не 100% гарантия.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Павел И. (3.14159) 07.11.13 09:39
если жесткий диск "не умерает"


p.s. Я збагоен :)
2. Вячеслав Гилёв (Gilev.Vyacheslav) 07.11.13 21:15
3. Вячеслав Гилёв (Gilev.Vyacheslav) 07.11.13 21:53

ну собственно говоря написал заметку "по горячим следам", в результате мы улучшили наш сервис и теперь он обнаруживает подобные ситуации
dlysychenko; +1 Ответить
4. Владимир (hogik) 07.11.13 23:17
(0)
Два предложения из описания ошибки от Microsoft:
1) "Очередь использует подсказку блокировки NOLOCK или уровень изоляции транзакции READ UNCOMMITTED."(с)
2) "Однако подсказка блокировки NOLOCK и уровень изоляции транзакции READ UNCOMMITTED позволили запросу считать данные, заблокированные другой транзакцией."(с)


Вячеслав (Gilev.Vyacheslav).
Думаю, в описании ошибки от Microsoft во втором предложении должно быть не "и", а "или". Как и в первом. Т.е. выполнение запроса вне транзакции с "подсказкой" NOLOCK может вызвать такую ошибку. И это не зависит от того, какой уровень изоляции у пишущей транзакции. Т.е. надо выполнить рекомендации от Microsoft: "Отправьте запрос повторно или удалите указание блокировки NOLOCK."(с) Платформа этого не делает - запрос не отправляет "необходимое" количество раз. А подсказки NOLOCK установлены в 1С-платформе (как я понимаю) для всех запросов "на чтение вне транзакции".
5. Вячеслав Гилёв (Gilev.Vyacheslav) 07.11.13 23:19
(4) hogik, я воспринял текст немного по другому:
NOLOCK = уровень изоляции транзакции READ UNCOMMITTED
если оценивать по конечному эффекту
6. Вячеслав Гилёв (Gilev.Vyacheslav) 07.11.13 23:21
(4) hogik,
А подсказки NOLOCK установлены в 1С-платформе (как я понимаю) для всех запросов "на чтение вне транзакции".
есть мнение, что не всегда
но если честно, я то хотел показать другую мысль: не только дело в чтении грязных данных, но и в порче дисков и т.п.
7. Владимир (hogik) 07.11.13 23:25
(5)
Вячеслав (Gilev.Vyacheslav).
Не буду спорить. Но, данная ошибка в MS SQL - это "нормальное поведение системы" при данных условиях (как я их понял). Надо повторить запрос за платформу. И всё... ;-)
Но допускаю, что повторить запрос не всегда возможно из среды 1С-а на уровне прикладного программиста. Тогда - проблема. :-(
Gilev.Vyacheslav; +1 Ответить 1
8. Вячеслав Гилёв (Gilev.Vyacheslav) 07.11.13 23:28
9. Владимир (hogik) 07.11.13 23:36
(6)
"... хотел показать другую мысль: не только ... , но и в порче дисков и т.п. "(с)
Вячеслав (Gilev.Vyacheslav).
Таких "логичных" сбоев не бывает по причине "порчи".
Ну, если только в сервере память стоит без ЕСС. :-) (Шутка по прошлым нашим с Вами темам).
10. Вячеслав Гилёв (Gilev.Vyacheslav) 07.11.13 23:54
(9) hogik, да, и память без коррекции тоже может быть негативным фактором

Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа