Не удалось продолжить просмотр с nolock вследствие перемещения данных 1с

Обновлено: 05.07.2024

Иногда я получаю «Не удалось продолжить сканирование с помощью NOLOCK из-за перемещения данных» с некоторыми большими заданиями, которые имеют WITH (NOLOCK) в выбранных запросах.

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

Как я могу воспроизвести это?

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

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

Удаление NOLOCK - это моя долгосрочная проблема. Причина NOLOCK была там, в первую очередь, заключалась в том, что запросы настолько плохи, что они зашли в тупик с ежедневными транзакциями, поэтому NOLOCK был лентой для остановки тупиков (которые работали). Поэтому мне нужна ленточная помощь на полосе помощи, пока мы не сможем сделать постоянное решение.

Если бы я мог воспроизвести его с Hello World, я бы планировал, что, возможно, похлопывая ленточную помощь с работой меньше чем через час. Не удается выполнить поиск и замену NOLOCK , потому что я снова начну использовать тупики приложения, что для меня хуже чем случайная неудачная работа.

Использование исправленной изоляции моментальных снимков - это хорошая возможность - мне придется работать с нашей командой базы данных, чтобы получить более подробную информацию об этом. Часть нашей проблемы заключается в том, что у нас нет эксперта SQL Server для решения такого рода вещей, и я недостаточно понимаю уровни изоляции, чтобы сделать это изменение прямо сейчас.

1 ответ

Kendra предоставляет подробную информацию о преимуществах и рисках с использованием уровня изоляции READ_COMMITTED_SNAPSHOT.

Этот уровень изоляции становится уровнем изоляции по умолчанию для кода базы данных.
У вас должен быть только один пользователь в базе данных, чтобы внести изменения в уровень изоляции READ_COMMITTED_SNAPSHOT.
Даже если вы используете изоляцию READ_COMMITTED_SNAPSHOT , вам все равно нужно удалить подсказки NOLOCK , так как они переопределяют значение по умолчанию.
Некоторые из ваших кодов могут иметь проблемы, требующие лечения.

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

Почему это произошло? Поскольку предыдущий уровень изоляции вызвал сильную блокировку, код мог «никогда» не достигнуть точки блокировки. Однако с READ_COMMITTED_SNAPSHOT, запросы могут продолжать двигаться вперед. Тем не менее, некоторый процент от ожидающих транзакций без ожидания начал блокировать.

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

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

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

В ОСТАЛЬНЫХ СЛУЧАЯХ, применительно к 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

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

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

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

Специальные предложения

ну собственно говоря написал заметку "по горячим следам", в результате мы улучшили наш сервис и теперь он обнаруживает подобные ситуации
(3) Коль вы связываете ошибку с проблемами диска, то опишите
- как часто такая ошибка регистрируется? Единичная, повторяющаяся?
- возможно ли определить таблицу, на которой возникла ошибка. Если да, то какой ее размер?
- как изменилась производительность дисков?
- какие ещё сопутствующие симптомы можно выделить?
Поделитесь наблюдениями)

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

Вячеслав (Gilev.Vyacheslav).
Думаю, в описании ошибки от Microsoft во втором предложении должно быть не "и", а "или". Как и в первом. Т.е. выполнение запроса вне транзакции с "подсказкой" NOLOCK может вызвать такую ошибку. И это не зависит от того, какой уровень изоляции у пишущей транзакции. Т.е. надо выполнить рекомендации от Microsoft: "Отправьте запрос повторно или удалите указание блокировки NOLOCK."(с) Платформа этого не делает - запрос не отправляет "необходимое" количество раз. А подсказки NOLOCK установлены в 1С-платформе (как я понимаю) для всех запросов "на чтение вне транзакции".

(4) hogik, я воспринял текст немного по другому:
NOLOCK = уровень изоляции транзакции READ UNCOMMITTED
если оценивать по конечному эффекту (5)
Вячеслав (Gilev.Vyacheslav).
Не буду спорить. Но, данная ошибка в MS SQL - это "нормальное поведение системы" при данных условиях (как я их понял). Надо повторить запрос за платформу. И всё. ;-)
Но допускаю, что повторить запрос не всегда возможно из среды 1С-а на уровне прикладного программиста. Тогда - проблема. :-( А подсказки NOLOCK установлены в 1С-платформе (как я понимаю) для всех запросов "на чтение вне транзакции". есть мнение, что не всегда
но если честно, я то хотел показать другую мысль: не только дело в чтении грязных данных, но и в порче дисков и т.п.
(6)
". хотел показать другую мысль: не только . , но и в порче дисков и т.п. "(с)
Вячеслав (Gilev.Vyacheslav).
Таких "логичных" сбоев не бывает по причине "порчи".
Ну, если только в сервере память стоит без ЕСС. :-) (Шутка по прошлым нашим с Вами темам).

