Ошибки таймаута SQL

Question

У меня возникла проблема только с 1 из примерно 30 сайтов, которые мы запускаем на веб-сервере W2003.

Вероятно, около 25% рабочего дня, сайт постоянно возвращается: SQL таймаута Ошибки различных соединений к SQL (с помощью ODBC)

Я проверил и обновил драйверы ODBC к последним, что я смог найти (3.5.x?), И я также проверяю SQL-сервер, чтобы увидеть, есть ли у него проблемы (другой сервер работает в той же сети, подключенной через Gb LAN)

Файлы журнала IIS возвращают «[Microsoft] [ODBC_SQL_Server_Driver] Timeout_expired"

Утром я испытал проблему, поэтому попытался перезагрузить сервер SQL, чтобы узнать, была проблема с загрузкой или что-то в этом роде, но сайт продолжал генерировать эти ошибки в течение примерно 20 минут после перезагрузки (хотя все наши другие сайты работали на этом этапе), - тогда он прекратил тайм-аут и теперь снова работает.

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

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

Я прошел через весь код, чтобы убедиться, что соединения DB открыты или закрыты правильно (сайт классический ASP), и гарантировал, что он не открывает слишком много параллельных подключений - но все это бесполезно, и я начиная с идеи ... кто-нибудь?

Мое единственное, что нужно сделать для подключения OLEDB вместо ODBC - но прежде чем я это сделаю, я хотел проверить, что не было чего-то еще, что я пропустил, и я мог попробовать сначала.

Спасибо заранее!

Carl.

Answer 1

Планируется ли (и работает) SQL Server регулярный план обслуживания, включая восстановление индексов?

Answer 2

Поскольку вы не изменили код, нет ничего плохого в ваших подключениях.

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

Answer 3

Вы упомянули изменение тайм-аута SQL-соединений, но неясно, в какой именно момент времени: это соединение с базой данных или слишком длинные запросы?

Одним из инструментов, которые могут помочь, является профилировщик Sql. Ограничьте это для пользователя или базы данных, которая испытывает таймауты. Если длина запроса является проблемой, это должно дать вам представление о том, какие запросы выполняются долго.

Если соединение связано с тайм-аутом, проверьте текущую активность в Management Studio. Это показывает количество открытых соединений; если они большие, там, вероятно, есть утечка.Вы можете проверить, что в процессе развития, запустив со строкой соединения, которая содержит:

MAX POOL SIZE=2; 

Это приведет к течи быстро исчерпывают пул соединений.

Предложение Mitch Wheat очень хорошее, неточная статистика может действительно ухудшить производительность с течением времени. Этот запрос может сказать вам, если ваша статистика современны:

SELECT 
    object_name = Object_Name(ind.object_id), 
    IndexName = ind.name, 
    StatisticsDate = STATS_DATE(ind.object_id, ind.index_id) 
FROM SYS.INDEXES ind 
order by STATS_DATE(ind.object_id, ind.index_id) desc 

Answer 4

Если эти вещи выше не работает, я бы проверить файл подкачки (PF), использование в диспетчере задач и увидеть, где он находится. Вы можете получить ошибки тайм-аута из-за отсутствия виртуальной памяти. Если это похоже на верхнюю часть, подумайте о том, чтобы увеличить ее. Я получаю много ошибок таймаута SQL спорадически и в разных частях моего приложения. Оказалось, что это проблема производительности. Я бы порекомендовал не менее 4000 Мбайт файла страницы в зависимости от количества бара, который у вас есть на вашем сервере.