SQL Server отключил implicit_transactions и другие параметры

Question

Я все еще немного изучаю sql server и недавно натолкнулся на запрос select в хранимой процедуре, который вызывал очень медленное заполнение набора данных в c #. Сначала я думал, что это связано с .NET, но потом нашел предложение добавить в хранимую процедуру:

отключить implicit_transactions

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

• отключить отсчет
• установить arithabort на
• установить concat_null_yields_null на
• установить ansi_nulls на
• выключить cursor_close_on_commit
• установить ansi_null_dflt_on на
• установить ansi_padding на
• установить ansi_warnings на
• установить quoted_identifier на

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

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

Редактировать: Получил, что мой ответ не закончил полностью просмотр всех вариантов, но нашел

УСТАНОВИТЕ УРОВЕНЬ ИЗОЛЯЦИИ СДЕЛКИ СЧИТАЕТСЯ НЕЗАКОННЫМ

Значительно ускорил сложные запросы, меня не волнует грязное чтение в этом случае.

Answer 1

Ой, кто-то где-то играет с огнем.

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

Например, посмотрите на следующие примеры:

set implicit_transactions on 
go
select top 10 * from sysobjects

И

set implicit_transactions off 
go
begin tran
select top 10 * from sysobjects

Они оба делают одно и то же, однако во втором утверждении совершенно ясно, что кто-то забыл совершить транзакцию. Это может быть очень сложно отследить, если у вас есть этот набор в неясном месте.

Лучшее место для получения документации для всех операторов set - это старые надежные sql серверные книги онлайн . Это вместе с небольшим количеством экспериментов в анализаторе запросов - это обычно все, что требуется для понимания большинства настроек.

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

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

Answer 2

Это страница из электронной документации по SQL Server, которая вам нужна. Он объясняет все операторы SET, которые можно использовать в сеансе. http://msdn.microsoft.com/en-us/library/ms190356.aspx

Answer 3

Одна вещь, на которую стоит обратить внимание, это то, что передается от клиента на сервер с помощью профилировщика.

У нас была странная ситуация, когда аргументы SET по умолчанию для соединения ADO заставляли SP запускаться с клиента целую вечность, что мы решили, посмотрев точно, что сервер получал от клиента, в комплекте с аргументами SET по умолчанию по сравнению с тем, что было отправлено при выполнении из SSMS. Затем мы заставили клиента передавать те же операторы SET, что и в SSMS.

Это может быть не в порядке, но это полезный метод для использования, когда SP выполняется своевременно на сервере, но не на клиенте.

Answer 4

Я думаю, вам нужно глубже изучить вашу хранимую процедуру. Я не думаю, что SET IMPLICIT_TRANSACTIONS действительно будет тем, что ускорило вашу процедуру, я думаю, что это, вероятно, совпадение.