Вот мои последние усилия по пересмотру этого вопроса. Но на этот раз я стараюсь следовать советам, данным Одедом в его статье " Получение хороших ответов о StackOverflow".
Мне нужно выяснить, как я могу определить причину следующей ошибки:
Ошибка связи
Поставщик TCP: указанное сетевое имя больше не доступно
Время от времени я вижу эту ошибку при запуске набора пакетов служб SSIS. Эта ошибка может возникать при запуске одного-многих пакетов из:
- Задание агента SQL Server
- Пакетный файл
- В режиме отладки от BIDS
Полное сообщение об ошибке, которое я вижу, выглядит следующим образом:
Код ошибки служб SSIS DTS_E_OLEDBERROR. Произошла ошибка OLE DB. Код ошибки: 0x80004005. Доступна запись OLE DB. Источник: "Собственный клиент Microsoft SQL Server 10.0". Результат: 0x80004005 Описание: "Ошибка канала связи". Доступна запись OLE DB. Источник: "Собственный клиент Microsoft SQL Server 10.0". Hresult: 0x80004005 Описание: "Поставщик TCP: указанное сетевое имя больше не доступно".
Код ошибки служб SSIS DTS_E_OLEDBERROR. Произошла ошибка OLE DB. Код ошибки: 0x80004005. Доступна запись OLE DB. Источник: "Собственный клиент Microsoft SQL Server 10.0". Результат: 0x80004005 Описание: "Ошибка протокола в потоке TDS". Доступна запись OLE DB. Источник: "Собственный клиент Microsoft SQL Server 10.0". Результат: 0x80004005 Описание: "Ошибка канала связи". Доступна запись OLE DB. Источник: "Собственный клиент Microsoft SQL Server 10.0". Результат: 0x80004005 Описание: "Поставщик TCP: существующее соединение было принудительно закрыто удаленным хостом".
Это обзор того, как я разработал процесс ETL:
- Два сервера
- Обе виртуальные машины
- Пакеты служб SSIS запускаются на сервере приложений
- База данных SQL Server живет на сервере базы данных
Я использую диспетчер соединений OLE DB для подключения из пакета служб SSIS на сервере приложений к базе данных SQL Server на сервере базы данных.
Пакеты запускаются как развертывание файловой системы на сервере приложений, а не как развертывание базы данных на сервере базы данных.
Основная причина этого заключается в том, что ETL интегрирован с набором инструментов, которые не найдены, а диски не доступны для сервера базы данных. Эти инструменты включают Apex Data Loader для Salesforce и pgAdmin III.
Пока я не могу последовательно воспроизвести эту ошибку. Однако вот что я заметил:
- Отказ происходит чаще в обычные рабочие часы
- Отказ происходит реже в нерабочее время
Около двух часов в пятницу утром я смог успешно воспроизвести ошибку на конкретном пакете.
Ошибка произошла во время большого потока данных, если был включен дочерний вызов пакета, предшествующий большому потоку данных.
Ошибка не произошла во время того же большого потока данных, если был отключен вызов дочернего пакета, который предшествовал большому потоку данных.
Рассматриваемый дочерний пакет перезванивает в базу данных, чтобы получить небольшое количество информации для использования в теле письма, а затем отправляет электронное письмо.
Такое ощущение, что может быть превышен лимит ресурсов?
Может быть лимит подключения?
Мне интересно, какие инструменты я должен использовать, чтобы попытаться определить причину ошибки.
Технические подробности о двух задействованных серверах перечислены ниже:
Информация о SQL Server и сервере баз данных:
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 17 июня 2011 г. 00:54:03 Авторское право (c) Microsoft Corporation Enterprise Edition (64-разрядная версия) в Windows NT 6.1 (сборка 7601: пакет обновления 1) (гипервизор) )Информация SSIS:
Microsoft Visual Studio 2008 Версия 9.0.30729.1 SP Microsoft.NET Framework Версия 3.5 SP1Информация о сервере приложений:
Имя ОС: Microsoft Windows Server 2008 R2, стандартная версия: 6.1.7601, пакет обновления 1, сборка 7601
Я изучил сообщение об ошибке в Интернете и нашел его, но очень хотел бы получить экспертную оценку, прежде чем продолжить:
- Как отключить TCP Chimney, механизм разгрузки TCPIP (TOE) или разгрузку сегментации TCP (TSO).
- Использование команд Netsh для включения или отключения разгрузки дымовых труб TCP
Любая помощь приветствуется.
Спасибо
ОБНОВИТЬ:
Дальнейшее тестирование показывает, что это не "вещь служб SSIS", поскольку при использовании SQL Server Management Studio такая же ошибка наблюдается с той же скоростью. Сложность запроса не делает ошибку более или менее вероятной. В попытке решить эту проблему мы попытались исправить одно (ниже):
Это была наша первая попытка. TCP Chimney теперь отключен на сервере приложений и сервере базы данных. Тестирование показывает, что та же ошибка происходит с той же скоростью.
Так куда же идти? Честно говоря, я не уверен. Остается один, казалось бы, хороший вариант:
- Установки сервера приложений и сервера базы данных SQL Server точно не совпадают
- Сервер приложений = SQL Server 2008 (SP1) - 10.0.2531.0 (X64)
- Сервер базы данных = SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)
Планируется обновить установку SQL Server на сервере приложений. Это своего рода хит и надежда, но на данный момент это кажется лучшим вариантом. Что-то в моем мозгу говорит мне, что это может быть решено путем исправления проблемы с оборудованием (под этим я подразумеваю ремонт или замену), и что конфигурация аппаратного и программного обеспечения может с этим ничего не поделать.
Тем не менее, я все еще не уверен, как определить первопричину. Мне все еще интересно, какие инструменты мне следует использовать для диагностики первопричины.
