В настоящее время вы работаете в автономном режиме; ожидается повторное подключение к Интернету

INF: Понимание и устранение проблемы с блокировками в SQL Server

ВНИМАНИЕ! Данная статья переведена с использованием программного обеспечения Майкрософт для машинного перевода и, возможно, отредактирована посредством технологии Community Translation Framework (CTF). Корпорация Майкрософт предлагает вам статьи, обработанные средствами машинного перевода, отредактированные членами сообщества Майкрософт и переведенные профессиональными переводчиками, чтобы вы могли ознакомиться со всеми статьями нашей базы знаний на нескольких языках. Статьи, переведенные с использованием средств машинного перевода и отредактированные сообществом, могут содержать смысловое, синтаксические и (или) грамматические ошибки. Корпорация Майкрософт не несет ответственности за любые неточности, ошибки или ущерб, вызванные неправильным переводом контента или его использованием нашими клиентами. Подробнее об CTF можно узнать по адресу http://support.microsoft.com/gp/machine-translation-corrections/ru.

Эта статья на английском языке: 224453
Аннотация
В этой статье термин «подключение» ссылается на один сеанс входа в систему базы данных. Для каждого подключения отображается как идентификатор сеанса (SPID). Каждый из этих SPID часто называется процесс, хотя это не отдельный процесс контекст в обычном смысле. Вместо этого каждый SPID состоит из ресурсов сервера и структуры данных, необходимые для обслуживания запросов одно подключение от данного клиента. Отдельное клиентское приложение может иметь одно или несколько подключений. С точки зрения SQL Server нет различия между несколько соединений от одного клиентского приложения на одном клиентском компьютере и несколько подключений из нескольких клиентских приложений или нескольких клиентских компьютерах. Одно соединение можно блокировать другое подключение, независимо от их исходящее из того же приложения или отдельные приложения на двух различных компьютерах.
Дополнительная информация
Блокировка является неизбежной характеристика любой системы управления реляционной базой данных (RDBMS) с параллелизмом на основе блокировки. В SQL Server блокировки происходит, когда один SPID удерживает блокировку определенного ресурса и второй SPID пытается получить конфликтующие тип блокировки на тот же ресурс. Как правило период времени, для которого первая SPID блокирует ресурс очень мала. Когда он освобождает блокировку, второе подключение может получить свою собственную блокировку ресурса и продолжить обработку. Это нормальное поведение и может происходить много раз на протяжении всего курса день с не заметно влияет на производительность системы.

Контекст транзакции и длительность запроса определяют, как долго его блокировки и, таким образом, их влияние на другие запросы. Если запрос не выполняется в рамках транзакции и используется без подсказки блокировки, блокировки для инструкций SELECT будет только сохранятся на ресурс в момент, когда он фактически чтения, а не во время запроса. Для инструкций INSERT, UPDATE и DELETE блокировки удерживаются в течение всего запроса, как для целостности данных, так и для возможного отката запроса, при необходимости.

Для запросов, выполнена в транзакции длительность для которого блокировки определяется тип запроса, уровень изоляции транзакции и того, является ли блокировка подсказки используются в запросе. Описание блокировки подсказки блокировки, а также уровни изоляции транзакций, в следующих разделах электронной документации по SQL Server:
  • Блокировка в ядре СУБД
  • Настройка блокировки и управления версиями строк
  • Режимы блокировки
  • Совместимость блокировок
  • Уровни изоляции на основе управления версиями строк в ядре СУБД
  • Управление транзакциями (ядро СУБД)
После блокировки и блокирования увеличение к точке где отрицательное влияние на производительность системы, обычно является по одной из следующих причин:
  • SPID удерживает блокировки на набор ресурсов для extendedperiod времени перед их освобождением. Этот тип блокировки устраняет itselfover времени, но может привести к снижению производительности.
  • SPID удерживает блокировки на набор ресурсов и никогда не releasesthem. Этот тип блокировки не решает сам и предотвращает доступ к ресурсам theaffected до бесконечности.
В первом случае, из списка выше, блокировка разрешается сама, со временем как SPID освобождает от блокировки ресурс. Однако ситуация может быть очень зыбкой, как только другие SPID'ы вызывают блокировки на другие ресурсы со временем, создавая динамичную цель для блокировок. По этой причине такие ситуации могут быть трудноустранимыми, при использовании SQL Server Enterprise Manager или собственных запросов SQL. Вторая ситуация оканчивается согласованным состоянием, которое может быть легче диагностировано.

Сбор сведений о блокировке

