Мы только что завершили миграцию с SQL 2000 на SQL 2008 R2 и начали периодически получать SqlExceptions со следующими двумя сообщениями об ошибках:
У нас есть 3 веб-сервера, подключенных к этому SQL Server, на которых запущено около 100 приложений (все обращаются к одним и тем же 8 базам данных на SQL Server).
Поскольку эти исключения не возникали на сервере 2000, мы считаем, что это вряд ли проблема приложения (однако мы не исключаем ее). Трафик на веб-сайтах типичный, что исключает проблему высокой посещаемости. В старом корпусе SQL 2000 было 4 ЦП и 8 ГБ ОЗУ, а в новом - 24 ГБ ОЗУ и 16 ЦП (которые в настоящее время и во время проблемы используются недостаточно).
Эти ошибки возникли около 5 минут несколько часов назад и еще не повторялись.
В системном представлении sys.dm_os_ring_buffers не отображаются записи для этих отключений, и нет соответствующих записей журнала событий ни на сервере, ни на клиенте.
При поиске в Google было обнаружено несколько похожих отчетов, однако ничего определенного не представлялось (см. Ссылки ниже). Кто-нибудь видел подобные ошибки после перехода с SQL 2000 на SQL 2008 R2?
Ссылки:
Мы отследили и исправили эту проблему в нашей среде. Описание, как я понимаю, приведено ниже (пожалуйста, извините за возможные неточности ниже; именно так я (как разработчик программного обеспечения) понимаю описания, данные мне нашим сетевым администратором (который также работал с нашей хостинговой компанией).
В конечном итоге причина была выявлена как проблема конфигурации сети, связанная с балансировщиком нагрузки. Мы ожидали, что балансировщик нагрузки находится между Интернетом и нашими веб-серверами, и что все наши серверы свободно обмениваются данными друг с другом. К сожалению, сеть была настроена таким образом, что весь сетевой трафик (включая трафик между SQL-серверами и веб-серверами) проходил через балансировщик нагрузки. Балансировщик нагрузки был настроен на ограничение пропускной способности, проходящей через него, и при превышении лимита он просто отбрасывал пакеты. Предел часто превышался при передаче больших файлов между серверами (например, когда резервные копии базы данных копировались с сервера базы данных и т. Д.). Нам было трудно это увидеть, поскольку у нас не было доступа к Load Balancer (только наш хостинг-провайдер мог получить к нему доступ), и, насколько мы могли судить, мы были далеки от насыщения наших сетевых интерфейсов. Кроме того, эти проблемы были чрезвычайно спорадическими (порядка нескольких минут каждые 3-5 месяцев).
Исправление заключалось в том, чтобы перестроить среду так, чтобы наш внутренний сетевой трафик не проходил через LB; Я считаю, что сеть была перестроена, чтобы соответствовать архитектуре балансировки нагрузки «Одноручная». С момента внесения этого изменения мы не испытывали периодических проблем с подключением.
Если я правильно понимаю, вы изменили не только свое программное обеспечение, но и свое оборудование, поэтому существует множество изменений, которые могут вызвать эту ошибку подключения. Я видел множество рекомендаций, чтобы дважды проверить драйверы сетевой карты и прошивку материнской платы (!!), чтобы исправить это. Ой!
В любом случае - вы должны увидеть эту ошибку в журнале серверного приложения. Отсюда вы можете получить представление о дате / времени возникновения исключения, чтобы вы могли сравнить их с отдельным событием клиента / приложения, чтобы сузить круг событий, когда это исключение появляется.
Вы также можете использовать Netmon для отслеживания подключений клиентов к серверу. Вы захотите дать ему пару дней, чтобы воспроизвести ошибку. Это должно немного сузить круг вопросов и, по крайней мере, дать вам представление о том, что не так.
В последний раз я видел, что «время ожидания семафора истекло», когда я пытался скопировать файлы с одного жесткого диска на другой в Windows Server 2008. Оказалось, из-за сильно фрагментированного жесткого диска с плохими кластерами. Western Digital 2TB икра Зеленая, кстати, не в RAID.
Давно потратил на это, но я тоже хотел добавить свои два цента. В нашем случае рассматриваемый SQL-сервер находится в другой сети с брандмауэром между ними, поэтому в игру вступила IPS. Это работало в течение многих лет, но, очевидно, только на этой неделе IPS получила новую версию старой сигнатуры обнаружения, которую она назвала «Атака MSSQL: уязвимость Microsoft SQL с переполнением буфера, высокая исходящая уязвимость». Таким образом, он начал блокировать попытки подключения через порт 1433.