Классическое приложение ASP, испытывающее на сервере SQL Server «тайм-ауты» и «SQL Server не существует или доступ запрещен»

Question

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

Пару раз в день мы будем видеть периоды, когда веб-страницы начинают выдавать «Истекло время ожидания [[Microsoft] [Драйвер SQL Server ODBC]», а вскоре после этого начинают выбрасываться страницы »[Microsoft] [Драйвер ODBC SQL Server] [DBNETLIB ] SQL Server не существует или доступ запрещен. "

У нас есть много разных приложений, которые подключаются к этому серверу базы данных. В среднем около 2500 одновременных соединений обрабатывают в среднем 10000 транзакций в секунду. Большинство наших приложений не имеют никаких проблем, кажется, что проблемы возникают только на веб-сервере. (Возможно, это связано с пулом соединений?)

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

Я подумал, что, возможно, возникла проблема с IP-подключением, поэтому я изменил ConnectionString, чтобы использовать IP-адрес, и запустил несколько длительных эхо-запросов. Я получил 0 пакетов между веб-сервером и сервером базы данных.

Строка подключения ASP теперь выглядит следующим образом:

Provider=MSDASQL; Driver={SQL Server}; Server=10.0.100.100; Database=DBName; UID=WebUserName; PWD=WebUserPassword; ConnectionTimeout=15; CommandTimeout=120;

Пользователь, не являющийся пользователем домена, подключается с использованием аутентификации Sql Server. Так что я не думаю, что это проблема, связанная с доменом. Я проверил файлы журналов сервера SQL и не нашел ничего, что соответствовало бы инцидентам.

Я нашел другой вопрос о стеке , описывающий подобное поведение, но без разрешения.

Подробности:

• Веб-сервер: Windows 2003 Standard SP2, IIS 6.
• Сервер базы данных: Microsoft SQL Server 9.0.4035

Кто-нибудь видел / решил эту проблему типа? У кого-нибудь есть какие-либо предложения относительно того, где я должен смотреть дальше?

Спасибо!

-Zorlack

EDIT

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

При взгляде на код довольно многое выглядит так:

Set objCn = Server.CreateObject("ADODB.Connection") 
objCn.Open(Application("RoConnStr"))
'do some stuff
objCn.Close
Set objCn = Nothing

Решение (по совету Скотта)

В этой статье описана моя проблема. Я внес изменения в реестр, а затем перезагрузил сервер.

Проблема решена!

Answer 1

Ваше веб-приложение закрывает и использует (не устанавливает) соединения с базой данных?

Кроме того, вы пытались использовать SQLOLEDB вместо ODBC?Не могу придумать причину, по которой вы будете использовать ODBC здесь.

вот моя строка подключения в очень занятом классическом приложении asp:

Dim strcConn
strConn = "Provider=SQLOLEDB; Data Source=someserver; Initial Catalog=somedb; User ID=someuserid; Password=somepassword"

Редактировать

Я наткнулся на это сообщение в блоге.Вроде интересно.

http://www.ryanbutcher.com/2006/02/classic-asp-on-2003-server-with.html

Answer 2

Я решил эту проблему, воссоздав хранимую процедуру!
Просто DROP, а затем CREATE остановил таймауты в моем случае!

Я страдал сэта проблема на неделю;классический ASP сказал «Тайм-аут SQL», когда я мог выполнить тот же запрос непосредственно к базе данных менее чем за секунду.(Однако я не видел сообщения «не существует».) ASP работал нормально целый месяц.

Мой друг-гений сказал: «Для прохождения через ASP используется« кэшированный »план выполнения., что не очень эффективно. Попробуйте удалить и воссоздать. Это говорит о том, что ваша хранимая процедура могла бы помочь с перезаписью, чтобы сделать ее более эффективной, как это может произойти снова. "

Так как процесс работал нормально, когдаПри тестировании с SQL Management Studio я предполагаю, что не использует кэшированный план, а ASP использует.

Answer 3

В те времена, когда у меня возникали такие проблемы, всегда приходилось общаться с кем-то, кто держал данные открытыми в клиентском приложении, без коммита «select ..».

Не знаю, решит ли это вашу проблему здесь ... хотя.