Для противодействия сложности по устранению проблем блокировки проблемы, администратор базы данных можно использовать сценарии SQL, которые постоянно отслеживать состояние блокировки и блокирования в SQL Server. Эти сценарии можно предоставить моментальные снимки из определенных экземпляров со временем приведет к общую картину проблемы. Описание способов наблюдения за блокирование сценариев SQL см. ниже статьях базы знаний Майкрософт:
271509 Наблюдение за блокировки в SQL Server 2005 и SQL Server 2000
Сценарии в этой статье будет выполнять следующие задачи. Там, где это возможно, предоставляется метод для получения этой информации из среды SQL Server Management Studio.
  1. Определение SPID в начало цепочки блокировки (ID сеанса) и инструкцию SQL.
    Вышеупомянутые статьи базы знаний с помощью сценариев, youcan определить начало цепочки блокировки с помощью средств, предоставляемых через среду SQL Server Management Studio. Для этого воспользуйтесь одним из следующих способов:
    • Щелкните правой кнопкой мыши объект сервера, разверните отчеты, разверните Стандартные отчетыи выберите мероприятие — все блокирующие транзакции. Этот отчет показывает транзакции в начале блокирующей цепочки. Если развернуть транзакции, отчет покажет проводок, которые блокируются транзакцией head. В отчете также отображаются «Блокировка SQL оператор» и «Оператор SQL заблокировано».
    • Используйте DBCC INPUTBUFFER (<spid>) для поиска последней выписки, которая была отправлена SPID.</spid>
  2. Уровень вложенности транзакций и состояния процесса SPID блокирующего найти.
    Уровень вложенности транзакций SPID в глобальной переменной the@@TRANCOUNT. Тем не менее его можно определить из внешних theSPID, запрашивая sysprocesses таблицы:

    SELECT open_tran FROM master.sys.sysprocesses WHERE SPID=<blocking SPID number>go						
    Возвращаемое значение является значением @@TRANCOUNT для SPID. Это showsthe степень вложенности транзакции для блокирования SPID, которые в свою очередь могут explainwhy он удерживает блокировку. Например если значение больше нуля, theSPID, в процессе транзакции (в котором случае ожидается, что этой itretains некоторых блокирует его получил, в зависимости от isolationlevel транзакции).

    Можно также проверить на предмет любых долгосрочных открыть transactionexists в базе данных с помощью инструкции DBCC OPENTRANимя_базы_данных.

Сбор данных трассировки SQL Server Profiler

Кроме выше сведений часто оказывается необходимым для запись трассировки профайлера действий на сервере, чтобы тщательно исследование проблемы с блокировкой на SQL Server. Если SPID, выполняет несколько инструкциями в транзакции, только последняя statementthat была отправлена, будут отображаться в отчете, входной буфер или выходной файл монитора активности. Тем не менее одна из предыдущих команд может быть причина, по которой по-прежнему выполняется блокировки. Трассировки профайлера позволит вам видеть все команды, выполняемые SPID в текущей транзакции. Следующие действия позволяют настроить SQL Server Profiler для записи трассировки.
  1. Откройте SQL Server Profiler.
  2. В меню файл выделите пункт Создатьи нажмите кнопку трассировки.
  3. На вкладке Общие укажите имя трассы и имя файла для записи данных.

    Важно: Файл трассировки должны быть написаны для быстрого локального или общего диска. Избегайте трассировки для медленных дискеты или сетевого диска. Также убедитесь, что сервер обрабатывает выбранные данные трассировки.
  4. На вкладке Выбор событий щелкните Показать все события и флажок Показать все столбцы .
  5. На вкладке Выбор событий добавьте типы событий, перечисленных в таблице 1 для трассировки.

    Кроме того можно включать дополнительные типы событий, перечисленных в таблице 2 для получения дополнительной информации. При выполнении в среде с большим объемом производства можно использовать только те события, в таблице 1, как они обычно подходят для большинства проблем блокировки. Включая дополнительные события в таблице 2 может облегчить быстро определить источник проблемы (или этих событий может потребоваться определить оператор виновником переполнения буфера в процедуре нескольких инструкций). Тем не менее включая события в таблице 2 будет также добавить нагрузку на систему и увеличить размер выходных данных трассировки.
Таблица 1: Типы событий
ЗаголовокСобытия
Ошибки и предупрежденияИсключение
Ошибки и предупрежденияВнимание
Аудит безопасностиАудит входа в систему
Аудит безопасностиАудит выхода
СеансыСуществующие подключения
Хранимые процедурыRPC: запуск
TSQLSQL: BatchStarting

Таблица 2: Типы событий
ЗаголовокСобытия
ПроводкиDTCTransaction
ПроводкиТранзакция SQL
Хранимые процедурыRPC: завершено
TSQLSQL:BatchCompleted
Хранимые процедурыSP: StmtStarting
Хранимые процедурыSP: StmtCompleted

Дополнительные сведения об использовании SQL Server Profiler обратитесь электронной документации по SQL Server.

Поиск и устранение наиболее распространенных сценариев блокировки

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

Просмотр блокировки выходного файла сценария

Проанализируйте выходные данные sys.sysprocesses для определения головки блокирующих цепей
Если быстрый режим блокировки сценариев не указан, будет раздел, озаглавленный «SPID в начало цепочки блокировки» thatlists SPID, которые блокируют другие SPID в выходных данных сценария.
SPIDs at the head of blocking chains
Если указан параметр быстрого выполнения программ, по-прежнему можно определить theblocking головок взглянув на выходных sys.sysprocesses и иерархии SPID, выводится в столбце блокировки.
Проанализируйте выходные данные sys.sysprocesses сведения о SPID, в начало цепочки блокировки.
Важно оценить sys.sysprocesses следующие поля:

Статус

Этот столбец показывает статус конкретного SPID. Как правило состояние ожидания указывает, что SPID завершила выполнение и ожидает приложение для передачи другого запроса или пакета. Готов к запуску, запущенили sos_scheduler_yield показывает, что идентификатор SPID в настоящее время обработки запроса. В следующей таблице дается краткое описание различных значений состояния.
СтатусЗначение
Фоновый (Background)Процесс SPID выполняется фоновую задачу, например, определение взаимоблокировок (deadlocks).
В спящем режиме (Sleeping)Процесс SPID в данный момент не выполняется. Обычно это означает, что идентификатор SPID ожидает команды из приложения.
Запущен (Running)Процесс SPID в настоящее время выполняется планировщиком.
Готов к запуску (Runnable)Процесс SPID находится в очереди задач планировщика и ожидает своего времени для исполнения планировщиком.
Sos_scheduler_yieldПроцесс SPID был запущен, но он добровольно предоставил временный интервал другим SPID для исполнения планировщиком заданий.
Приостановлен (Suspended)Идентификатор SPID ожидает события, например или кратковременная блокировка.
Откатывается (Rollback)Процесс SPID находится в состоянии отката транзакции.
DefwakeupУказывает, что идентификатор SPID ожидает ресурс, который находится в процессе освобождается. Поле waitresource должно указывать ресурса.

Open_tran

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

Lastwaittype, waittype и waittime

Поле lastwaittype является строковое представление waittype поле, которое является зарезервированным внутреннего двоичного столбца. Если waittype 0x0000, идентификатор SPID не ожидает в данный момент ничего и значение lastwaittype указывает последнюю waittype , имеющего идентификатор SPID. Если waittype не равно нулю, значение lastwaittype указывает текущий waittype SPID.

Краткое описание различных lastwaittype и waittype значений см. следующие статьи базы знаний Майкрософт:
822101 Описание столбцов в таблице master.dbo.sysprocesses в SQL Server 2000 и SQL Server 2005 waittype и lastwaittype
Дополнительные сведения о sys.dm_os_wait_statsсодержатся в разделе электронной документации по SQL Server.

Waittime значение может использоваться для определения, если SPID продвигается. Когда запрос к таблице sys.sysprocesses возвращает значение в столбце waittime , меньше, чем в предыдущем запросе sys.sysprocesseswaittime значение, это означает, что был получат и освободят блокировку предыдущего, и ожидают новый замок (подразумевает waittime равно нулю). Это можно проверить, сравнив waitresource между sys.sysprocesses выходные данные.

Waitresource

В этом поле указывает на ресурс, который ожидает SPID. В следующей таблице перечислены распространенные форматы waitresource и их смысл:
РесурсФорматПример
ТаблицыDatabaseID:ObjectID:IndexIDTAB: 5:261575970:1
В этом случае является 5 идентификатор базы данных образец базы данных pubs и объект ID 261575970 является таблицы titles и 1 является кластеризованный индекс.
СтраницаDatabaseID:FileID:PageIDСТРАНИЦА: 5:1:104
В этом случае является 5 идентификатор базы данных pubs, файл 1 идентификатор — первичный файл данных и страница 104 — это страница, относящиеся к таблице titles .

