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

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

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

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

Я не уверен, к чему приписать эту проблему. Рассматриваемый сервер 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

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

Спасибо!

-Зорлак

ИЗМЕНИТЬ

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

Глядя на код, довольно много выглядит так:

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

Решение (по совету ScottE)

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

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


sql-server timeout connection-pooling asp-classic
person zorlack    schedule 22.06.2010    source источник
comment
Спасибо, у меня тоже была эта проблема. Однако похоже, что пул соединений - отвлекающий маневр. Когда я тестировал с пулом соединений и без него, сервер по-прежнему создавал тысячи TCP-соединений в состоянии TIME_WAIT. Кажется, что пул соединений позволяет повторно использовать объекты соединения, но иногда они создают много новых TCP-соединений между серверами.   -  person GC.    schedule 13.06.2011

Ответы (3)


arrow_upward
7
arrow_downward

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

Кроме того, пробовали ли вы использовать 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

person ScottE    schedule 22.06.2010
comment
Это две вещи, на которые я хотел бы обратить внимание: ODBC добавляет ненужную абстракцию к соединению, и неспособность восстановить соединения - распространенная проблема. - person Godeke; 22.06.2010
comment
В большинстве случаев приложение не устанавливает для объекта подключения ничего после завершения. В то время я понимал, что оставить объект подключения можно, поскольку он выйдет за пределы области видимости, когда страница завершит рендеринг. В этот момент не вступает в действие пул соединений? - person zorlack; 22.06.2010
comment
@zorlack - установка объекта подключения = ничего - это лучшая практика управления памятью для классического asp. - person ScottE; 23.06.2010

arrow_upward
2
arrow_downward

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

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

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

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

person Magnus Smith    schedule 13.02.2014
comment
Это очень, очень хороший ответ, требующий положительных отзывов! Работал с ASP в течение многих лет и никогда не сталкивался с этой проблемой (к счастью, потому что мои процедуры не вызывали никаких проблем), но это очень хорошая информация, о которой следует помнить! Спасибо! - person Digs; 19.03.2015
comment
Если проблема заключается в кэшированном плане, вы можете решить эту проблему с меньшим прерыванием, указав SQL для явной переоценки кэшированного плана: exec sp_recompile 'MyProcedure' Это позволяет избежать проблем с неожиданными изменениями разрешений. - person Bruce; 29.06.2017

arrow_upward
0
arrow_downward

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

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

person Edelcom    schedule 23.06.2010