1. Главная страница » Компьютеры » Nolock sql что это

Nolock sql что это

Автор: | 16.12.2019

532 Andy White [2009-03-26 20:13:00]

Может ли кто-нибудь объяснить последствия использования with (nolock) для запросов, когда вы должны/не должны его использовать?

Например, если у вас есть банковское приложение с высокими ставками транзакций и большим количеством данных в определенных таблицах, в каких типах запросов nolock будет в порядке? Существуют ли случаи, когда вы всегда должны использовать его/никогда не использовать?

16 ответов

388 Решение David M [2009-03-26 20:16:00]

WITH (NOLOCK) является эквивалентом использования READ UNCOMMITED в качестве уровня изоляции транзакции. Таким образом, вы рискуете прочитать незафиксированную строку, которая впоследствии будет откат, т.е. Данные, которые никогда не попадали в базу данных. Таким образом, хотя это может помешать чтению заходить в тупик другими операциями, это сопряжено с риском. В банковском приложении с высокими транзакционными ставками он, вероятно, не будет правильным решением любой проблемы, которую вы пытаетесь решить с помощью IMHO.

Вопрос в том, что хуже:

  • тупик или
  • неправильное значение?

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

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

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

Тем не менее, SQL Server 2005 исправил большинство ошибок, которые сделали NOLOCK необходимым. Поэтому, если вы не используете SQL Server 2000 или более раннюю версию, вам не нужно.

Дополнительная литература
Версии уровня строк

49 sqlbelle [2011-03-29 10:30:00]

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

"С подсказкой NOLOCK (или установкой уровня изоляции сеанса READ UNCOMMITTED) вы указываете SQL Server, что вы не ожидаете согласованности, поэтому нет никаких гарантий. Помните, что" непоследовательные данные "означают не только то, что вы можете увидеть незафиксированные изменения, которые впоследствии были отброшены, или изменения данных в промежуточном состоянии транзакции. Это также означает, что в простом запросе, который сканирует все данные таблицы/индекса, SQL Server может потерять позицию сканирования, или вы можете получив одну и ту же строку дважды ".

49 saasman [2009-03-26 20:55:00]

Пример текстовой книги для законного использования подсказки nolock — это выборка отчета для базы данных OLTP с высоким уровнем обновления.

Сделать актуальный пример. Если бы крупный банк США на высоких улицах захотел запустить почасовой отчет о поиске первых признаков городского уровня, которые выполнялись в банке, запрос на нолоке мог бы сканировать транзакционные таблицы, суммирующие денежные депозиты и снятие наличных денег в каждом городе. Для такого отчета крошечный процент ошибок, вызванных свернутыми транзакциями обновления, не уменьшит значение отчета.

30 Andrew [2010-03-03 20:01:00]

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

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

Никакая блокировка не только возвращает неправильные значения, она возвращает phantom записи и дубликаты.

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

Справедливости ради, вот два специальных сценария, в которых подсказка nolock может обеспечить полезность

1) База данных sql-сервера до 2005 года, которая должна запускать длительный запрос в отношении текущей базы данных OLTP, может быть единственным способом

2) Плохо написанное приложение, которое блокирует записи и возвращает управление пользовательскому интерфейсу и читателям, блокируется неограниченно. Nolock может быть полезен здесь, если приложение не может быть исправлено (сторонний и т.д.), А база данных — либо до 2005 года, либо версия версии не может быть включена.

23 Seibar [2009-03-26 20:43:00]

NOLOCK эквивалентен READ UNCOMMITTED , однако Microsoft заявляет, что вы не должны использовать его для операторов UPDATE или DELETE :

Для операторов UPDATE или DELETE: эта функция будет удалена в будущей версии Microsoft SQL Server. Избегайте использования этой функции в новых разработках и планируйте изменять приложения, которые в настоящее время используют эту функцию.

Эта статья относится к SQL Server 2005, поэтому поддержка NOLOCK существует, если вы используете эту версию. В целях обеспечения будущего кода (при условии, что вы решили использовать грязные чтения) вы можете использовать это в своих хранимых процедурах:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

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

В общем случае: вы можете использовать его, когда вы очень уверены, что все в порядке, чтобы прочитать старые данные. Важно помнить, что очень легко получить это неправильно. Например, даже если это нормально в момент написания запроса, уверены ли вы, что в будущем в базе данных не будет изменений, чтобы сделать эти обновления более важными?

Читайте также:  Amnf victoria что это

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

16 marc_s [2009-03-26 20:15:00]

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

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

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

13 dkretz [2009-03-26 21:08:00]

Простой ответ — всякий раз, когда ваш SQL не изменяет данные, и у вас есть запрос, который может мешать другим действиям (через блокировку).

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

Это особенно полезно, если у вас есть отчеты типа OLAP, которые вы используете против базы данных OLTP.

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

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

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

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

Я использовал для получения "следующей партии" для вещей. В этом случае не имеет значения точный элемент, и у меня есть много пользователей, которые запускают этот же запрос.

6 Learning [2009-03-26 20:16:00]

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

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

Я использую подсказку (nolock), особенно в базах данных SQLServer 2000 с высокой активностью. Я не уверен, что это необходимо в SQL Server 2005. Недавно я добавил эту подсказку в SQL Server 2000 по просьбе клиентского DBA, потому что он замечал множество блокировок записей SPID.

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

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

Короткий ответ:

Никогда не используйте WITH (NOLOCK) .

Длительный ответ:

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

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

Ошибка или Result-set могут быть пустыми, пропускать строки или отображать одну и ту же строку несколько раз.

Это связано с тем, что другие транзакции перемещают данные одновременно с чтением.

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

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

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

Никогда не используйте NOLOCK.

3 Ed Green [2016-05-20 12:49:00]

Самый простой ответ — простой вопрос — нужны ли вам результаты, которые можно было бы повторить? Если да, то NOLOCKS не подходит ни при каких обстоятельствах

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

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

7. Производительность скалярных UDF оставляет желать лучшего

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

Посмотрите этот пост о принудительном использовании параллелизма – в частности, список того, что приводит к генерации «однопоточного» плана выполнения запроса. Скорее всего, использование скалярных UDF (прим. переводчика: а для серверов младше 2008 R2 и не только скалярных) приведёт к тому, что ваш запрос будет выполняться в одном потоке (*грустно вздыхает*).

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

6. «WITH (NOLOCK)» не означает, что блокировок не будет вообще

На одном из этапов своей карьеры разработчика вы можете начать использовать хинт WITH (NOLOCK) повсеместно, поскольку с ним ваши запросы выполняются быстрее. Это не всегда плохо, но может сопровождаться неожиданными побочными эффектами, про которые Kendra Little рассказывала вот в этом видео. Я же сфокусируюсь только на одном из них.

Читайте также:  Officesuite что это за программа

Когда ваш запрос обращается к какой-либо таблице, даже с хинтом NOLOCK, вы накладываете блокировку стабилизации схемы (schema stability lock, Sch-S). Никто не сможет изменить эту таблицу или её индексы до тех пор, пока ваш запрос не завершится. Это не кажется серьёзной проблемой до тех пор, пока вам не понадобится удалить индекс, но вы не сможете этого сделать, поскольку люди постоянно работают с этой таблицей, находясь в полной уверенности, что не создают никаких проблем, поскольку они используют хинт WITH (NOLOCK).

Здесь нет «серебряной пули», но начните читать об уровнях изоляции SQL Server — я полагаю, что уровень изоляции READ COMMITTED SNAPSHOT будет наилучшим выбором для вашего приложения. Вы будете получать целостные данные с меньшим количеством проблем с блокировками.

5. Используйте три строки соединения в своём приложении

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

  1. Строка соединения для записи и чтения «в реальном времени» — это та строка соединения, которую вы используете сейчас и думаете, что все данные должны приходить именно отсюда. Вы можете оставить весь свой код таким, какой он есть сейчас, но когда будете что-то дописывать, или изменять текущий, подумайте о том, чтобы изменить в запросах строку соединения на одну из представленных ниже.
  2. Строка соединения для получения «относительно свежих» данных, возрастом 5-15 минут – для данных которые могут быть слегка устаревшими, но всё равно сегодняшними.
  3. Строка соединения для «вчерашних» данных – для отчётов и построения трендов. Например, в онлайн-магазине, с этой строкой соединения вы можете вытягивать пользовательские обзоры к товарам, а самих пользователей предупреждать, что их обзоры будут опубликованы на следующий день.

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

4. Используйте промежуточную БД

Вероятно, вы используете БД для выполнения каких-то второстепенных задач – вычисления, сортировка, загрузка и т.д. Если вдруг эти данные пропадут, вы вряд ли сильно расстроитесь, но вот структура таблиц – это, конечно, другое дело. Сейчас вы делаете всё в «основной базе данных» вашего приложения.

