2016-02-24 3 views
0

Мы перенесли часть старого программного обеспечения на новый сервер. Ранее мы использовали SQL Server 2008 Enterprise, и теперь мы используем SQL Server 2014 Enterprise на новой машине, поэтому теперь она должна быть быстрее.Изменение значения CommandTimeout по умолчанию

Старое программное обеспечение является устаревшим программным обеспечением и истекает, поэтому я не хочу прилагать много усилий для его исправления. Но по какой-то причине существует функция C#, в которой выполняется запрос SQL к базе данных, для которой я получаю сообщение об ошибке

Истек срок ожидания. Период ожидания истекает до завершения операции или сервер не отвечает.

Все, что я прочитал, это то, что я должен продлить время ожидания, используя CommandTimeout. Но, к сожалению, все работает под «context connection = true». Поэтому для восстановления этой функции потребуется небольшая работа с возможностью изменения таймаута.

И я спрашиваю себя, почему это произошло на старой машине, и это не будет на новом. Поэтому он должен что-то сделать с новой машиной или с новым движком SQL Server. Есть ли способ изменить стандартный тайм-аут в 30 секунд для команды в .NET Framework или SQL Server?

Большое спасибо за любые предложения!

ответ

0

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

Следовательно, я должен сосредоточиться на скорости сервера и настройке базы данных.

Спасибо всем, кто занимался этим вопросом!

Edit:

Я нашел решение моей проблемы, косвенно. Я не мог понять, почему выполнение заявления на новой машине занимает так много времени. Но оказалось, что оператор itselft использует переменные таблицы. Я поменял их на локальную временную таблицу в базе данных tempdb. Теперь выполнение занимает менее одной секунды, а не более 7 минут!

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

+1

Итак, это вопрос SQLCLR? Существует различие между двумя системами: SQL 2008 был связан с CLR v2.0 и .NET Framework v3.5, тогда как SQL 2014 как минимум связан с CLR 4.0 и .NET Framework 4.0, но будет использовать последнюю версию, которую вы установлен. Вам нужно дать более подробную информацию о том, что делает код, чтобы получить лучшую помощь. –

+0

Ну, это только вопрос SQLCLR косвенно, потому что .NET Framework вызывает проблему с таймаутом.Но если я беру инструкцию SQL из исходного кода и выполняю ее непосредственно в Management Studio, это занимает слишком много времени для выполнения. Так что это действительно проблема с оператором SQL (или сервером). Но, к счастью, я нашел решение (как упоминалось выше)! Но спасибо за ответ, так или иначе! –

+0

Хорошо, если это все еще занимает 7 минут вне объекта SQLCLR, то да, очевидно, что SQLCLR не проблема. Эта информация не была в Вопросе. Глядя на ваше обновление, ваша терминология сбивает с толку. Когда вы говорите «виртуальные таблицы», вы имеете в виду переменные таблицы (начиная с '@')? И когда вы говорите «пользовательская таблица в базе данных tempdb», вы имеете в виду локальную временную таблицу (начиная с '#')? Вероятно, это неверно настроенный SQL Server. Если вы разместили запрос в Вопросе, было бы легче помочь определить проблему, особенно теперь, зная, что помогло. –

0

Вы можете установить тайм-аут команды с CommandTimeout свойством:

var cmd = new SqlCommand { CommandTimeout = 60 } 
+0

Спасибо за ответ, но 'CommandTimeout' не будет работать при использовании' SqlConnection' с 'context connection = true'. И мне интересно, почему я должен изменить код, потому что он уже работал на старой машине. –

Смежные вопросы