Чтобы определить идентификатор объекта, которому принадлежит страница, команда DBCC страницы (dbid, идентификатор файла, pageid, output_option) и посмотрите на m_objId. Например:
DBCC TRACEON ( 3604 )DBCC PAGE ( 5 , 1 , 104 , 3 )
КлючDatabaseID:Hobt_id (хэш-значение для ключа индекса)КЛЮЧ: 5:72057594044284928 (3300a4f361aa)

В этом случае является 5 идентификатор базы данных Pubs, соответствует Hobt_ID 72057594044284928 без кластеризованного index_id 2 для объекта с идентификатором 261575970 (заголовки таблицы). Используйте представление каталога sys.partitions связать hobt_id конкретный индекс идентификатор и идентификатор объекта. Нет способа, чтобы удалить объект из кэша хеш ключа индекса для определенного ключа значения индекса.
СтрокиDatabaseID:FileID:PageID:Slot(row)RID: 5:1:104:3

В этом случае является 5 идентификатор базы данных pubs, файл 1 идентификатор — первичный файл данных, страница 104 — это страница, относящиеся к таблице titles и разъем 3 указывает позицию строки на странице.
КомпиляцияDatabaseID:ObjectID [[COMPILE]]TAB: 5:834102012 [[COMPILE]] — это не блокировка таблицы, а блокировка компиляции для хранимой процедуры. 5 идентификатор базы данных pubs, 834102012 идентификатор объекта хранимой процедуры usp_myprocedure. Дополнительные сведения о блокировке причиной блокировки компиляции см в статье 263889 базы знаний.
Другие столбцы

Оставшиеся sys.sysprocesses столбцы могут предоставить информацию в корень проблемы также. Их полезность варьируется в зависимости от условий возникновения проблемы. Например если проблема происходит только с определенных компьютеров (имя узла), можно определить на определенных сетевых библиотек (net_library), когда пакет последних отправленных SPID (last_batch) и т. д.
Проанализируйте выходные данные инструкции DBCC INPUTBUFFER.
Для любого SPID, в начало цепочки блокировки или с нуля anon waittype блокирование сценариев выполнит узнать, используется инструкция DBCC INPUTBUFFER текущего запроса для этого SPID.

Во многих случаях это запрос, который вызывает ожидаемого блокировки, другие пользователи удерживаться. Тем не менее если SPID в atransaction, блокировки может приобретенных ранее выполненного запроса не соответствует текущей. Таким образом следует также просмотреть выходные данные профилировщика для SPID не только inputbuffer.

Примечание Из-за блокирования сценариев состоит из нескольких этапов, он ispossible, что SPID могут отображаться в первом разделе как голову blockingchain, но к моменту выполнения инструкции DBCC INPUTBUFFER запроса, не longerblocking и INPUTBUFFER не фиксируются. Указывает, что blockingis сам разрешение для этого SPID и он может или может и не быть проблемой. В thispoint можно воспользоваться быстрой версии блокирование сценариев toensure записи inputbuffer перед очищается (хотя по-прежнему noguarantee) или просмотреть данные из времени для определения whatqueries SPID время выполнения профилировщик.

Просмотр данных профилировщика

Просмотр данных профилировщика эффективно исключительно важен для разрешения проблем блокировки. Важнее всего понимать, является то, что вы не рассмотреть все собранные; Будьте осторожны. Profiler предоставляет возможности, позволяющие эффективно изучать собранные данные. В диалоговом окне Свойства (в меню файл выберите команду Свойства), профилировщик позволяет ограничить отображаемые данные с помощью удаления столбцов данных или событий, группировки (сортировки) по столбцам данных и применения фильтров. Можно найти всей трассе или только в определенном столбце определенные значения (в меню Правка выберите команду Найти). Также можно сохранить данные профилировщика в таблицу SQL Server (в меню файл выберите команду Сохранить как и нажмите кнопку таблицы) и выполнять запросы SQL к ней.

Будьте внимательны, можно выполнить фильтрацию только на ранее сохраненный файл трассировки. Если выполнить эти шаги на активной трассировки, существует риск потери данных, собранных с момента запуска трассировки. Сохранение активной трассировки в файле или таблице (в меню файл выберите команду Сохранить как) и запустите ее снова (в меню файл выберите пункт Открыть) для продолжения. При работе с файлом сохраненную трассировку фильтрация не удаляет данные отфильтрованные, он просто не отображает все данные. Можно добавлять и удалять события и столбцы данных, необходимыми для сужения поиска.

Что искать:
  • Какие команды имеет идентификатор SPID в начало блокировки chainexecuted в текущей транзакции?
    Фильтрация данных трассировки для aparticular SPID, в начало цепочки блокировки (в меню файл выберите команду Свойства, укажите значение SPID на закладке фильтры ). Затем можно проверить предварительного выполнения будет получать сокращенные команды во время он блокировать другие SPID. Включить события theTransaction, легко можно определить момент запуска транзакции. В противном случае можно выполнить поиск текстового столбца Начало сохранить COMMIT или ROLLBACK TRANSACTIONoperations. Используйте значение из таблицы sysprocessesopen_tran для обеспечения перехватывать все события транзакции. Знание контекста транзакции и команд, выполняемых позволит вам узнать, почему SPID удерживает блокировки используется.

    Помните, что можно removeevents и столбцов данных. Выберите поиск с начала и completedevents. Если блокирующие SPID не хранимые процедуры, удалитьSP: запуск или SP: завершена события; SQLBatch и RPC события будут отображаться при вызове процедуры. Только представление whenyou событий SP нужно определить этот уровень детализации.
  • Какова длительность запросов для SPID в headof блокировки цепей?
    Если включить завершенного события выше, столбце длительность будет показывать время выполнения запроса. Это может помочь youidentify долго выполняющихся запросов, которые приводят к блокировке. Чтобы определить, почему запроса работает медленно, просмотр ЦП, Чтениеи запись столбцов, а также событий План выполнения .

Распределение общих сценариев блокировки

В приведенной ниже таблице сопоставляет симптомах их потенциальных причин. Соответствует номеру, указанному в столбце сценарий номер в разделе «Общие блокировки сценариев и разрешения» ниже в этой статье. Waittype, Open_Tranи состояние столбцы соответствуют sysprocesses сведения. Устраняет? столбец показывает, решит ли блокировка на свой собственный.

СценарийWaittypeOpen_TranСтатусЭто обновление позволяет устранить?Другие симптомы
1Ненулевое значениенастроек = 0готовые к запускуДа, после завершения запроса.Physical_IO, Процессора и/или Memusage столбцов увеличивается со временем. Длительность запроса будет высокой, после завершения.
20x0000настроек 0в спящем режимеНет, но могут быть уничтожены SPID.Сигнал предупреждения можно увидеть в трассе профилировщика для этого SPID, указывающее время ожидания запроса или "Отмена" произошло.
30x0000настроек = 0готовые к запускуНет. Не решит пока клиент выбирает все строки или закрывает подключение. SPID можно быть уничтожены, но может занять до 30 секунд.Если open_tran = 0 и SPID удерживает блокировки, пока уровень изоляции транзакций по умолчанию (COMMMITTED чтения), это является вероятной причиной.
4Зависит отнастроек = 0готовые к запускуНет. Не решит пока клиент отменяет запросы или закрытие подключения. SPID можно быть уничтожены, но может занять до 30 секунд.Столбец имени хоста в sysprocesses для SPID, в начало цепочки блокировки будет таким же, как один SPID, он блокирует.
50x0000настроек 0откатДа.Сигнал предупреждения можно увидеть в трассе профилировщика для этого SPID, указывающее время ожидания запроса произошла отмена или просто инструкция rollback был выдан.
60x0000настроек 0в спящем режимеВ конце концов. Если Windows NT определяет сеанс больше не является активным, подключение к SQL Server будет работать.Значение last_batchsysprocesses гораздо раньше, чем текущее время.