Создайте отдельную базу данных, назовите её MyAppTemp, и делайте всё в ней! Поставьте ей простую модель восстановления и просто создавайте резервную копию раз в день. Не заморачивайтесь с высокой доступностью или аварийным восстановлением этой БД.

Использование такой техники имеет кучу плюсов. Она минимизирует количество изменений в основной БД, а значит резервные копии журнала транзакций и дифференциальные бэкапы будут делаться быстрее. Если вы используете log shipping, по-настоящему важные данные будут копироваться быстрее. Вы даже можете хранить эту БД отдельно от других баз, например на недорогом, но шустром SSD-диске, оставив основную систему хранения данных для критически важных в продакшене данных.

3. «Вчерашние» статьи и книги могут перестать быть актуальными сегодня.

SQL Server вышел уже больше десяти лет назад и за эти годы в нём произошло множество изменений. К сожалению, старые материалы не всегда обновляются, чтобы описать «сегодняшние» изменения. Даже свежие материалы из проверенных источников могут быть неправильными – вот, например, критика методики Microsoft по повышению производительности SQL Server. Microsoft Certified Master Jonathan Kehayias нашёл множество по-настоящему плохих советов в документе Microsoft.

Когда вы слышите что-то, что звучит как хороший совет, я предлагаю вам использовать стратегию, обратную стратегии доктора Фила. Доктор Фил говорит, что вы должны «проникнуться» любой идеей на протяжении 15 минут. Вместо этого, попробуйте возненавидеть её – постарайтесь опровергнуть то, что вы прочитали перед тем как применять это в продакшене. Даже если совет чертовски хорош, он может быть не очень-то и полезным на вашей системе. (Да, это относится и к моим советам).

2. Избегайте использования ORDER BY; сортируйте данные в приложении

На сортировку результатов вашего запроса, SQL Server тратит процессорное время. SQL Server Enterprise Edition стоит порядка 7000$ за одно ядро – не за процессор, а за само ядро. Двухсокетный, шестиядерный сервер обойдётся примерно в 84000$ — и это только цена лицензий, не считая железа. Вы можете купить чертовски много серверов приложений (даже с 256 ГБ оперативки на каждом) за $84k.

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

UPD. Я получил множество комментариев о том, что приложение нуждается, например, только в десяти строках, вместо десяти миллионов строк, возвращаемых запросом. Да, конечно, если вы пишете TOP 10, вам нужна сортировка, но как на счёт того, чтобы переписать запрос так, чтобы он не возвращал кучу ненужных данных? Если же данных так много, что серверу приложений приходится тратить слишком много ресурсов на сортировку – так ведь и SQL Server выполняет ту же самую работу. Мы поговорим о том как находить такие запросы на вебинаре, ссылка на который есть в конце поста. Кроме того, помните, что я сказал «Избегайте использования ORDER BY», а не «Никогда не используйте ORDER BY». Я точно так же использую эту инструкцию – но, если я могу избежать этого на очень дорогом уровне баз данных, я стараюсь это сделать. Вот что означает «избегать».

(А это часть, в которой фанаты MySQL и PostgreSQL рассказывают о том как снизить стоимость лицензий, используя СУБД с открытым исходным кодом). (А в этой части вы ждёте, что я им остроумно отвечу, но я не буду этого делать. Если вы разрабатываете новое приложение и задумались о выборе БД, прочтите мой ответ на StackOverflow о том какая БД выдержит наибольшую нагрузку.)

Читайте также:  Excel перевод текста в формулу
1. У SQL Server есть встроенные инструменты для поиска узких мест, не влияющие на производительность

Динамические административные представления SQL Server (DMV) могут показать вам все места, пагубно влияющие на производительность, т.е.:

  • какие запросы генерируют наибольшую нагрузку на вашем сервере
  • какие индексы просто занимают место и замедляют операции вставки/удаления/обновления
  • какие узкие места есть на вашем сервере (CPU, диск, сеть, блокировки и т.д.)?

Всё что вам нужно знать – это где всё это посмотреть — и во вторник, пятого марта, мы вам это покажем. Мы делаем 30-минутный вебкаст для подготовки разработчиков и вы можете зарегистрироваться на него здесь (upd вебинар успешно прошёл, запись можно посмотреть здесь).

Примечание переводчика: любые предложения и замечания по переводу и стилистике, как обычно, приветствуются.

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

