Разбираем блокировки в sql

Sql-ex blog

Введение

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

SQL Server блокирует данные для обеспечения их целостности. Это необходимо в любой БД, где данные подвергаются изменениям. Чтобы подчеркнуть это, скажу, что если БД находится в состоянии READ_ONLY, SQL Server не создает блокировок считываемых данных, поскольку они не могут быть изменены и, следовательно, защищать данные не нужно. Поэтому SQL Server только помечает объекты, к которым происходит обращение, блокировкой Intense Share (IS), чтобы исключить выполнение таких DDL-выражений, как удаление таблицы, из которой производится чтение.

Блокировки данных существуют в любой среде, где модифицируются данные (то есть БД находится в состоянии READ_WRITE, в противоположность предыдущему примеру), и это совершенно нормально. SQL Server удерживает необходимые блокировки для защиты целостности данных и освобождает данные, как только отпадает необходимость в блокировке.

Краткосрочные блокировки не оказывают негативного воздействия, они – часть нормальной работы SQL Ser­ver. Проблемы возникают, когда продолжительность блокировок становится большой, то есть в несколько секунд, и в этом случае в игру вступает sp_locks.

SQL Server, объект Locks

Объект SQLServer: блокировки в Microsoft SQL Server предоставляет сведения о блокировках SQL Server , полученных для отдельных типов ресурсов. Блокировки выдаются на такие ресурсы SQL Server , как прочитанные или измененные транзакцией строки, для предотвращения одновременного использования ресурсов несколькими транзакциями. Например, если исключительная (X) блокировка получена транзакцией на строку в таблице, никакая другая транзакция не сможет изменить эту строку, пока блокировка не будет освобождена. Минимизация использования блокировок повышает параллелизм, что может улучшить общую производительность. Одновременно может отслеживаться несколько экземпляров объекта Locks , каждый из которых будет представлять собой блокировку отдельного вида ресурсов.

Как посмотреть блокировки в ms sql

Для отслеживания sql блокировок в SQL Server существует команда sp_who2. В результате выполнения данной команды мы получим список соединений с SQL Server, но вот находить блокировщиков придется вручную, анализируя колонку BlkBy.

В этой колонке мы увидим блокирующий процесс, который можно принудительно «убить» с помощью команды KILL ПРОБЕЛ SPID убиваемого процесса (напимер, KILL 22).

Скрипт для удобного использования команды sp_who2 при отслеживании sql блокировок

Однако если активных соединений с SQL Server очень много, то sql блокировки отслеживать трудно: приходится прокручивать весь список и вручную выбирать самых-самых «блокировщиков». Гораздо удобно создать временную таблицу и сделать сортировку по полю BlkBy. Готовый скрипт для обнаружения и устранения sql блокировок можно взять ниже.

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

Как узнать выполняемый блокирующим процессом скрипт или бонус к отслеживанию sql блокировок

Данную статью я решил дополнить очень, на мой взгляд, полезной вещью.

Увидели мы блокирующий процесс. А дальше что? Убить блокировщика, вызвавшего sql блокировку, всегда успеем. Но ведь нужно смотреть в корень и предупредить возникновение блокировок. А для этого надо узнать, какой скрипт выполняется под блокировщиком.

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

Для запуска процедуры выполняем команду

Команда выведет выполняемый блокировщиком код на языке TSQL, который мы с легкостью сможем проанализировать.

Удачи в отслеживании sql блокировок и отсутствия долгих транзакций!

