Oto mój ostatni wysiłek w rewizji tego pytania. Ale tym razem staram się postępować zgodnie z dobrą radą udzieloną przez Odeda w jego artykule Getting good answers on StackOverflow.Jak określić przyczynę główną dla błędu łącza komunikacyjnego Dostawca TCP: Określona nazwa sieci nie jest już dostępna?
muszę się dowiedzieć, w jaki sposób mogę określić przyczynę dla następującego błędu:
Communication link failure
TCP Provider: The specified network name is no longer available
Od czasu do czasu, widzę ten błąd podczas uruchamiania zestawu pakietów SSIS. Ten błąd może wystąpić, gdy jeden do wielu pakietów są prowadzone od:
- SQL Server Agent Job
- plik wsadowy
- W trybie debugowania od stawek
Pełny komunikat o błędzie widzę przedstawia się następująco:
SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "TCP Provider: The specified network name is no longer available.
".
SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "Protocol error in TDS stream".
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "TCP Provider: An existing connection was forcibly closed by the remote host."
jest to przegląd tego, jak mam zaprojektowany proces ETL:
- Dwa serwery
- Oba są maszyny wirtualne
- SSIS pakiety uruchamiane na serwerze aplikacji bazie
- SQL Server mieszka na serwerze bazy danych
używam połączenia OLE DB manager, aby połączyć się z pakietu SSIS na serwerze aplikacji z bazą danych SQL Server na serwerze bazy danych.
Pakiety są uruchamiane jako wdrożenie systemu plików na serwerze aplikacji, a nie jako wdrożenie bazy danych na serwerze bazy danych.
Głównym powodem tego jest to, że ETL jest zintegrowany z zestawem narzędzi, których nie ma na dyskach i nie jest dostępny dla serwera bazy danych. Narzędzia te obejmują Apex Data Loader dla Salesforce i pgAdmin III.
Do tej pory nie mogę konsekwentnie odtworzyć tego błędu. Jednak to co zaobserwowałem:
- Błąd występuje częściej w normalnych godzinach pracy
- Błąd występuje rzadziej w czasie poza godzinami
Za około okres dwóch godzin w piątek rano udało się odtworzyć błąd na konkretnym pakiecie.
Błąd wystąpił podczas dużego przepływu danych, jeśli włączone zostało wywołanie pakietu potomnego, które poprzedza duży przepływ danych.
Błąd nie wystąpił podczas tego samego dużego przepływu danych, jeśli wyłączono wywołanie pakietu potomnego, które poprzedza duży przepływ danych.
Pakiet podrzędny przywołuje z powrotem do bazy danych, aby pobrać niewielką ilość informacji do wykorzystania w treści wiadomości e-mail, a następnie wysyła wiadomość e-mail.
Czy możliwe jest przekroczenie limitu zasobów?
Może limit połączenia?
Zastanawiam się, jakie narzędzia powinienem użyć, aby spróbować ustalić główną przyczynę błędu.
szczegóły techniczne dotyczące dwóch serwerów zaangażowane są wymienione poniżej:
SQL Server Database Server info:
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 17 czerwca 2011 00 : 54: 03 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) w systemie Windows NT 6.1 (Build 7601: Service pack 1) (hypervisor)
SSIS INFO:
Microsoft Visual Studio 2008 w wersji 9.0.30729.1 SP Microsoft .NET Framework w wersji 3.5 SP1
informacji Application Server:
nazwa System operacyjny: Microsoft Windows Server 2008 R2 Standard Wersja: 6.1.7601 Service Pack 1 budowy 7601
mam zbadane komunikat o błędzie w Internecie i okazało się to, ale naprawdę chciałbym, aby uzyskać wgląd biegłego przed kontynuacją:
How to Disable TCP Chimney, TCPIP Offload Engine (TOE) or TCP Segmentation Offload (TSO).
Using Netsh Commands to Enable or Disable TCP Chimney Offload
Każda pomoc jest doceniana.
Dzięki
UPDATE:
Dalsze badania pokazują, że to nie jest „rzeczą SSIS” jako ten sam błąd jest widoczne w tym samym tempie przy użyciu programu SQL Server Management Studio. Złożoność zapytania nie sprawia, że błąd jest mniej lub bardziej prawdopodobny. Próbując rozwiązać, staraliśmy się naprawić (poniżej):
#1 How to Disable TCP Chimney, TCPIP Offload Engine (TOE) or TCP Segmentation Offload (TSO).
To była nasza pierwsza próba. Komin TCP jest teraz wyłączony na serwerze aplikacji i serwerze bazy danych. Testowanie pokazuje, że ten sam błąd występuje z tą samą szybkością.
A więc dokąd się udać? Szczerze mówiąc nie jestem pewien. Jeden pozornie dobrym rozwiązaniem pozostaje: instalacje SQL Server
Application Server i serwer bazy danych nie są identyczne
Application Server = SQL Server 2008 (SP1) - 10.0.2531.0 (X64)
Database Server = SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)
Plan jest modernizacja instalacji programu SQL Server na serwerze aplikacji. To rodzaj hitu i nadziei, ale w tym momencie wydaje się to najlepszą opcją. Coś w moim mózgu mówi mi, że można to rozwiązać przez naprawienie problemu ze sprzętem (mam tu na myśli naprawę lub wymianę) i że może nie być niczego, co może zrobić konfiguracja sprzętu i oprogramowania.
Jednak nadal nie jestem pewien, jak ustalić podstawową przyczynę. Nadal zastanawiam się, jakie narzędzia powinienem użyć do zdiagnozowania głównej przyczyny.
Czy dostałeś to posortowane? – matcheek
@ osoba, dzięki za zapytanie. Przykro mi to mówić, nie, jeszcze nie ... mimo że wypróbowałem kilka rzeczy i złamałem kilka rzeczy. Możesz uczyć się na mojej porażce. Zaktualizowałem pytanie o aktualny status. –
@antiago_jon, widzę ten sam błąd w dziennikach serwera internetowego. Kod Pythona używający ADO do komunikacji z SQL 2008r2. Pełny stos to maszyny wirtualne, więc nie jest to prawdopodobnie problem ze sprzętem. – Manfre