Грязное чтение: В этой методологии процесс считывает незафиксированные данные и не обращает внимания на открытые транзакции, поэтому блокировки не вызывают никаких проблем в процессе чтения. Таким образом, этот тип чтения снижает уровень блокировок. Однако грязное чтение имеет как положительные, так и отрицательные стороны, поскольку грязное чтение может вызывать проблемы несогласованности данных в результирующем наборе оператора SELECT. Как отмечалось ранее, этот результирующий набор может включать следы незафиксированных транзакций, и мы должны принимать это в расчет, решая использовать этот вид чтения. Мы не можем быть уверены в реальности строк, которые мы получаем при грязном чтении, поскольку для этих строк может быть выполнен откат. С другой стороны, этот тип чтения позволяет избежать проблем с блокировками и увеличить производительность SQL Server.

NOLOCK: По умолчанию SQL Server использует уровень изоляции Read Committed (чтение зафиксированных транзакций), и этот уровень изоляции не позволяет читать объекты, которые заблокированы незавершенными транзакциями. Кроме того, эти заблокированные объекты могут изменяться в соответствии с эскалацией блокировки.

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

В этом случае User2 ждет, по меньшей мере, 10 секунд, а затем транзакция откатывается пользователем user1, после чего пользователь user2 может прочитать строку, отмеченную зеленым, поскольку блокировка строки снимается пользователем user1. Это поведение по умолчанию уровня изоляции Read Committed в SQL Server.

Теперь продемонстрируем этот случай в SQL Server. Сначала создадим таблицу FruitSales и добавим в неё несколько строк.

На первом шаге мы открываем два окна (вкладки) в SQL Server Management Studio и выполняем сначала запрос пользователя user1, а затем — запрос пользователя user2.

Как вы можете увидеть, второй запрос ожидает до тех, пока пользователь user1 не выполнит откат транзакции.

Теперь мы обсудим детали использования хинта NOLOCK. Хинт NOLOCK — один из наиболее популярных табличных хинтов, который используется разработчиками баз данных и администраторами для решения проблем блокировок в базах данных SQL Server. С помощью табличного хинта NOLOCK мы можем читать заблокированные объекты (строку, страницу или таблицу), которые заблокированы открытыми транзакциями. Хинт NOLOCK отменяет значение по умолчанию оптимизатора запросов SQL Server таким образом, что оператор SELECT может читать заблокированные объекты.

Теперь мы добавим хинт NOLOCK в оператор SELECT пользователя user2, а затем выполним UPDATE пользователя user1 с последующим оператором SELECT пользователя user2.

Итак, User1 выполняет оператор обновления в явной транзакции, а затем пользователь user2 выполняет оператор выборки, и результирующий набор возвращается без задержки на время выполнения транзакции. Это главное назначение NOLOCK — читать заблокированные объекты.

Теперь посмотрим на результат выполнения оператора SELECT. Оператор SELECT пользователя user2 возвращает значение 20 столбца SalesTotal, хотя реальное значение осталось равным 8. Запомните, что если вы используете табличный хинт NOLOCK в запросе на выборку, то можете столкнуться с подобным типом несоответствия результатов.

Совет. Ключевое слово «WITH» является устаревшим, поэтому Майкрософт рекомендует не использовать его в новых проектах баз данных и удалить из текущих разработок. Вы можете использовать хинт NOLOCK без слова «WITH».

Кроме этого, табличный хинт READUNCOMMITTED эквивалентен хинту NOLOCK, и мы можем использовать его вместо NOLOCK.

Несмотря на это, существует случай, когда хинт NOLOCK не в состоянии преодолеть барьер блокировки. Если некоторый процесс изменяет структуру таблицы, NOLOCK не может изменить тип блокировки и не позволит продолжить операцию чтения. Причина заключается в том, что хинт NOLOCK ориентирован на блокировки Sch-S (стабильность схемы), а оператор ALTER TABLE накладывает Sch-M блокировку (модификация схемы), так что имеет место конфликт.

Сначала мы определим Object_id (идентификатор объекта) таблицы FruitSales с помощью следующего запроса.

Запустите следующий запрос user1, а затем запрос user2. В результате запрос user2 будет ожидать завершения процесса изменения таблицы пользователем user1.

Откройте новое окно запроса и выполните следующий код. Этот запрос поможет выяснить тип блокировки запросов user1 и user2.

Теперь мы сверимся с матрицей совместимости блокировок для SCH-M и SCH-S. Матрица указывает на конфликт между SCH-M и SCH-S.

Заключение

В статье рассматривается процесс грязного чтения и хинт NOLOCK. Использование этого хинта является эффективным методом чтения заблокированных страниц; однако метод имеет как преимущества, так и недостатки. Это следует учитывать прежде, чем использовать хинт NOLOCK.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

code