Ошибки тайм-аута SQL - PullRequest
0 голосов
/ 27 мая 2009

У меня проблема только с одним из 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 лет без проблем, и мы некоторое время ничего не меняли на наших серверах - это начало происходить во время Рождества, но с тех пор оно становится все более и более регулярным.

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

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

Заранее спасибо!

Карл. * * Тысяча двадцать-одна

Ответы [ 4 ]

1 голос
/ 27 мая 2009

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

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

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

MAX POOL SIZE=2;

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

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

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
0 голосов
/ 12 апреля 2011

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

0 голосов
/ 27 мая 2009

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

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

0 голосов
/ 27 мая 2009

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

...