sql server set implicit_transactions off и другие опции

Question

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

набор implicit_transactions от

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

• набор NOCOUNT от
• набор ARITHABORT на
• набор CONCAT_NULL_YIELDS_NULL на
• набор ANSI_NULLS на
• набор CURSOR_CLOSE_ON_COMMIT от
• набор ANSI_NULL_DFLT_ON на
• множества ANSI_PADDING на
• набор ANSI_WARNINGS на
• множества QUOTED_IDENTIFIER на

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

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

Edit: Получил мой ответ не в конечном итоге полностью рассматривать все варианты, но нашел

SET TRANSACTION READ ISOLATION УРОВЕНЬ UNCOMMITTED

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

Answer 1

Это страница из SQL Server Books Online (BOL), которую вы хотите. Он объясняет все инструкции SET, которые могут использоваться в сеансе. http://msdn.microsoft.com/en-us/library/ms190356.aspx

Answer 2

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

Answer 3

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

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

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

Answer 4

Ой, кто-то, где-то играет с огнем большого времени.

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

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

set implicit_transactions on 
go 
select top 10 * from sysobjects 

И

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

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

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

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

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