Тайм-аут сервера SQL 2000 из C # .NET - PullRequest
Новая
       21

Тайм-аут сервера SQL 2000 из C # .NET

1 голос
/ 19 января 2010

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

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

Запрос содержит несколько объединений, но в основном это суммирует, что сделано: 

INSERT INTO ProductionDataCache
   (column1, column2, ...)
   SELECT tab1.column1, tab1.column2, tab2.column1, tab3.column1 ...
       FROM linkedserver.database.dbo.Table1 AS tab1
       JOIN linkedserver.database.dbo.Table2 AS tab2 ON (...)
       JOIN linkedserver.database.dbo.Tabl32 AS tab3 ON (...)
       ...
       WHERE tab1.productionOrderId = @id
       ORDER BY ...

Очевидно, что моей первой попыткой исправить проблему было увеличение лимита времени ожидания с первоначальных 5 минут. Но когда я прибыл в 30 минут и все еще получил тайм-аут, я начал подозревать, что происходит что-то еще. Запрос просто не переходит от выполнения менее чем за 5 минут до более чем 30 минут за ночь.

Я вывел SQL-запрос (который изначально был в коде C #) в свои журналы и решил выполнить запрос в Query Analyzer непосредственно на сервере базы данных. К моему большому удивлению, запрос был выполнен правильно менее чем за 10 секунд.

Таким образом, я изолировал выполнение SQL в простой тестовой программе и наблюдал одинаковое время ожидания запроса как на сервере, на котором изначально было запущено это решение, так и при его локальном запуске на сервере базы данных. Также я попытался создать хранимую процедуру и выполнить ее из программы, но это также истекло. Запуск его в Query Analyzer отлично работает менее чем за несколько секунд.

Кажется, проблема возникает только тогда, когда я выполняю этот запрос из программы на C #. Кто-нибудь видел такое поведение раньше и нашел для него решение?

UPDATE: Я теперь использовал SQL Profiler на сервере. Очевидное отличие состоит в том, что при выполнении запроса из программы .NET он отображается в журнале как "exec sp_executesql N'INSERT INTO ... '", но при выполнении из Query Analyzer он выполняется как обычный запрос в журнале. .

Далее я попытался подключить SQL Query Analyzer, используя того же пользователя SQL, что и программа, и это также вызвало проблему в Query Analyzer. Таким образом, кажется, что проблема возникает только при подключении через TCP / IP с использованием пользователя SQL.

1 Ответ

0 голосов
/ 19 января 2010

Есть несколько вещей для расследования; первый вариант SET; это может иметь огромное значение для некоторых запросов. Посмотрите на параметры SET в трассировке и повторите их при тестировании в Management Studio (или Query Analyzer). Обратите внимание, что вам нужно посмотреть реальный сеанс профиля, чтобы увидеть их (а не только то, что ваши журналы кода).

Следующее, на что я посмотрю, это транзакции; какую модель транзакции вы используете в своем C #? Любой? Никто? Какая изоляция? Сериализуемый? Возможно распределен? Возможно, на столе лежит какой-то неясный замок.

Конечно, если блокировка является проблемой, вы можете увидеть что-то через sp_who / sp_who2 во время выполнения запроса.

...