Что означает exec sp_reset_connection в Sql Server Profiler?

Пытаемся понять, что Sql Profiler означает, испуская sp_reset_connection.

У меня есть следующая строка «exec sp_reset_connection», за которой следуют BatchStarting и Completed,

RPC:Completed       exec sp_reset_connection
SQL:BatchStarting   SELECT [c].[TestID] AS [TestID], [c].[Description] AS [Description] FROM [dbo].[Test] AS [c]
SQL:BatchCompleted  SELECT [c].[TestID] AS [TestID], [c].[Description] AS [Description] FROM [dbo].[Test] AS [c]

В принципе, первая строка «exec sp_reset_connection» означает, что весь процесс (мое соединение было открыто, запускается select stmt, затем соединение закрывается и возвращается обратно в пул) просто происходит? Или мое подключение все еще находится в стадии разработки.

И почему sp_reset_connection выполняется до моего собственного оператора select, не должен ли сброс происходить после пользовательского sql?

Я пытаюсь узнать, есть ли способ узнать более подробно, когда соединение открывается и закрывается?

Означает ли это, что мое соединение закрыто, увидев "exec sp_reset_connection"?


sql-server database-connection sql-server-profiler sp-reset-connection
person Ray    schedule 13.03.2009    source источник

Ответы (3)


arrow_upward
206
arrow_downward

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

Блог Джимми Мэйса MSDN сказал:

sp_reset_connection НЕ сбрасывает уровень изоляции транзакции до серверного значения по умолчанию из настроек предыдущего соединения.

ОБНОВЛЕНИЕ. Начиная с SQL 2014, для клиентских драйверов с TDS версии 7.3 или выше уровни изоляции транзакций будут сброшены до значений по умолчанию.

ref: SQL Server: утечки уровня изоляции через объединенные соединения

Вот дополнительная информация:

Что делает sp_reset_connection?

Все уровни API доступа к данным, такие как ODBC, OLE-DB и System.Data.SqlClient, вызывают (внутреннюю) хранимую процедуру sp_reset_connection при повторном использовании соединения из пула соединений. Это делается для сброса состояния соединения перед его повторным использованием, однако нигде не задокументировано, что именно сбрасывается. В этой статье делается попытка задокументировать те части подключения, которые сбрасываются.

sp_reset_connection сбрасывает следующие аспекты подключения:

  • Все состояния и номера ошибок (например, @@ error)

  • Останавливает все EC (контексты выполнения), которые являются дочерними потоками родительского EC, выполняя параллельный запрос

  • Ожидает любых невыполненных операций ввода-вывода, которые являются невыполненными

  • Освобождает любые удерживаемые буферы на сервере при подключении

  • Разблокирует любые буферные ресурсы, используемые соединением.

  • Освобождает всю выделенную память, принадлежащую соединению

  • Очищает все рабочие или временные таблицы, созданные при подключении.

  • Убивает все глобальные курсоры, принадлежащие соединению

  • Закрывает все открытые дескрипторы SQL-XML, которые открыты

  • Удаляет все открытые рабочие таблицы, связанные с SQL-XML

  • Закрывает все системные таблицы

  • Закрывает все пользовательские таблицы

  • Сбрасывает все временные объекты

  • Прерывает открытые транзакции

  • Дефекты распределенной транзакции при зачислении

  • Уменьшает счетчик ссылок для пользователей в текущей базе данных, что освобождает общие блокировки базы данных

  • Освобождает приобретенные замки

  • Освобождает любые приобретенные ручки

  • Сбрасывает все параметры SET до значений по умолчанию

  • Сбрасывает значение @@ rowcount

  • Сбрасывает значение идентичности @@

  • Сбрасывает любые параметры трассировки на уровне сеанса с помощью dbcc traceon ()

  • Сбрасывает CONTEXT_INFO на NULL в SQL Server 2005 и новее [не является частью исходной статьи]

sp_reset_connection НЕ сбрасывается:

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

  • Роли приложений, введенные с использованием sp_setapprole, поскольку до SQL Server 2005 невозможно было восстановить роли приложений. Начиная с SQL Server 2005, роли приложений можно было восстанавливать, но только с дополнительной информацией, которая не является частью сеанса. Перед закрытием соединения роли приложения необходимо вручную вернуть через sp_unsetapprole, используя значение cookie, которое фиксируется при выполнении sp_setapprole.

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