Блокировки схемы

  • Блокировка стабильности схемы (Sch-S): эта блокировка используется, когда схема в зависимости от запроса компилируется, и генерируется ее план выполнения. (Sch-S не накладывает никаких блокировок на данные объекта.
  • Блокировка модификации схемы (Sch-M): эта блокировка является результатом выполнения запроса DDL (язык определения данных). SQL Server может иметь только одну блокировку модификации схемы на объект. Вы не можете модифицировать объект при данной блокировке схемы.
BEGIN TRAN
Alter TABLE DemoTable ADD new bit
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type  'DATABASE'
ROLLBACK

Системные хранимые процедуры

Наложенные блокировки также можно посмотреть через системные хранимые процедуры/функции SQL Server. Для просмотра текущих блокировок используется системная хранимая функция sp_lock, которая возвращает следующую информацию:

Имя колонки

Описание

spid -Идентификатор процесса SQL Server.

dbid -Идентификатор базы данных.

ObjId -Идентификатор объекта, на который установлена блокировка.

IndId -Идентификатор индекса.

Type -Тип объекта. Может принимать значения: DB, EXT, TAB, PAG, RID, KEY.

Resource — Содержимое колонки syslocksinfo.restext. Обычно это идентификатор строки (для типа RID) или идентификатор страницы (для типа PAG).

Mode -Тип блокировки. Может принимать значения: Sch-S, Sch-M, S, U, X, IS, IU, IX, SIU, SIX, UIX, BU, RangeS-S, RangeS-U, RangeIn-Null, RangeIn-S, RangeIn-U, RangeIn-X, RangeX-S, RangeX-U, RangeX-X.

Status -Статус процесса SQL Server. Может принимать значения: GRANT, WAIT, CNVRT.

На рисунке 7 представлен пример использования функции sp_lock. На нем видно, что на три записи наложена совмещаемая блокировка типа KEY, это ключи выбираемых записей. Если вызывать функцию sp_lock без параметров, то она вернет абсолютно все блокировки всех процессов. Можно вывести блокировки только определенных процессов, передав идентификаторы процессов через запятую. Например, вызвав exec sp_lock 55, Мы выведем блокировки только процесса с идентификатором 55 (см. Рис. 7).

SQL Server имеет также функции sp_who и sp_who2 для просмотра активных в данный момент процессов. Разница между этими функциями только в составе выдаваемых данных, sp_who2 выдает больше информации. С помощью этой функции мы можем увидеть какие процессы в данный момент активны и в каком они состоянии. Нас прежде всего интересует состояние блокировки процессов, которые можно увидеть с помощью этой функции.

Sp_who2 показывает, все блокировки на том экземпляре SQL Server, где имеются проблемы. Запуск sp_who2 на проблемном сервере показывает, что там действительно есть заблокированные процессы, как следует из поля BlkBy в результатах процедуры, см. Рис. 8.

Можно с первого взгляда наглядно определить, что SPID 56 заблокирован SPID 54.

sp_who2 возвращает результирующий набор со следующими сведениями:

Имя колонки

Описание

SPID -Идентификатор процесса SQL Server.

Status — Состояние процесса

Login -Имя входа процесса

HostName -Имя хоста, который инициировал процесс

BlkBy -Идентификатор процесса, заблокировавший текущий процесс

DBName -Имя БД, к которому обратился процесс

Command -Исполняемая процессом команда или имя системного процесса ядра СУБД

CPUTime -Время выполнения процесса

DiskIO -Количество операций чтения/записи с диска

LastBatch -Время последнего вызова удаленной хранимой процедуры или инструкции EXECUTE клиентским процессом.

ProgramName -Имя приложения

REQUESTID -Идентификатор запроса. Применяется для идентификаций запросов, выполняемых в текущем сеансе.

Шаг 4.

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

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

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

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

Подробнее о блокировках данных можно прочитать в статье «Блокировки данных в 1С:Предприятии 8» (https://kb.1c.ru/articleView.jsp?id=30).

Подробнее о типичных причинах избыточных блокировок можно прочитать в статье «Типичные причины избыточных блокировок и методы оптимизации» (https://kb.1c.ru/articleView.jsp?id=45).

1.5.3. Ключи

Ограничение PRIMARY KEY определяет первичный ключ таблицы, который уникально идентифицирует строку. Это гарантирует целостность таблицы. Когда мы изучали оператор PRIMARY KEY, то уже видели примеры и мне добавить нечего. Давайте только сведем все вышесказанное, чтобы увидеть свойства первичного ключа:

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

Ограничение FOREIGN KEY (внешний ключ) гарантирует ссылочную целостность. Ограничение внешнего ключа определяет ссылку на колонку с первичным ключом или уникальную колонку в этой же или другой таблице. С помощью такого ключа обеспечивается целостность связей между таблицами.

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

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

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

Опция REFERENCE команд CREATE TABLE и ALTER TABLE поддерживаю опции ON DELETE и ON UPDATE. Эти опции позволят вам указать опции CASCADE и NO ACTION:

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

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

Просмотр блокировок в Microsoft SQL Server

В SQL Server существует достаточно много различных DMV, для просмотра блокировок основной DMV является sys.dm_tran_locks, однако, чтобы получить дополнительную информацию по блокировкам, и отобразить ее в более понятном виде, мы будем обращаться еще и к другим DMV.

Ниже представлен запрос, который отображает Ваши (по ORIGINAL_LOGIN) текущие заблокированные запросы.

Описание столбцов результирующего набора данного запроса, а также описание источников, представлено чуть ниже, после самого запроса.

  
  SELECT 
                = TL.request_status,
              = TL.request_mode,
              = DB.name,
             = OBJECT_NAME(P.object_id),
             = I.name,
          = TL.resource_type,
             = TAT.transaction_begin_time,
          = CONVERT(VARCHAR, DATEADD(MS, WT.wait_duration_ms, 0), 108), -- hh:mm:ss
             = TL.request_session_id,
     = WT.blocking_session_id,
             = ES.original_login_name,
     = ESB.original_login_name,
               = RST.text,
       = BST.text,
           = ES.program_name
  FROM       sys.dm_tran_locks               AS TL
  INNER JOIN sys.databases                   AS DB  ON DB.database_id      = TL.resource_database_id
  INNER JOIN sys.dm_exec_sessions            AS ES  ON ES.session_id       = TL.request_session_id
  LEFT  JOIN sys.partitions                  AS P   ON P.hobt_id           = TL.resource_associated_entity_id
  LEFT  JOIN sys.indexes                     AS I   ON I.object_id         = P.object_id 
                                                   AND I.index_id = P.index_id
  LEFT  JOIN sys.dm_os_waiting_tasks         AS WT  ON WT.resource_address = TL.lock_owner_address
  LEFT  JOIN sys.dm_exec_sessions            AS ESB ON ESB.session_id      = WT.blocking_session_id
  LEFT  JOIN sys.dm_exec_connections         AS EC  ON EC.session_id       = TL.request_session_id
  LEFT  JOIN sys.dm_exec_connections         AS ECB ON ECB.session_id      = WT.blocking_session_id
  LEFT  JOIN sys.dm_tran_active_transactions AS TAT ON TL.request_owner_id = TAT.transaction_id 
                                                   AND TL.request_owner_type = 'TRANSACTION'
  OUTER APPLY sys.dm_exec_sql_text (EC.most_recent_sql_handle)  AS RST
  OUTER APPLY sys.dm_exec_sql_text (ECB.most_recent_sql_handle) AS BST
  WHERE (
         ES.original_login_name  = ORIGINAL_LOGIN() -- Свои процессы
         OR
         ESB.original_login_name = ORIGINAL_LOGIN() -- Процессы, которые заблокировали мы сами
	 )
	  AND TL.resource_database_id = DB_ID()     -- В рамках текущей база дынных
	  AND WT.blocking_session_id IS NOT NULL    -- Только заблокированные процессы
  ORDER BY  DESC
  GO

Описание столбцов:

  • – текущее состояние запроса. WAIT означает, что запрос заблокирован и ожидает ресурса
  • – тип блокировки
  • – имя базы данных
  • – имя таблицы
  • – имя индекса
  • – тип ресурса, на который накладывается блокировка
  • – время начала транзакции
  • – время нахождения процесса в заблокированном состоянии в формате hh:mm:ss
  • – идентификатор сессии, которая запустила инструкцию
  • – идентификатор сессии, которая заблокировала инструкцию
  • – имя входа (по ORIGINAL_LOGIN), которое запустило инструкцию
  • – имя входа (по ORIGINAL_LOGIN), которое заблокировало инструкцию
  • – текст SQL инструкции
  • – текст SQL инструкции, которая блокирует текущую инструкцию
  • – имя приложения, откуда пришел запрос

Описание источников:

  • dm_tran_locks – возвращает сведения об активных в данный момент в SQL Server ресурсах диспетчера блокировок
  • sys.databases – системное представление, возвращающее информацию о базах данных на сервере
  • sys.dm_exec_sessions – возвращает сведения обо всех активных подключениях пользователей и внутренних задачах
  • sys.partitions – отображает информацию о секциях всех таблиц и большинства типов индексов базы данных. Считается, что все таблицы и индексы в SQL Server содержат как минимум одну секцию, даже если они явно не секционированы
  • sys.indexes – отображает информацию об индексах
  • sys.dm_os_waiting_tasks – возвращает сведения об очереди задач, ожидающих освобождения определенного ресурса
  • sys.dm_exec_connections – возвращает сведения о соединениях, установленных с данным экземпляром SQL Server
  • sys.dm_tran_active_transactions – возвращает данные о транзакциях для экземпляра SQL Server
  • sys.dm_exec_sql_text – табличная функция, возвращающая текст SQL пакета, который идентифицируется по sql_handle.

На сегодня это все, надеюсь, данный скрипт будет Вам полезен!

Нравится12Не нравится

Using blocked process threshold option to monitor SQL Server blocking problems

We can use the blocked process threshold option to report a blocked query wait time over the specified value. By default, this option is disabled, and to enable this option we need to use the sp_configure system procedure. Microsoft recommends setting this value to at least 5 seconds. With the help of the following query, we can enable this option and set it 10 seconds.

1
2
3
4
5
6
7
8
9

EXECsp_configure’show advanced options’,1;

GO

RECONFIGURE;

GO

EXECsp_configure’blocked process threshold’,10;

GO

RECONFIGURE;

GO

EXECsp_configure’blocked process threshold’

After enabling the blocked process threshold option, we need to create an extended event session that reports the blocked process. To do this we need to use the blocked_process_session event. Firstly, we right-click on the Sessions folder that is located under the Management node and then click New Session Wizard.

On the Set Session Properties window, we will give a name to our session and then click Next.

We chose the “Do not use a template” option and skip the Choose Template screen.

We filter the blocked_process_report event and add it to the Selected events. To quickly create the extended event session, we will click the Finish button. We can see a captured event on the Watch Live Data screen when we simulate a blocked process.

On the last screen of the extended event, we click the Start the event session immediately and Watch live data on screen as it is captured. So that, the session starts immediately and the Watch Live Data screen will appear.

The blocked processes will be captured by this session but their wait time must be over the blocked process threshold.

The blocked_process field shows an XML report. This report includes all details about the blocking and blocked processes.

Режимы блокирования

  • Разделяемые блокировки:
    • При этой блокировке SQL Server позволяет другим сессиям выполнять операции для чтения блокированных данных. Однако препятствует обновлению пока блокировка активна.
    • Множество транзакций может накладывать разделяемую блокировку в одно и то же время на строку или страницу.
    • Это обычная блокировка, которую вы наблюдаете на объектах вашей базы данных.

динамическое административное представление

BEGIN TRAN
SELECT * FROM . WITH (HOLDLOCK)
WHERE CustomerID=1
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type  'DATABASE'
ROLLBACK

  • Эксклюзивные (X) блокировки:
    • SQL Server использует эксклюзивную блокировку (X-блокировка) для операций DML (Delete, Insert или Update), требующих модификацию строки или страницы данных.
    • Она предотвращает доступ других пользователей к ресурсу пока наложена блокировка.
    • SQL Server может может иметь только одну эксклюзивную блокировку на странице или строке в пределах транзакции.
BEGIN TRAN
UPDATE . 
SET Suffix='Mr.'  
WHERE CustomerID=1
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type  'DATABASE'
ROLLBACK

  • Блокировки обновления (U):
    • Блокировка обновления подобна эксклюзивной блокировке. Она может накладываться на запись, имеющую разделяемую блокировку.
    • Блокировка обновления накладывает другую разделяемую блокировку на конкретную строку. Как только записи смогут модифицироваться, SQL Server преобразует блокировку обновления в эксклюзивную блокировку.
    • SQL Server не может наложить разделяемую блокировку на ресурс с блокировкой обновления.
    • Вы можете также использовать WITH UPDLOCK для принудительной блокировки обновления.
BEGIN TRAN
SELECT * FROM . WITH (UPDLOCK)
WHERE CustomerID=1
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type  'DATABASE'
ROLLBACK

  • Блокировки с намерением (Intent locks):
    • Их назначение — информировать транзакцию о намерении запросить блокировку. Это имеет место, когда транзакция требует разделяемую или эксклюзивную блокировку на ресурсы ниже в иерархии.
    • Транзакция не позволяет другим транзакциям получить эксклюзивную блокировку на таблицу, использующую блокировку с намерением.
    • Типы блокировок с намерением перечислены ниже.
      • Разделяемая блокировка с намерением (IS): указывает, что SQL Server намерен прочитать ресурсы ниже в иерархии, запрашивая разделяемую блокировку индивидуально на эти ниже находящиеся в иерархии ресурсы.
      • Эксклюзивная блокировка с намерением (IX): указывает, что SQL Server намерен модифицировать ресурсы ниже в иерархии, получая эксклюзивную блокировку на эти ниже находящиеся в иерархии ресурсы.
      • Блокировка обновления с намерением (IU): может запрашиваться только на уровне страницы для ресурсов ниже в иерархии, и по завершению обновления преобразуется в IX-блокировку.

Как посмотреть блокировки в Microsoft SQL Server

Всем привет! Сегодня мы поговорим о том, как посмотреть блокировки в Microsoft SQL Server, в материале представлен готовый скрипт на T-SQL, который показывает информацию о блокировках в удобном и понятном виде.

Введение

В Microsoft SQL Server посмотреть блокировки можно несколькими способами, например:

  • с помощью системных хранимых процедур
  • с помощью Dynamic Management Views (DMV)

К числу системных хранимых процедур, с помощью которых можно посмотреть блокировки и текущие процессы, можно отнести:

  • sp_lock
  • sp_who
  • sp_who2

Однако данные процедуры уже немного устарели, даже сам Microsoft для просмотра блокировок рекомендует использовать Dynamic Management Views (DMV – динамические административные представления).

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

Dynamic Management Views (DMV) – это динамические административные представления, возвращающие данные о состоянии сервера, которые можно использовать для контроля исправности экземпляра SQL Server, диагностики проблем и настройки производительности.

Просмотр блокировок в Microsoft SQL Server

В SQL Server существует достаточно много различных DMV, для просмотра блокировок основной DMV является sys.dm_tran_locks, однако, чтобы получить дополнительную информацию по блокировкам, и отобразить ее в более понятном виде, мы будем обращаться еще и к другим DMV.

Ниже представлен запрос, который отображает Ваши (по ORIGINAL_LOGIN) текущие заблокированные запросы.

Описание столбцов результирующего набора данного запроса, а также описание источников, представлено чуть ниже, после самого запроса.

Описание столбцов:

  • – текущее состояние запроса. WAIT означает, что запрос заблокирован и ожидает ресурса
  • – тип блокировки
  • – имя базы данных
  • – имя таблицы
  • – имя индекса
  • – тип ресурса, на который накладывается блокировка
  • – время начала транзакции
  • – время нахождения процесса в заблокированном состоянии в формате hh:mm:ss
  • – идентификатор сессии, которая запустила инструкцию
  • – идентификатор сессии, которая заблокировала инструкцию
  • – имя входа (по ORIGINAL_LOGIN), которое запустило инструкцию
  • – имя входа (по ORIGINAL_LOGIN), которое заблокировало инструкцию
  • – текст SQL инструкции
  • – текст SQL инструкции, которая блокирует текущую инструкцию
  • – имя приложения, откуда пришел запрос

Описание источников:

  • dm_tran_locks – возвращает сведения об активных в данный момент в SQL Server ресурсах диспетчера блокировок
  • sys.databases – системное представление, возвращающее информацию о базах данных на сервере
  • sys.dm_exec_sessions – возвращает сведения обо всех активных подключениях пользователей и внутренних задачах
  • sys.partitions – отображает информацию о секциях всех таблиц и большинства типов индексов базы данных. Считается, что все таблицы и индексы в SQL Server содержат как минимум одну секцию, даже если они явно не секционированы
  • sys.indexes – отображает информацию об индексах
  • sys.dm_os_waiting_tasks – возвращает сведения об очереди задач, ожидающих освобождения определенного ресурса
  • sys.dm_exec_connections – возвращает сведения о соединениях, установленных с данным экземпляром SQL Server
  • sys.dm_tran_active_transactions – возвращает данные о транзакциях для экземпляра SQL Server
  • sys.dm_exec_sql_text – табличная функция, возвращающая текст SQL пакета, который идентифицируется по sql_handle.

Как проверить, заблокирована ли таблица на sql server

У меня есть большой отчет, который я запускаю на сервере sql. Бег занимает несколько минут. Я не хочу, чтобы пользователи дважды нажимали кнопку «Выполнить». Поскольку я оборачиваю всю процедуру в транзакцию, как мне проверить, заблокирована ли таблица транзакцией? В таком случае я хотел бы вернуть сообщение об ошибке «создание отчета, повторите попытку через несколько минут».

Как этого добиться?

6 ответов

А еще лучше подумайте о sp_getapplock , который предназначен для этого. Или используйте SET LOCK_TIMEOUT

В противном случае вам придется что-то делать с sys.dm_tran_locks который я бы использовал только для DBA, а не для пользовательского параллелизма.

Вы можете использовать представление sys.dm_tran_locks , которое возвращает информацию о текущие активные ресурсы диспетчера блокировок.

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

sys.dm_tran_locks содержит информацию о блокировке сеансов.

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

Если вы заинтересованы в поиске и имени входа пользователя, и выполняемого запроса

Для получения дополнительной информации запрос блокировки

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

Самый простой способ проверить, заблокирована ли таблица, — обновить поле в этой таблице. Если таблица заблокирована, вы получите сообщение об ошибке, подобное этому:

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

Вы когда-нибудь забывали запереть дверь в свой дом? единственный способ проверить, ЗАБЛОКИРОВАНА ли дверь — это вручную проверить, открывается ли дверь . это лучший способ, которым я могу это описать.

Заключение

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

– журналы приложений (логи);

– штатные средства MS SQL Server.

Также кратко затронули, как пользоваться инструментами диагностики взаимоблокировок:

– MS SQL Profiler;

– регистрация блокировок в журнале MS SQL Server;

– использование системных хранимых процедур sp_lock, sp_who2.

Для быстрого обнаружения лучше всего использовать журналы приложения и счетчики производительности.

Штатные средства MS SQL Server лучше использовать при диагностике и исправлении проблем с взаимоблокировками.

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

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

Автор статьи: Николай Иванов, Старший Разработчик, ITA Labs

Понравилась статья? Поделиться с друзьями:
Быть в курсе нового
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: