INF: Понимание и разрешение проблем блокировок SQL Server

Переводы статьи Переводы статьи
Код статьи: 224453 - Vizualiza?i produsele pentru care se aplic? acest articol.
Развернуть все | Свернуть все

В этой статье

Аннотация

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

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

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

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

Для запросов, выполнена в транзакции длительность для которого блокировки определяется тип запроса, уровень изоляции транзакции, и используются ли подсказки блокировки в запрос. Описание подсказки блокировки, блокировка и изоляции транзакций уровни, содержатся в следующих разделах документации по SQL Server:
  • Блокировка в ядре базы данных
  • Настройка блокировки и управление версиями строк
  • Режимы блокировки
  • Совместимость блокировок
  • Уровней изоляции, основанных на управлении версиями ядра базы данных строк
  • Управление транзакциями (ядро СУБД)
После блокировки и блокирования увеличение до точки, в которых отрицательное влияние на производительность системы, обычно это по одной из по следующим причинам:
  • Идентификатор SPID удерживает блокировки на набор ресурсов для расширенной период времени перед их освобождением. Сам устраняет этот тип блокировки со временем но может привести к снижению производительности.
  • Идентификатор SPID удерживает блокировки на набор ресурсов и никогда не освобождает их. Этот тип блокировки не решается сама собой и запрещает доступ к ресурсы неограниченно долго.
В первом сценарии устраняет проблемы с блокировкой сам со временем как 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.
    В дополнение к использованию сценариев в вышеупомянутые статьи базы знаний, которые можно определить начало цепочки блокировки с помощью средств, предоставляемых через SQL Server Management Studio. Для этого воспользуйтесь одним из следующих методов:
    • Щелкните правой кнопкой мыши объект сервера, разверните узел Отчеты, разверните узел Стандартные отчеты, а затем нажмите кнопку Активность – все блокирующие транзакции. Этот отчет показывает операции, размещаемый в цепочке блокировки. Если развернуть транзакции, отчет покажет транзакции, заблокированные транзакцией head. В отчете также отображаются «Блокировка инструкции SQL» и «Инструкции SQL заблокировано».
    • Используйте DBCC INPUTBUFFER (<spid>) для поиска последней выписки, которая была отправлена SPID.</spid>
  2. Уровень вложенности транзакций и состояния процесса SPID блокирующего найти.
    Уровень вложенности SPID в транзакции Глобальная переменная @@ TRANCOUNT. Тем не менее, он может быть определен из вне Идентификатор SPID, запрашивая sysprocesses таблицы следующим образом:

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

    Также можно проверить на наличие любых долгосрочных открытых проводок существует в базе данных с помощью инструкции 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: завершено
TSQLBatchCompleted
Хранимые процедурыSP: StmtStarting
Хранимые процедурыSP: StmtCompleted

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

Определение и разрешение общие блокировки сценариев

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

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

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

Состояние

В этом столбце отображается Статус конкретного SPID. Как правило в спящем режиме состояние означает, что SPID завершила выполнение и является Ожидание приложение для передачи другого запроса или пакета. A готов к запуску, Running, или sos_scheduler_yield состояние означает, что идентификатор SPID в настоящее время обработки запроса. В Следующая таблица дает краткий перечень различных состояния значения.
Свернуть эту таблицуРазвернуть эту таблицу
СостояниеЗначение
ФонИдентификатор SPID запущен фоновый рисунок Задача, например определение взаимоблокировки.
В спящем режимеИдентификатор SPID в данный момент не выполняется. Обычно это означает, что идентификатор SPID ожидает команды из приложения.
ВыполнениеИдентификатор SPID в настоящее время выполняется на планировщик.
Готов к запускуИдентификатор SPID находится в очереди исполнителей планировщика заданий и ожидается получение времени планировщика заданий.
Sos_scheduler_yieldИдентификатор SPID был запущен, но добровольно изгибанием его временной срез на планировщик заданий позволяет другим SPID на получение времени планировщика заданий.
ПриостановленоИдентификатор SPID ожидает события, такие как или кратковременная блокировка.
ОткатИдентификатор 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 значения, обратитесь к следующей статье в Microsoft База знаний:
822101 Описание waittype и lastwaittype столбцов в таблице master.dbo.sysprocesses в SQL Server 2000 и SQL Server 2005
Для получения дополнительных сведений о sys.dm_os_wait_stats, содержатся в документации по SQL Server.

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

Waitresource

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

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

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

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

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

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

Примечание Поскольку блокирование сценариев состоит из нескольких этапов, Возможно, идентификатор SPID могут отображаться в первом разделе как начало блокировки Цепочка, но к моменту выполнения инструкции DBCC INPUTBUFFER запроса больше нет Блокирование и INPUTBUFFER не фиксируются. Это означает, что блокирование разрешается самим SPID и он может или не может быть проблемой. На этом точки, можно либо использовать быстрый версии блокирование сценариев для Убедитесь, что записи inputbuffer перед очищает (хотя по-прежнему не гарантировать) или просмотр данных профилировщика в период времени для определения запросы выполнения SPID.

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

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

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

Что искать:
  • Какие команды имеет идентификатор SPID, размещаемый в блокирующем цепочки выполнена в текущей транзакции?
    Фильтровать данные трассировки конкретного SPID, в начало цепочки блокировки (на Файл меню, нажмите кнопку Свойства; затем нажмите на Фильтры Вкладка указать значение SPID). Затем можно проверить команды его был выполнен до времени, он блокировать другие SPID. Если включить События транзакции, их можно легко определить момент запуска транзакции. В противном случае поиск Текст столбец для НАЧАЛА СОХРАНЕНИЯ ФИКСАЦИИ или ОТКАТА ТРАНЗАКЦИИ операции. Использование open_tran значение из sysprocesses таблице, чтобы перехватывать все события транзакции. Знание контекста транзакции и команд, выполняемых позволит Определите, почему SPID удерживает блокировку.

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

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

В приведенной ниже таблице сопоставляет симптомах их потенциальных причин. Номер, указанный в Сценарий столбец соответствует значению "общие блокировки Сценарии и решения» разделе ниже. В 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 секунд.В Hostname столбец в sysprocesses для SPID в начало цепочки блокировки будет совпадать с именем один из SPID, он блокируется.
50x0000> 0откат"Да".Объект сигнал предупреждения можно увидеть в трассе профилировщика для этого SPID, указывающее Ошибка времени ожидания запроса или "Отмена" или просто инструкция rollback была выдан.
60x0000> 0в спящем режимеСо временем. Когда Windows NT определяет сеанс активен не больше времени, SQL Server соединение будет разорвано.В last_batch значение в sysprocesses Это гораздо раньше текущего времени.

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

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

    Разрешение:
    Решение проблемы блокировки такого типа является поиск способы оптимизации запроса. На самом деле этот класс проблемы с блокировкой может просто быть проблемы с производительностью и требуют, чтобы заняться его таким образом. Для получения сведений об устранении определенных медленно выполняемого запроса, обратитесь к следующей статье Microsoft Knowledge Base:
    243589 Устранение неполадок медленного выполнения запросов SQL Server 7.0 или более поздней версии
    Для повышения производительности приложений Устранение неполадок, обратитесь к следующей статье базы знаний:
    224587 Устранение производительность приложений с помощью SQL Server
    Для получения дополнительных сведений см. Наблюдение за производительностью и разделы руководства по настройке Раздел документации по SQL Server 2008 на веб-узле MSDN:
    http://MSDN.Microsoft.com/en-us/library/ms187830.aspx
    Если у вас есть длительного запроса, который блокирует другие пользователи и не могут быть оптимизированы, рекомендуется переместить его из системы OLTP среда системы поддержки принятия решений.
  2. Блокирование вызвана SPID спящей, который потерял отслеживать уровень вложенности транзакции

    Этот тип блокировки часто определяется SPID в спящем режиме или ожидаются команды еще транзакций, в которой уровень вложенности (ЗНАЧЕНИЕ @@ TRANCOUNT, open_tran От sysprocesses) больше нуля. Это может произойти, если приложение испытывает время ожидания запроса или выдает cancel без выдачи также требуемое количество инструкций COMMIT или ROLLBACK. При получении SPID время ожидания запроса или "Отмена", она завершит текущего запроса и пакета, но автоматически откат или фиксации транзакции. Приложение ответственность за это, как SQL Server нельзя предполагать, что вся транзакция должен быть откат просто из-за один запрос отмены. Запрос время ожидания или "Отмена" будет отображаться как сигнал ВНИМАНИЯ события для SPID в Трассировки профайлера.

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

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

    Способы решения.

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

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

    Разрешение:

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

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

    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 и awaits результаты запуска обработки возвращенных данных. При запуске возвращающийся данных (из любого dbproc сначала отвечает--считайте dbproc1), он обрабатывает для Завершение всех данных, возвращаемый для этого dbproc. Извлекает результаты dbproc1, пока SPID1 блокируется блокировки, удерживаемые SPID2 (поскольку два запросы выполняются асинхронно на сервере). На этом этапе будет dbproc1 бесконечно ожидать больше данных. SPID2 не блокируются на блокировку, но пытается Отправьте данные клиенту, dbproc2. Тем не менее dbproc2 блокируется на dbproc1 на уровне приложений, как один поток выполнения для приложение используется в dbproc1. В результате взаимоблокировки SQL Server не удается обнаружить или решения, так как только один из задействованных ресурсов SQL Ресурс сервера.
    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 ОБНОВЛЕНИЕ или удаление операторов в одной таблице. В конечном итоге SPID1 (выполнение блокировки, удерживаемые SPID2 блокируется INSERT, UPDATE или DELETE) (выполнение SELECT). SPID2 записывает строку результата dbproc2 клиента. Dbproc2, затем пытается передать строку в буфер dbproc1, но является dbproc1 занят (оно заблокировано ждет SPID1 окончания текущего INSERT, которая является заблокированные на SPID2). В данный момент заблокирована dbproc2 на уровне приложений с dbproc1 по SPID2 которого SPID (SPID1) блокируется на уровне базы данных. Опять же, Это приводит к взаимоблокировке, SQL Server не удается обнаружить или разрешить, поскольку только один из задействованных ресурсов представляет собой ресурс SQL Server.
    В обоих примерах a и b являются фундаментальные проблемы Разработчики приложений должны знать. Они должны код приложения для обработки этих случаев соответствующим образом.

    Способы решения.

    Два надежного решения, либо запрос время ожидания или связанных соединений.

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

    Запрос изменения данных, с точки или отменена вне пользовательской транзакции будет выполнен откат. Это также может происходить как побочный эффект перезапуска компьютера клиента и его сеанса отключение. Точно так же как будет выполнен откат жертвы запроса назад. Запрос изменения данных часто не удается выполнить откат быстрее, чем изначально были применены изменения. Например если удаления, вставки или обновления Инструкция работали в час, он может получить по крайней мере час для наката назад. Это ожидаемое поведение, поскольку изменения должны быть полностью откат или бы транзакций и физическая целостность базы данных опасности. Поскольку это должно произойти, SQL Server помечает SPID в «золотые» откат состояния или (что означает, что он не может быть уничтожены или выбранный как взаимоблокировка жертвы). Это часто определяется наблюдая за выходные данные sp_who, которая может означать команду ROLLBACK. В Состояние столбец sys.sysprocesses будет указано состояние ОТКАТА, которая также появится в sp_who и вывод в мониторе SQL Server Management Studio действие.
    Разрешение:

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

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

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

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

    Разрешение:

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

    KILL 9
    						

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

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

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

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

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

Свойства

Код статьи: 224453 - Последний отзыв: 4 июня 2011 г. - Revision: 4.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
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:224453

Отправить отзыв

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com