(9) hogik, да, и память без коррекции тоже может быть негативным фактором

Используем 1С 8.2, обычные формы, режим блокировок автоматический.

Авторитетные знающие люди, подскажите, если в этой ошибке указанно ID 601 то зачем использовать "dbcc checkdb".

Формальная отписка на сайте MS гласит: "Эта ошибка отменяет запрос. Отправьте запрос повторно или удалите указание блокировки NOLOCK".

Вопрос: как убедить админа вывести базу из работы, провести проверку и если ошибок нет, передать работу программистам и поддержке 1C.

Корпорация Майкрософт распространяет исправления Microsoft SQL Server 2008 как один загружаемый файл. Так как исправления являются накопительными, каждый выпуск содержит все исправления и все исправления безопасности, которые были включены в предыдущие 2008 SQL Server исправления выпуска.

Проблемы

Ошибка msg 605, 21 уровень состояние 3, строка 1Attempt для выборки логической страницы (1:225) в базе данных 2. Он принадлежит к 281474980315136 единицы размещения не для 504403158513025024.

Msg 601, уровень 12, состояние 3, процедура procedure имя, номер строкине удалось продолжить просмотр с NOLOCK вследствие перемещения данных.

Запрос конструкцию, которая может приводить к этим ошибкам выглядит следующим образом:

Решение

Исправление этой уязвимости первого выпуска накопительного обновления 3. Дополнительные сведения о том, как получить этот накопительный пакет обновления для SQL Server 2008, щелкните следующий номер статьи базы знаний Майкрософт:

960484 Накопительный пакет обновления 3 для SQL Server 2008Примечание. Поскольку построения являются накопительными, каждый новый выпуск исправление содержит все исправления и все исправления, входившие в состав предыдущих SQL Server 2008 выпуска исправлений. Мы рекомендуем рассмотреть применение последнего выпуска исправления, содержащего это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

956909 SQL Server 2008 выполняет построение, выпущенных после выпуска SQL Server 2008После установки этот накопительный пакет обновления, необходимо включить флаг трассировки 4135. Чтобы сделать это, можно добавить -T4135 параметра запуска. Или можно использовать инструкцию dbcc traceon(4135) для конкретного сеанса.

Обходное решение

Чтобы обойти эту проблему, добавьте столбец с кластеризованного первичного ключа и свойство identity во временной таблице. Например выполните следующую инструкцию, чтобы изменить временной таблицы:

Статус

Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе "Применяется к".

Дополнительная информация

960484 Накопительный пакет обновления 3 для SQL Server 2008

Сведения о SQL Server 2008 R2 анализатора соответствия Рекомендациям

Ссылки

Правило SQL Server 2008 R2 анализатора соответствия Рекомендациям

Примечание. Можно включить флаг трассировки 4135 или флаг трассировки 4199 Включение данного исправления. Флаг трассировки 4135 был представлен в накопительный пакет обновления 3 для SQL Server 2008. Флаг трассировки 4135 доступен также в Пакет обновления 1 для SQL Server 2008, Пакет обновления 2 для SQL Server 2008 и SQL Server 2008 R2. Флаг трассировки 4199 был введен в накопительный пакет обновления 7 для SQL Server 2008, накопительный пакет обновления 7 для SQL Server 2008 Пакет обновления 1 и накопительный пакет обновления 1 для SQL Server 2008 R2. Дополнительные сведения о флаге трассировки 4199 щелкните следующий номер статьи базы знаний Майкрософт:

974006 Флаг трассировки 4199 добавляется к элементу управления, несколько изменений оптимизатор запросов, сделанных в группе несколько флагов трассировки Так как исправление для этой проблемы включает в себя сочетание построения исправления и флага трассировки, чтобы активировать его, предоставляются вместе в следующей таблице показаны различные сценарии и рекомендуемые действия для выполнения для каждого сценария.Дополнительные сведения о последней версии сборок SQL Server щелкните следующий номер статьи базы знаний Майкрософт:

957826 Где найти сведения о последней версии SQL Server формирует

Call stack information

Ссылки

Дополнительные сведения о списке сборок, доступных после выпуска SQL Server 2008 щелкните следующий номер статьи базы знаний Майкрософт:

956909 SQL Server 2008 выполняет построение, выпущенных после выпуска SQL Server 2008Дополнительные сведения о добавочных модель обслуживания для SQL Server щелкните следующий номер статьи базы знаний Майкрософт:

935897 Модель обслуживания изменений, используемая рабочей группой SQL Server, предоставляет модель ISM для распространения исправлений обнаруженных проблемДополнительные сведения о схеме именования для обновления SQL Server щелкните следующий номер статьи базы знаний Майкрософт:

822499Новая схема присвоения имен пакетам обновлений программного обеспечения Microsoft SQL ServerДля получения дополнительных сведений о терминологии обновлений программного обеспечения щелкните следующий номер статьи базы знаний Майкрософт:

824684 Стандартные термины, используемые при описании обновлений программных продуктов Майкрософт

Author (SME): bruceye
Writer: ericzha
Tech Reviewer: bruceye; wcarroll
Editor: v-janhal

Помогите, не пойму почему при тестировании базы - при проверка регистра сведений "Версии объектов" на 30% выдает ошибку: Конфликт блокировок при выполнении транзакции: Microsoft SQL Server Native Client 10.0: Не удалось продолжить просмотр с NOLOCK вследствие перемещения данных. Нашла за какой день в этом регистре ошибка, пытаюсь просто прокрутить и просмотреть регистр за этот день и мне тут же выдает ошибку ту же ошибку. При очисте регистра за этот день тоже самое. что делать с базой. Помогите плиз.

При этом в базе кроме меня никто не работает! и стоит блокировка выполнения регламентных заданий.

Далее перезапускаем сервер 1с, если не помогает запускаем тестирование и исправление базы

паралельно пытаемся восстановить архив в тестовую базу и посмотреть взлетит не взлетит

При попытке выгрузки базы средствами 1С выдало ошибку: Сеанс работы завершен администратором. по причине: Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 10.0: Shared Memory Provider: С обоих концов канала отсутствуют процессы.

Перезагрузила, зашла в предприятие и просто за этот день пролистала и не сразу, а чуть позже появляется ошибка: Конфликт блокировок при выполнении транзакции Microsoft SQL Server Native Client 10.0: Не удалось продолжить просмотр с NOLOCK вследствие перемещения данных.

как вариант делайте как Михаил сказал. Единственное, я бы еще скопировал бы базу целиком

сейчас запустила тестрирование через конфигуратор, если не поможет тогда как Михаил Базу целиком? она не файловая и выгрузку получается могу сделать только с помощью SQL

а если можно подробно описать как сделать DBCC CHECKDB через скуль, никогда этого не делала. SQL Server 2008

и какой мой предшественник выставил версионировать все. вот досталось по наследству.

А можно подробное описание как сделать DBCC CHECKDB через скуль, никогда этого не делала. SQL Server 2008 Я зашла в скуль, на базе правой кнопкой - новый запрос - и в поле справа наисала:DBCC CHECKDB (0, REPAIR_ALLOW_DATA_LOSS) и все? и просто выполнить?

DBCC CHECKDB WITH NO_INFOMSGS. Лучше сначала просто понять какие есть ошибки (если есть)

SQL Server Database Engine не удается продолжить выполнение запроса, поскольку приложение пытается считать данные, обновленные или удаленные другой транзакцией. Очередь использует подсказку блокировки NOLOCK или уровень изоляции транзакции READ UNCOMMITTED. Как правило, доступ к данным, которые изменяются другой операцией, запрещен из-за наложенной на них блокировки. Однако подсказка блокировки NOLOCK и уровень изоляции транзакции READ UNCOMMITTED позволили запросу считать данные, заблокированные другой транзакцией. Это называется «грязным» чтением, поскольку таким образом можно считать значения, которые еще не были зафиксированы и могут быть изменены. Эта ошибка отменяет запрос. Отправьте запрос повторно или удалите подсказку блокировки NOLOCK. Удалить ты не можешь, но при определенной версии SQL можно изменить уровень изоляции на SNAPSHOT. Правда, при этом будет эпизодически пухнуть tempdb.

Если не используется инкрементальное резервное копирование в SQL, стОит перевести recovery model БД в Simple

Значит так, очистила таблицу регистра сведений "Версии объектов" (пожертвовала ненужной информацией)прямо через таблицы скуля. и все заработало:) Тестирование и исправление прошло удачно. Придется историю изменения объектов в копии смотреть:( Большое спасибо за советы и подсказки :)

Читайте также: