Войти с помощью учетной записи Майкрософт
Войдите или создайте учетную запись.
Здравствуйте,
Select a different account.
У вас несколько учетных записей
Выберите учетную запись, с помощью которой вы хотите войти.

Обзор

В этой статье термин «подключение» ссылается на один сеанс входа в систему базы данных. Для каждого подключения отображается как идентификатор сеанса (SPID). Каждый из этих SPID часто называется процессом, хотя это не отдельный процесс контекста как в обычном смысле. Вместо этого каждый SPID состоит из ресурсов сервера и структуры данных, необходимые для обслуживания запросов одно подключение от данного клиента. Отдельное клиентское приложение может иметь одно или несколько подключений. С точки зрения 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.

  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
    database_name.

Сбор данных трассировки 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:Starting

TSQL

SQL:BatchStarting


Таблица 2: Типы событий

Заголовок

События

Проводки

DTCTransaction

Проводки

Транзакция SQL

Хранимые процедуры

RPC:Completed

TSQL

SQL:BatchCompleted

Хранимые процедуры

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 завершила выполнение и ожидает приложение для передачи другого запроса или пакета. Готов к запуску, запущенили 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 описание столбцов waittype и lastwaittype в таблице master.dbo.sysprocesses в SQL Server 2000 и SQL Server 2005

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

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

Waitresource

В этом поле указывает на ресурс, который ожидает SPID. В следующей таблице перечислены распространенные форматы waitresource и их смысл:

Ресурс

Формат

Пример

Таблицы

DatabaseID:ObjectID:IndexID

TAB: 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]]

ЗАКЛАДКА: 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.

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

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

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

Что искать:

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

    Помните, что можно удалить событий и столбцов данных. Вместо того чтобы смотреть обе начала и завершения события, выберите один. Если блокирующие SPID не хранимые процедуры, удаление
    SP: запуск или SP: завершена события; SQLBatch и RPC события будут отображаться при вызове процедуры. Только просмотр событий SP при необходимости получения этого уровня детализации.

  • Какова длительность запросов для SPID, в начало цепочки блокировки?
    Если включить завершенного события выше, столбце длительность будет показывать время выполнения запроса. Это может помочь определить длительные запросы, которые приводят к блокировке. Чтобы определить, почему запрос работает медленно, просмотр ЦП, Чтениеи запись столбцов, а также событий План выполнения .

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

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

Сценарий

Waittype

Open_Tran

Статус

Это обновление позволяет устранить?

Другие симптомы

1

Ненулевое значение

> = 0

готовые к запуску

Да, после завершения запроса.

Physical_IO, Процессора и/или Memusage столбцов увеличивается со временем. Длительность запроса будет высокой, после завершения.

2

0x0000

> 0

в спящем режиме

Нет, но могут быть уничтожены SPID.

Сигнал предупреждения можно увидеть в трассе профилировщика для этого SPID, указывающее время ожидания запроса или "Отмена" произошло.

3

0x0000

> = 0

готовые к запуску

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

Если open_tran = 0 и SPID удерживает блокировки, пока уровень изоляции транзакций по умолчанию (COMMMITTED чтения), это является вероятной причиной.

4

Зависит от

> = 0

готовые к запуску

Нет. Не решит пока клиент отменяет запросы или закрытие подключения. SPID можно быть уничтожены, но может занять до 30 секунд.

Столбец имени хоста в sysprocesses для SPID, в начало цепочки блокировки будет таким же, как один SPID, он блокирует.

5

0x0000

> 0

откат

Да.

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

6

0x0000

> 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 указывает уровень вложенности транзакций один. Это было, удаления или запроса на обновление или HOLDLOCK была использована при ВЫБОРЕ, все блокировки, полученные по-прежнему удерживались. Даже при использовании вышеприведенного запроса Если другой запрос получен и удержания блокировок в транзакции, они по-прежнему удерживались при выше SELECT был отменен.

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

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

      1. В обработчике ошибок в клиентском приложении отправить IF открыть TRAN ОТКАТА следующие ошибки, даже если клиентское приложение не кажется, что транзакция является @@TRANCOUNT > 0. Это необходимо, поскольку хранимая процедура вызывается во время пакетной может запустить транзакцию без ведома клиентского приложения. Обратите внимание, что определенные условия, например Отмена запроса, запретить процедуре выполняется за пределами текущего оператора, даже если процедура содержит логику для проверки <> @@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, соответствующее клиентское приложение не извлекать все строки результата выполнения

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

    Решение:

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

  4. Блокирование причиной взаимоблокировки распределенной клиент сервер

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

    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 являются фундаментальные проблемы, с которыми разработчики приложений должны быть знакомы. Они должны кода приложений для обработки таких случаев соответствующим образом.

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

    Время ожидания запроса или связанных соединений являются две надежные решения.

    • Время ожидания запроса
      Если время ожидания запроса было предоставлено, в случае распределенной взаимоблокировки, он будет работать при затем произойдет тайм-аут. На время ожидания запроса с помощью просмотра документации ODBC или DB-Library.

    • Привязка соединений
      Эта функция позволяет клиенту с несколькими подключениями связать их в области одной транзакции, поэтому соединения не блокируют друг друга. Дополнительные сведения приведены в разделе «Использование привязки подключений» в электронной документации по SQL Server 7.0.

  5. Блокирование вызвана SPID в «Золотой» или отката, состояние

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

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

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

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

  6. Блокирование вызвана потерянного подключения

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

    Устранение неполадок потерянных подключений в SQL Server как 137983


    Решение:

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

    KILL 9


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

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

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

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

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

Нужна дополнительная помощь?

Совершенствование навыков
Перейти к обучению
Первоочередный доступ к новым возможностям
Присоединение к программе предварительной оценки Майкрософт

Были ли сведения полезными?

Насколько вы удовлетворены качеством перевода?
Что повлияло на вашу оценку?

Спасибо за ваш отзыв!

×