Иногда я получаю сообщение «Не удалось продолжить сканирование NOLOCKиз-за перемещения данных» с некоторыми большими заданиями, которые выполняются WITH (NOLOCK)в запросах выбора.
Я понимаю, что это как-то связано с попыткой выбора данных, когда произошел разрыв страницы, из-за которого данные перестали быть такими, какими они должны были быть - я предполагаю, что это происходит в моей среде.
Как бы я воспроизвести это?
Я пытаюсь сделать краткосрочный обходной путь, чтобы поймать ошибку и повторить попытку, когда это происходит, но я не могу проверить это, если я не могу воспроизвести это. Есть ли достаточно надежный способ вызвать это?
Когда это происходит, повторное выполнение запроса приводит к успеху - поэтому у меня нет особых опасений по поводу того, что реальные данные или база данных будут постоянно повреждены. Некоторые таблицы в запросе (вместе с их индексами) часто удаляются, воссоздаются и заполняются, поэтому я предполагаю, что это как-то связано с этим.
Удаление NOLOCK- это моя долгосрочная проблема. Во NOLOCK-первых, причина была в том, что запросы были настолько плохими, что они зашли в тупик с ежедневными транзакциями, поэтому NOLOCKбыла и пластырь, чтобы остановить взаимные блокировки (что сработало). Поэтому мне нужен лейкопластырь на лейкопластыре, пока мы не сможем сделать окончательное решение.
Если бы я мог воспроизвести это с Hello World, я бы планировал, возможно, нанести пластырь на работу менее чем за час. Не могу выполнить удаление с поиском и заменой NOLOCK, потому что я снова начну получать блокировки приложений, что для меня хуже, чем случайная неудачная работа.
Хорошая возможность - использовать изоляцию моментальных снимков с фиксацией чтения - мне нужно будет поработать с нашей командой базы данных, чтобы получить более подробную информацию об этом. Частично наша проблема заключается в том, что у нас нет эксперта по SQL Server, который бы справлялся с подобными вещами, и я недостаточно хорошо понимаю уровни изоляции, чтобы сделать это изменение прямо сейчас.
DEADLOCK_PRIORITYзначение LOWв заданиях, чтобы при возникновении взаимоблокировок сбой заданий, а не приложений. После этого вы можете исследовать тупики и выяснить, почему они происходят, и решить эту проблему. Это может быть очень простое исправление, например, поменять местами порядок двух операторов. Какова бы ни была проблема, NOLOCKэто не решение , поэтому перестаньте пытаться заставить ее быть только потому, что это проще всего.
NOLOCKс этих рабочих мест? 601 должен меньше всего волновать вас, если результаты этих запросов должны быть точными . Пол Уайт показывает особенно ужасный пример чтения данных, который не должен быть здесь возможным .