person ram    schedule 27.05.2010
comment
Хорошая мысль о включении сюда важной информации. Ваша вторая ссылка теперь мертва. - person Nick Chammas; 04.01.2012
comment
он также вызывает событие Audit Login / Audit Logout, которое отображается в SQL Server Profiler и запускает для них соответствующие триггерные события. Похоже, что клиент отключился и снова подключился, хотя на самом деле этого не произошло. Из-за этого я какое-то время гнался за своим хвостом, поэтому, хотя я позволил людям сейчас - person Martin; 01.02.2012
comment
Сбрасывает ли я то, что я вставил в CONTEXT_INFO? - person Robert Niestroj; 22.06.2012
comment
Фактически, роли приложения можно вернуть с помощью sys.sp_unsetapprole - просто его нужно вызвать вручную перед закрытием соединения (возвращением соединения обратно в пул). - person YS.; 27.06.2012
comment
@RobertNiestroj Более ранние версии (определенно SQL Server 2000) не сбрасывали CONTEXT_INFO. Это привело нас к необходимости выполнения определенных шагов, прежде чем мы удалим какое-либо соединение, чтобы очистить CONTEXT_INFO вручную. Недавно я заметил, что, по крайней мере, в SQL Server 2008 R2 исправлена ​​ошибка; CONTEXT_INFO очищается автоматически. - person Ian Boyd; 24.01.2013
comment
@IanBoyd Я только что тестировал SQL Server 2005 SP3, и он действительно сбрасывает CONTEXT_INFO на NULL. Я дополню ответ этой подробностью. И чего бы это ни стоило, я действительно подтвердил, что TRANSACTION ISOLATION LEVEL не сброшен. - person Solomon Rutzky; 16.05.2015
comment
Вы знаете, действительно ли sp_reset_connection передается по сети в виде отдельного заявления? У меня смутное воспоминание, что это просто флаг в сообщениях TDS (?), Чтобы избежать дополнительных накладных расходов на его синтаксический анализ и обращение с ним как с «нормальным» процессом, который нужно выполнить. Я не уверен, откуда у меня эта идея ... и еще не вытащил wirehark, чтобы проверить это. - person Rory; 09.11.2016
comment
@Rory выглядит так, как будто он явно называется linksource.microsoft .com / # System.Data / System / Data / - person Dan Def; 29.03.2017
comment
@Rory по словам Боба Бошемина (SQL Server и соединения в пуле или соединения без пула): первый выполненный пакет SQL приводит к установке бита RESETCONNECTION в первом отправляемом пакете TDS. Кроме того, ссылочный код, связанный Дэном, вводит в заблуждение: он просто сообщает, что следует делать в потоке TDS, но не выполняет физический вызов. См. linksource.microsoft.com/#System.Data / System / Data / и прокрутите немного вниз, чтобы увидеть фактический установленный бит. - person Solomon Rutzky; 16.11.2017
comment
@DanDef Этот ссылочный код, на который вы ссылаетесь, вводит в заблуждение: он просто сообщает, что следует делать в потоке TDS, но не выполняет физический вызов. См. linksource.microsoft.com/#System.Data / System / Data / и прокрутите немного вниз, чтобы увидеть фактический установленный бит. - person Solomon Rutzky; 16.11.2017
comment
Также интересно отметить, что пул соединений, предоставляемый ADO.net и OLE DB, будет пытаться выполнить сбросить соединение, когда соединение извлекается из пула. Если соединение использовало роль приложения: RESET не только не вернет контекст, но и сервер разорвет соединение и зарегистрирует ошибку в журнале сервера: Error: 18059, Severity: 20, State: 1. The connection has been dropped because the principal that opened it subsequently assumed a new security context, and then tried to reset the connection under its impersonated security context. - person Ian Boyd; 04.02.2019
comment
@IanBoyd Я только что обновил этот последний пункт, чтобы уточнить, что проблема не в том, что использовалась роль приложения, а в том, что она не была вручную возвращена до того, как приложение закроет соединение (т.е. вернет его в пул). Я не уверен, что sp_reset_connection выдаст общий REVERT для отмены EXECUTE AS, поскольку для этого не требуется значение cookie и не будет ошибки, если нет контекста, из которого можно было бы вернуться. Тем не менее, Module Signing - это гораздо лучший выбор, поскольку он более безопасен, более детализирован и не требует возврата: - ). - person Solomon Rutzky; 13.12.2019

arrow_upward
22
arrow_downward

Это признак того, что используется пул соединений (что хорошо).

person Mitch Wheat    schedule 13.03.2009

arrow_upward
10
arrow_downward

Однако обратите внимание:

Если вы запускаете SET TRANSACTION ISOLATION LEVEL в хранимой процедуре или триггере, когда объект возвращает управление, уровень изоляции сбрасывается до уровня, действовавшего на момент вызова объекта. Например, если вы устанавливаете REPEATABLE READ в пакете, а затем этот пакет вызывает хранимую процедуру, которая устанавливает уровень изоляции на SERIALIZABLE, установка уровня изоляции возвращается к REPEATABLE READ, когда хранимая процедура возвращает управление пакету.

http://msdn.microsoft.com/en-us/library/ms173763.aspx

person SAO    schedule 03.08.2011
comment
но если вы сделаете то же самое на стороне клиента, используя клиентские методы, он не сбрасывается ... - person Softlion; 17.08.2013