Распространенные сценарии блокировки и разрешения

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

    Разрешение:
    Решение проблемы блокировки такого типа является найти forways для оптимизации запроса. На самом деле этот класс блокирующей проблемы могут justbe проблемы с производительностью и необходимо продолжить его таким образом. Для устранения определенных медленно выполняемого запроса о обратитесь к следующей статье базы знаний Майкрософт:
    243589 Устранение неполадок медленного выполнения запросов в SQL Server 7.0 или более поздних версий
    Для performancetroubleshooting всего приложения обратитесь к следующей статье базы знаний Майкрософт:
    224587 Устранение производительности приложения с SQL Server
    Дополнительные сведения приведены в разделе Наблюдение за производительностью и разделы руководства, посвященные настройке электронной документации по SQL Server 2008 на веб-узле MSDN: Если продолжительный запрос, blockingother пользователей и не может быть оптимизирован, рассмотрите возможность перемещения из OLTPenvironment системы поддержки принятия решений.
  2. Блокирование вызвана SPID спящей потерявшем отслеживать уровень вложенности транзакций

    Этот тип блокировки часто может быть идентифицирован по SPIDthat в спящем режиме или ожидаются команды, но чьи степень вложенности транзакции (@@TRANCOUNT, open_tran от sysprocesses) больше нуля. Это может произойти, если applicationexperiences время ожидания запроса или "Отмена" без выдачи также therequired количество инструкций COMMIT и ROLLBACK. Получив SPID aquery время ожидания или "Отмена", она завершит обработку текущего запроса и пакета, butdoes не автоматического отката или фиксации транзакции. Isresponsible приложения для этого, как SQL Server нельзя рассчитывать на весь transactionmust выполнить откат только из-за один запрос отмены. Querytimeout или кнопку "Отмена" будет отображаться как сигнал ВНИМАНИЯ события для SPID в трассировке theProfiler.

    Чтобы продемонстрировать это, выполните следующие queryfrom простой анализатор запросов:

    BEGIN TRAN SELECT * FROM SYSOBJECTS S1, SYSOBJECTS S2-- Issue this after canceling querySELECT @@TRANCOUNTROLLBACK TRAN						
    Во время выполнения запроса, щелкните красный значок кнопки Отмена . После отмены запроса ВЫБЕРИТЕ @@TRANCOUNT indicatesthat уровень вложенности транзакций является одним. Если бы это была DELETE или UPDATEquery, или HOLDLOCK была использована при ВЫБОРЕ, все блокировки, полученные wouldstill сохранятся. Даже при использовании вышеприведенного запроса Если другой запрос приобретен andheld блокировок в транзакции, они по-прежнему удерживались при aboveSELECT была отменена.

    Способы разрешения:

    • Приложения должны правильно управлять уровней вложенности транзакций, или они могут вызвать проблемы с блокировкой после отмены запроса таким образом. Это можно сделать одним из нескольких способов:
      1. В обработчике ошибок в клиентском приложении отправить IF @@TRANCOUNT настроек 0 TRAN ОТКАТА следующие ошибки, даже если клиентское приложение не кажется, что транзакция является открытие. Это необходимо, поскольку хранимая процедура вызывается во время пакетной может запустить транзакцию без ведома клиентского приложения. Обратите внимание, что определенные условия, например Отмена запроса, запретить процедуре выполняется за пределами текущего оператора таким образом, даже если процедура содержит логику для проверки @@ERROR Если <> 0 и прерывании транзакции, этот код отката не будет выполняться в подобных случаях.
      2. Используйте инструкцию SET XACT_ABORT ON для подключения или в хранимых процедурах, которые начала транзакции и не Очистка следующая ошибка. В случае возникновения ошибки во время выполнения этот параметр прервать все открытые проводки и возвращения управления клиента. Обратите внимание, что следующий за оператором, который вызвал ошибку инструкции T-SQL не выполняется.
      3. Если пул соединений, используется в приложении, которое открывает соединение и выполняется небольшое число запросов перед освобождением соединения в пул, например веб-приложения, временное отключение пула подключений может помочь решить проблему, пока клиентское приложение изменяется соответствующим образом обрабатывать ошибки. Отключение пула подключений, освобождая подключения приведет к физической Выход соединения SQL Server, что на сервере выполняется откат всех открытых транзакций.
      4. Если пул соединений включен, а сервер назначения — SQL Server 2000, обновления на клиентском компьютере компонентов MDAC 2.6 или более поздней версии могут пригодиться. Эта версия компонентов MDAC добавляет код драйвера ODBC и поставщика OLE DB таким образом, подключение может быть «reset» до повторного использования. Этот вызов sp_reset_connection прерывает все транзакции, инициированных сервера (транзакции DTC, инициированные клиентское приложение не влияет), восстанавливает базу данных по умолчанию, задание параметров и т.д. Обратите внимание, что подключение не изменяется до повторного использования из пула подключений, поэтому возможно, что пользователь может открывать транзакцию и затем освобождает подключение в пул подключений, но он не может быть использован на несколько секунд, в течение, транзакция будет оставаться открытым. Если подключение не используется повторно, транзакция прервана при времени ожидания подключения и удаляется из пула подключений. Таким образом является оптимальным для клиентского приложения для отмены операции в их обработчик ошибок или использовать инструкцию SET XACT_ABORT ON во избежание подобных потенциальных задержек.
    • На самом деле этот класс блокирующей проблемы может также быть проблемы с производительностью и необходимо продолжить его таким образом. Если время выполнения запроса может снизиться, время ожидания запроса или "Отмена" может не возникать. Важно, что приложение сможет обработать значение времени ожидания или "Отмена" сценарии их возникновения, но преимущества проверки производительности запроса.
  3. Блокирование вызвана SPID, соответствующее клиентское приложение не извлекать все строки результата выполнения

    После отправки запроса на сервер, все applicationsmust немедленно извлечь все строки результата до завершения. Если приложение повышенной извлечь все строки результата, блокировки могут остаться на таблицах, блокируя otherusers. При использовании приложения, которое прозрачно отправляет на сервер SQLstatements, приложение должно выборки все строки результата. Если itdoes не (и если он не может быть настроен для этого), может быть невозможно toresolve блокирующей проблемы. Чтобы избежать проблем, можно restrictpoorly работающих приложений отчетов или решение supportdatabase.

    Разрешение:

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

    В отличие от обычной взаимоблокировки распределенной deadlockis не удается обнаружить с помощью РСУБД закрыть диспетчер. Это происходит из-за thatonly фактов одного из ресурсов участвующих во взаимоблокировке блокировки SQL Server. На уровне приложения клиента, через который SQLServer имеет элемент управления не является Theother сторона взаимоблокировки. Ниже приведены два примера как это может произойти, и возможные способы приложения можно избежать.

    1. Клиент/сервер распределенной взаимоблокировки с одного клиентского потока
      Если клиент имеет несколько открытых соединений и один поток выполнения, могут возникнуть следующие распределенной взаимоблокировки. Для краткости термин «dbproc» используется здесь относится к структуре подключения клиента.

       SPID1------blocked on lock------->SPID2  /\                         (waiting to write results           |                           back to client)  |                                 |  |                                 |                      Server side  | ================================|==================================  |     <-- single thread -->       |                      Client side  |                                 \/  dbproc1   <-------------------   dbproc2 (waiting to fetch             (effectively blocked on dbproc1, awaiting  next row)                     single thread of execution to run)								
      В случае показано выше поток приложений одного клиента имеет два открытых подключений. Он асинхронно отправляет операции SQL на dbproc1. Это означает, что он не ожидает возврата перед выполнением вызова. Приложение отправляет другой операции SQL на dbproc2 и ждет результатов для запуска обработки возвращенных данных. Начала возвращающийся данных (из любого dbproc сначала отвечает--предполагается это dbproc1), он обрабатывает до завершения всех данных, возвращаемый для этого dbproc. Он получает результаты из dbproc1, пока SPID1 блокируется блокировки, удерживаемые SPID2 (так как два запроса выполняются асинхронно на сервере). На этом этапе dbproc1 будет ждать бесконечно больше данных. SPID2 не блокируются блокировки, но пытается отправить данные клиенту, dbproc2. Тем не менее dbproc2 блокируется на dbproc1 на уровне приложений как один поток выполнения для приложения, dbproc1. Это приводит к взаимоблокировке, SQL Server не удается обнаружить или разрешить, так как только один из задействованных ресурсов представляет собой ресурс SQL Server.
    2. Клиент/сервер распределенной взаимоблокировки с потока на каждое соединение

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

      SPID1------blocked on lock-------->SPID2  /\                         (waiting on net write)        Server side  |                                 |  |                                 |  | INSERT                          |SELECT  | ================================|==================================  |     <-- thread per dbproc -->   |                      Client side  |                                 \/  dbproc1   <-----data row-------   dbproc2 (waiting on                     (blocked on dbproc1, waiting for it  insert)                         to read the row from its buffer)								
      Этот случай аналогичен примеру A, за исключением dbproc2 и SPID2 выполняется инструкция SELECT, намереваясь выполнения строки во время обработки и передачей каждой строки через буфер dbproc1 для инструкции INSERT, UPDATE или DELETE для одной таблицы. В конце концов, SPID1 (выполнение INSERT, UPDATE или DELETE) блокируется блокировки, удерживаемые SPID2 (выполнение SELECT). SPID2 записывает строку результата dbproc2 клиента. Затем пытается передать строку в буфер dbproc1 Dbproc2, но находит dbproc1 занят (он будет заблокирована, ожидая на SPID1 окончания текущего INSERT, который заблокирован на SPID2). На этом этапе dbproc2 блокируется на уровне приложения dbproc1 по SPID2 которого SPID (SPID1) блокируется на уровне базы данных. Опять же это приводит к взаимоблокировке, SQL Server не удается обнаружить или разрешить, так как только один из задействованных ресурсов представляет собой ресурс SQL Server.
    В обоих примерах A и B являются thatapplication разработчики должны быть знакомы основные проблемы. Они должны соответствующим образом кода приложений для случаев handlethese.

    Способы разрешения:

    Два надежные решения должны использовать querytimeout или связанных соединений.

    • Время ожидания запроса
      Если время ожидания запроса было предоставлено, в случае распределенной взаимоблокировки, он будет работать при затем произойдет тайм-аут. На время ожидания запроса с помощью просмотра документации ODBC или DB-Library.
    • Привязка соединений
      Эта функция позволяет клиенту с несколькими подключениями связать их в области одной транзакции, поэтому соединения не блокируют друг друга. Дополнительные сведения приведены в разделе «Использование привязки подключений» в электронной документации по SQL Server 7.0.
  5. Блокирование вызвана SPID в «Золотой» или отката, состояние

    Запрос изменения данных, будет содержать значение KILLed или canceledoutside пользовательской транзакции откатываются. Кроме того, можно occuras побочный эффект перезапуска компьютера клиента и его sessiondisconnecting сети. Аналогичным образом запроса выбран в качестве жертвы взаимоблокировки будет rolledback. Запрос изменения данных часто нельзя выполнить откат любых быстрее, чем thechanges изначально были применены. Например если UPDATEstatement, вставка или удаление работали часа, может занять по крайней мере один час для отката. Это ожидаемое поведение, поскольку изменения должны быть completelyrolled назад или becompromised бы транзакций и физическую целостность базы данных. Так, как это должно произойти, SQL Server помечает SPID в состоянии «золотой» или отката (то есть не могут быть уничтожены или выбранные как deadlockvictim). Часто это можно определить, просматривая выходные данные sp_who, который может указывать команды ОТКАТА. Столбец состояниеsys.sysprocesses покажет состояние ОТКАТА, которая также будет отображаться в выходном sp_who или монитор активности SQL Server Management Studio.
    Разрешение:

    Необходимо дождаться SPID для завершения откат thechanges, которые были сделаны.

    Если сервер выключен в выполнении данной операции, база данных будет в режиме восстановления после перезапуска и itwill являются недоступными, пока не будут обработаны все открытые операции. Startuprecovery принимает то же количество раз в транзакции в качестве timerecovery выполнения и база данных недоступна в течение этого периода. Таким образом сервер forcingthe до исправления SPID в состоянии отката будет часто becounterproductive.

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

    При перезапуске ловушки клиентского приложения или clientworkstation, сеанс на сервере может не beimmediately отменено при определенных условиях. С точки зрения сервера по-прежнему отображается отказа присутствовать и любые блокировки может по-прежнему beretained. Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:
    137983 Устранение неполадок потерянных подключений в SQL Server

    Разрешение:

    Если клиентское приложение отключил withoutappropriately очистку своих ресурсов, можно прервать SPID командой KILL usingthe. Команда KILL принимает в качестве входных данных значение SPID. Например чтобы завершить SPID 9, просто введите следующую команду:

    KILL 9						

    Примечание Команда KILL может занять до 30 секунд, из-за интервал между проверками команды KILL.

Участие приложения в проблем блокировки

Может быть тенденция сосредоточиться на серверные платформы и настройке проблем при лицевой стороной проблемы с блокировкой. Тем не менее это не обычно приводит к разрешению и могут поглощают время и энергию лучше направлены на изучение клиентского приложения и запросы, которые он отправляет. Независимо от того, какой уровень видимости приложение предоставляет относительно базы данных вызова, блокирующей проблемы тем не менее часто требует проверки точное инструкций SQL, отправленные приложением и точное поведение приложения относительно отмены запроса управления подключением, получение всех строк результирующего и т. д. Если средство разработки не допускает явного управления Управление подключениями, отмену запросов, время ожидания запроса, результат выборки и так далее, нельзя разрешить проблемы с блокировками. Эту возможность следует подробный анализ перед выбором средство разработки приложений для SQL Server, особенно для сред с критически OLTP.

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

Надлежащее применение и конструктор запросов Microsoft SQL Server может поддерживать несколько тысяч пользователей на одном сервере, с немного блокировки.

Внимание! Эта статья переведена автоматически

Свойства

Номер статьи: 224453 — последний просмотр: 02/09/2016 02:52:00 — редакция: 6.0

Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 Workgroup, Microsoft SQL Server 2000 Developer Edition, Microsoft SQL Server 2000 Enterprise Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Workgroup

  • kbsqlsetup kbhowto kbtshoot kbexpertiseinter kbinfo kbmt KB224453 KbMtru
Отзывы и предложения