Udostępnij za pośrednictwem

Rozwiązywanie sporadycznych lub okresowych problemów z nawiązywaniem połączenia z programem SQL Server

  • Artykuł

Uwaga 16.

Przed rozpoczęciem rozwiązywania problemów zalecamy sprawdzenie wymagań wstępnych i listy kontrolnej. Aby uzyskać więcej informacji, zobacz Artykuły samodzielnej pomocy.

Stabilność sieci jest niezbędna do bezproblemowego działania różnych usług i aplikacji. Jednak czasami problemy z siecią zakłócają tę stabilność. Ten artykuł pomaga zrozumieć i rozwiązać sporadyczne lub okresowe problemy z siecią oraz ich typowe komunikaty o błędach. Te problemy mogą być frustrujące, ale można je skuteczniej rozwiązać, lepiej rozumiejąc i odpowiednie techniki rozwiązywania problemów.

Najbardziej typowe komunikaty o błędach

Sporadyczne problemy występują nieregularnie, podczas gdy okresowe problemy mają tendencję do występowania w przewidywalnych odstępach czasu. Identyfikowanie typu problemu jest pierwszym krokiem rozwiązywania problemów. W przypadku sporadycznych lub okresowych problemów z siecią mogą wystąpić następujące komunikaty o błędach:

  • Błąd połączenia komunikacyjnego: ten błąd wskazuje na zakłócenia komunikacji między składnikami sieci.
  • Upłynął limit czasu połączenia: przekroczono limit czasu połączenia z serwerem, co sugeruje opóźnienie lub niedostępność serwera.
  • Ogólny błąd sieci: ogólny komunikat o błędzie sieci często wskazuje nieokreślony problem z siecią.
  • Błąd na poziomie transportu: ten błąd występuje w warstwie transportu, co sugeruje problemy z przesyłaniem danych.
  • Określona nazwa sieci nie jest już dostępna: ten komunikat oznacza, że nie można uzyskać dostępu do określonego zasobu sieciowego.
  • Limit czasu semafora: ten błąd wskazuje na warunek przekroczenia limitu czasu związany z użyciem semaforów w sieci.
  • Upłynął limit czasu operacji oczekiwania: operacja oczekiwania przekroczyła dozwolony czas, zazwyczaj z powodu opóźnień sieci.
  • Wystąpił błąd krytyczny podczas odczytywania strumienia wejściowego z sieci: ten komunikat sugeruje błąd krytyczny podczas odczytywania danych z sieci.
  • Błąd protokołu w strumieniu TDS: Tabelaryczny strumień danych (TDS) jest protokołem używanym przez program SQL Server. Ten błąd wskazuje problem z protokołem.
  • Serwer nie został znaleziony lub niedostępny: ten komunikat o błędzie sugeruje, że serwer, do którego próbujesz uzyskać dostęp, jest niedostępny lub nie można go odnaleźć.
  • Program SQL Server nie istnieje lub odmowa dostępu: ten błąd może wskazywać na brak programu SQL Server lub błąd uwierzytelniania podczas próby uzyskania dostępu do programu SQL Server.

Przyczyna

Najczęstsze problemy są związane z przerywaniami pakietów z powodu oprogramowania antywirusowego, optymalizacji sieci, starszych sterowników sieci, nieprawidłowych routerów lub przełączników oraz połączeń niepulowanych w aplikacji.

Niektóre przyczyny, takie jak oprogramowanie antywirusowe, mogą być trudne do udowodnienia, ale nadal są powszechne. Może być konieczne odinstalowanie i ponowne uruchomienie komputera, aby to udowodnić, bez wyraźnych dowodów. Utworzenie wyjątku dla programu SQL Server może również działać. Ale wyłączenie programu antywirusowego zwykle nie działa, ponieważ sterowniki filtrów sieci nadal ładują się, nawet jeśli nie są monitorowane.

Proces rozwiązywania problemów

Uwaga 16.

Ten proces jest przeznaczony dla połączeń klienta i serwera programu SQL Server. Inne komunikaty, takie jak dublowanie programu SQL Server, zawsze włączone i ruch synchronizacji usługi Service Broker przez port 5022, nie są rozwiązywane.

Ogólnie rzecz biorąc, rozwiązywanie problemów powinno być oparte na danych, co może ustąpić empirycznym testom w bardziej ukierunkowanym kontekście. Jeśli problem jest bardzo sporadycznie, a ślady sieci będą trudne do przechwycenia, metody empiryczne mogą być stosowane najpierw.

Zbieranie raportu przy użyciu narzędzia SQLCHECK na każdej maszynie

Uruchom narzędzie SQLCHECK na każdej maszynie, aby utworzyć raport. Warto określić, dlaczego połączenie może zakończyć się niepowodzeniem.

Zbieranie śladów sieci na kliencie i serwerze

  • Na maszynach z systemem Windows zbierz ślady sieci przy użyciu narzędzia SQLTRACE.

    Wykonaj następujące kroki, aby przygotować i wykonać ślad. Kroki 2 i 3 należy wykonać tylko raz.

    1. Pobierz najnowszą wersję programu SQLTRACE i rozpakuj ją do folderu, takiego jak C:\MSDATA.

    2. Otwórz plik SQLTrace.ini i wyłącz następujące ustawienia:

      BIDTrace=no, AuthTrace=no i EventViewer=no

    3. Zapisz plik.

    4. Otwórz program PowerShell jako administrator i zmień katalog na folder zawierający plik SQLTrace.ps1.

      CD C:\MSDATA

    5. Uruchom kolekcję śledzenia.

      .\SQLTrace.ps1 -start

    6. Odtwórz problem lub poczekaj na wystąpienie błędu.

    7. Zatrzymaj śledzenie.

      .\SQLTrace.ps1 -stop

    Folder wyjściowy jest generowany w bieżącym katalogu i można go użyć do dalszej analizy.

  • Na komputerach z systemem innym niż Windows użyj protokołu TCPDUMP lub WireShark, aby zebrać przechwytywanie pakietów.

Uruchamianie analizatora sieci programu SQL Server

Interfejs użytkownika analizatora sieci SQL (SQLNAUI) udostępnia interfejs graficzny służący do wybierania plików śledzenia na potrzeby analizowania i opcji ustawień. Pobierz go z narzędzia SQL Network Analyzer (SQLNA).

Przetwarzaj dane śledzenia klienta i serwera oddzielnie. Jeśli ślady zostały łańcuchowe, przetwórz je w tym samym czasie. Całkowity rozmiar tych plików nie powinien przekraczać 80% pamięci komputera. Upewnij się, że masz wystarczającą ilość pamięci do przetworzenia wszystkich powiązanych plików śledzenia.

To narzędzie wygeneruje raport o podejrzanych problemach i pliku CSV, który można eksplorować w programie Excel w celu uzyskania alternatywnych badań.

Spróbuj zlokalizować dopasowane konwersacje w śladzie klienta i ślad serwera. Ogólnie rzecz biorąc, adresy IP i numery portów są zgodne. Jeśli jednak połączenia przechodzą przez jakikolwiek rodzaj translacji adresów sieciowych lub mapowania portów, może to być trudniejsze i może być konieczne skonfigurowanie przy użyciu identyfikatorów pakietów IPV4 i porównanie ładunków.

Wzorce do wyszukania w analizie śledzenia sieci

Sprawdź, jak rozmowy kończą się na netMON lub WireShark. Sprawdź, czy klient i serwer zgadzają się na to samo lub czy opowiadają inną historię.

Połączenie zostało zamknięte podczas uzgadniania protokołu SSL

W pakiecie ServerHello, jeśli używany pakiet szyfrowania jest pakietem Diffie-Hellman, a ruch jest między windows 2012 lub starszym i Windows 2016 lub nowszym, ten algorytm zmienia się począwszy od poprawek zabezpieczeń systemu Windows 2016. Należy wyłączyć tę grupę zestawów szyfrowania. Aby uzyskać więcej informacji, zobacz Aplikacje napotkają wymuszone błędy połączenia TLS podczas nawiązywania połączenia z serwerami SQL Server w systemie Windows.

Jeśli połączenie jest zamknięte po clientHello, sprawdź, czy istnieje niezgodność protokołu TLS 1.0 lub TLS 1.2 między klientem a serwerem. Jeśli są one takie same, sprawdź włączone zestawy szyfrowania i włączone skróty na obu maszynach.

Aby uzyskać więcej informacji, zobacz Advanced Secure Sockets Layer data capture (Przechwytywanie danych advanced Secure Sockets Layer).

Porzucone pakiety

Wyświetl koniec dopasowanych konwersacji. Jeśli jeden ma wiele przetransmittowanych pakietów (lub 10 pakietów Keep-Alive, 1-sekundowy od siebie), a następnie ACK +RESET, a drugi nie, lub zgłasza terminową odpowiedź, a druga widzi opóźnienie i zamyka lub resetuje konwersację, oznacza to problem z urządzeniem sieciowym i pakiety są porzucane lub opóźnione.

Może również zostać wyświetlony raport klienta wskazujący, że serwer resetuje konwersację, a raport serwera wskazujący, że klient resetuje konwersację. Jest to spowodowane nieprawidłowym przełącznikiem lub routerem zamykającym połączenie z środka, a czasami można je skonfigurować tak, jeśli wykryje, że połączenie było bezczynne przez pewien czas — często ignorując pakiety Keep-Alive.

Aby uzyskać więcej informacji na temat porzuconych połączeń, zobacz:

Zarówno ślad serwera, jak i ślad klienta zgadzają się, że problem występuje na kliencie

Jeśli oba ślady pokazują opóźnienie lub brak odpowiedzi na klienta lub jeśli klient wystawia ACK+RESET po potwierdzeniu odpowiedzi serwera lub w inny sposób zamyka połączenie na wczesnym etapie sekwencji logowania, musisz wykonać ślad BID i ślad NETSH na kliencie, aby zajrzeć do stosu TCP/IP i co myśli sterownik. Jest to typowe, jeśli oprogramowanie antywirusowe lub inne sterowniki filtrów sieci opóźniają odbieranie pakietu lub wysyłanie odpowiedzi. Przekroczenia limitu czasu połączenia mogą być również spowodowane powolną odpowiedzią DNS lub powolnym interfejsem API zabezpieczeń, który został wywołany przed wysłaniem początkowego pakietu SYN za pośrednictwem przewodu.

Sprawdź raport dotyczący portów efemerycznych analizatora sieci SQL i upewnij się, że klient nie kończy portów wychodzących.

Jeśli klient ma duże opóźnienie przed wysłaniem pakietu SYN, może zostać wyświetlony wzorzec pokazujący tylko 3-drogowy uzgadnianie TCP, a następnie natychmiast lub czasami po wysłaniu pakietu PreLogin przez ACK+FIN pochodzące z klienta.

Zbieranie śladu sieci i śladu BID w celu izolowania problemów klientów w systemie Windows

  1. Otwórz plik SQLTrace.ini i włącz następujące ustawienia:

    BIDTrace=Yes, AuthTrace=Yes i EventViewer=Yes

  2. Skonfiguruj element BIDProviderList w SQLTrace.ini , aby był zgodny ze sterownikiem używanym przez aplikację.

    .NET System.Data.SqlClient jest domyślnie włączona. Jeśli nie jest to sterownik, którego używasz, wyłącz BIDProviderList , dodając # do przodu linii i usuwając go z początku listy ODBC lub OLEDB. Spowoduje to przechwycenie wszystkich obsługiwanych sterowników tego typu. Aby uzyskać więcej informacji, zobacz INI Configuration (Konfiguracja INI).

  3. Zapisz plik.

  4. Otwórz program PowerShell jako administrator i zmień katalog na folder zawierający plik SQLTrace.ps1.

    CD C:\MSDATA

  5. Zainicjuj rejestr śledzenia BID, jeśli zbierasz ślady BID.

    Uwaga 16.

    Śledzenie bid jest domyślnie włączone.

    .\SQLTrace.ps1 -setup

  6. Uruchom ponownie śledząc usługę lub aplikację.

    W przypadku niektórych aplikacji, takich jak pakiety usług SQL Server Integration Services (SSIS), nowe wystąpienie narzędzia DTEXEC lub ISServerExec jest uruchamiane po uruchomieniu pakietu, więc ponowne uruchomienie nie ma sensu.

  7. Uruchom kolekcję śledzenia.

    .\SQLTrace.ps1 -start

  8. Odtwórz problem lub poczekaj na wystąpienie błędu.

  9. Zatrzymaj śledzenie.

    .\SQLTrace.ps1 -stop

Folder wyjściowy jest generowany w bieżącym katalogu i można go użyć do dalszej analizy.

Aby śledzić inne sterowniki programu Microsoft SQL Server, zobacz następujące artykuły. Wykonaj przy użyciu śledzenia sieci.

Aby śledzić sterowniki innych firm, zapoznaj się z dokumentacją dostawcy.

Zarówno ślad serwera, jak i ślad klienta zgadzają się, że problem znajduje się na serwerze

Jeśli oba ślady pokazują opóźnienie lub brak odpowiedzi na serwerze lub jeśli serwer zamknie połączenie w nieoczekiwanym punkcie w sekwencji logowania lub jeśli serwer zamknie wiele połączeń w tym samym czasie, oznacza to, że na serwerze występują pewne problemy.

Najbardziej prawdopodobną przyczyną jest niska wydajność serwera, wysoka wartość MAXDOP oraz duże zapytania równoległe i blokowanie. Mogą one spowodować zagłodnienie wątku, uniemożliwiając szybkie obsłużenie żądania logowania, zwłaszcza jeśli wiele przekroczenia limitu czasu połączenia kończy się w tym samym czasie, a kolumna LoginAck zawiera wartość "Late". Plik DZIENNIKA BŁĘDÓW programu SQL Server może pokazywać, że operacje we/ wy trwają dłużej niż 15 sekund, co jest kolejnym wskaźnikiem problemów z wydajnością. W śladzie sieci może być również widocznych wiele konwersacji w raporcie Resetowanie z sześcioma ramkami lub mniejszą liczbą, co oznacza, że uzgadnianie TCP 3-way mogło nie zostać ukończone. Aby uzyskać więcej informacji, zobacz Zbieranie buforu pierścienia łączności.

RingBufferConnectivity Uruchom zapytanie i wklej wyniki do programu Excel. Ponieważ jest to lista historyczna, można ją uruchomić po wystąpieniu problemu. Jednak w przypadku zajętego serwera może to zakończyć się szybko. W przypadku powolnego serwera może mieć dane przez kilka dni.

Jeśli aplikacja używa wielu aktywnych zestawów wyników (MARS), kończy się resetem w ramach sekwencji zamykającej. Jest to łagodne, jeśli pakiety SMP:FIN i ACK+FIN zostały już wysłane z klienta. Pakiet SMP:FIN serwera zostanie dostarczony po ACK+FIN od klienta, a system Windows wyda ACK+RESET, a następnie reset dla wszystkich innych odpowiedzi serwera w ramach sekwencji zamykania połączenia.

Buforowanie połączeń

Aby uzyskać więcej informacji, zobacz Buforowanie połączeń.

Jeśli jest używane buforowanie połączeń, konwersacje w śledzeniu sieci zwykle będą dość długie. Plik CSV wygenerowany przez analizator sieci programu SQL Server umożliwia sortowanie i filtrowanie według protokołów i ramek. Prawdopodobnie nie zobaczysz ramek początkowych ani końcowych, jeśli przechwytywanie sieci jest mniejsze niż pół godziny. Jeśli wiele konwersacji jest krótszych niż 30 ramek z pakietu SYN do pakietu ACK+FIN, oznacza to niepulowane połączenia. Jeśli są one mieszane z kilkoma dłuższymi konwersacjami, podejrzewasz, że połączenia w tle niezwiązane z pulą spowodowane wykonywaniem poleceń w połączeniu spoza usługi MARS podczas odczytywania zestawu wyników.

Raport dotyczący portów efemerycznych pokaże liczbę nowych połączeń w okresie istnienia śledzenia. Częstotliwość połączeń można ocenić według liczby połączeń na sekundę.

RESET a ACK+RESET

Usługa ACK+RESET jest zwykle widoczna, gdy aplikacja lub system Windows przerywa połączenie. Jest to zwykle spowodowane błędem PROTOKOŁU TCP niskiego poziomu. Pakiet informuje inny komputer, aby natychmiast przestał wysyłać. Jeśli jednak serwer znajduje się w trakcie przesyłania, jeden lub dwa pakiety mogą zostać wysłane do klienta po wysłaniu ACK+RESET. Ponieważ port jest zamknięty, system operacyjny wysyła pakiet RESET. Dzieje się tak również, jeśli pakiety docierają po pakiecie ACK+FIN, który nie jest częścią normalnego uzgadniania zamykającego.

Niektóre sterowniki innych firm wysyłają również pakiet ACK+RESET, aby zamknąć połączenie zamiast ACK+FIN. Niektóre połączenia sondy mogą również to zrobić. Jeśli pakiet ACK+RESET nie jest poprzedzony pakietami Keep-Alive, pakietami Retransmitted lub zero pakietów systemu Windows i pochodzi z klienta, gdy oczekuje się normalnego zamknięcia ACK+FIN, może to być łagodne.

Analizowanie problemów z siecią przy użyciu narzędzia NETSTAT

Funkcja NETSTAT jest automatycznie zbierana podczas uruchamiania pliku SQLTrace.ps1 na potrzeby zbierania danych.

Możesz też uruchomić NETSTAT -abon > c:\ports.txt polecenie w wierszu polecenia jako administrator, aby zebrać informacje związane z problemami z siecią.

Plik ports.txt będzie zawierać listę wszystkich portów przychodzących i wychodzących, numerów portów, identyfikatorów procesów i nazw aplikacji, które należą do portów. Dzięki temu można zobaczyć najgorszych przestępców i określić, czy osiągnięto limit portów. Włącz pasek stanu w Notatniku i wyłącz zawijanie programu Word. Pasek stanu będzie zawierać liczbę wierszy. Możesz podzielić przez dwa, aby uzyskać przybliżone użycie portów.

Dostosowywanie tcpTimedWaitDelay i MaxUserPort

Jeśli aplikacja wyczerpała porty wychodzące na maszynie hosta i nie można wprowadzać żadnych natychmiastowych zmian w aplikacji, można zmniejszyć TcpTimedWaitDelay się z 240 do nawet 30 sekund, co pozwoli na szybsze przetwarzanie portów wychodzących.

W przypadku systemu Windows 2003 lub nowszego można również zwiększyć wartość MaxUserPort. W przypadku systemu Windows Vista i nowszych należy to ustawić za pomocą NETSH polecenia . Ten przebieg akcji nie eliminuje niewydajności niepulowanych połączeń ani niepulowanych połączeń w tle, a deweloper powinien być zdecydowanie zachęcany do zmiany aplikacji w celu korzystania z buforowania połączeń.

W przypadku systemu Windows 2008 i nowszych zakres został domyślnie zwiększony z około 4000 portów efemerycznych do 16 000 portów.

Aby uzyskać więcej informacji, zobacz Dostosowywanie ustawień MaxUserPort i TcpTimedWaitDelay.

Prawie wszystkie pakiety wysyłane z klienta do serwera lub serwera do klienta są odpowiadane z pakietem ACK przechodzącym w przeciwnym kierunku. Warstwa TCP.SYS generuje ACK. Jeśli pakiet jest odbierany na kliencie, a ślad klienta pokazuje, że jest on przychodzący, ale nie jest zwracany do serwera, jest to dobre wskazanie, że program antywirusowy lub inny sterownik filtru sieciowego utracił lub porzucił pakiet lub zatrzymał go przez długi czas (po zakończeniu zbierania danych śledzenia sieci). Podobnie, jeśli ślad serwera pokazuje pakiet pochodzący z klienta, ale żadne ACK nie jest wysyłane z powrotem do klienta, oznacza to, że program antywirusowy serwera na serwerze może mieć problem.

Jednak podczas przekazywania lub pobierania dużej ilości danych pakiety ACK mogą pochodzić po serii pakietów danych, które ułatwiają sterowanie przepływem.

Oprogramowanie antywirusowe i sterowniki filtrów są bardzo trudne do udowodnienia jako winowajca. Test empiryczny jest prawie zawsze wymagany. Utwórz wyjątek dla aplikacji lub programu SQL Server w oprogramowaniu antywirusowym, a następnie monitoruj go przez 48 godzin, aby sprawdzić, czy zachowanie się poprawi. Jeśli nie można ustawić wyjątku, odinstaluj program antywirusowy i uruchom go ponownie. Wyłączenie go zwykle nie pomaga, ponieważ sterownik filtru antywirusowego nadal będzie ładowany. Zrób to tylko w ostateczności, jeśli ochrona krawędzi jest w miejscu.

Skontaktuj się z administratorami zabezpieczeń sieci. Jeśli sytuacja się poprawi, może być konieczne współpraca z dostawcą oprogramowania antywirusowego, aby rozwiązać ten problem. Jeśli tak nie jest, inne sterowniki filtrów sieciowych mogą być winowajcą.

Włączanie inspekcji zapory systemu Windows

Aby określić, czy zapora porzuciła jakiekolwiek pakiety, włącz inspekcję zapory w systemie Windows.

W przypadku programu SQL Server ten problem może być związany z klientem lub maszyną serwera. Ślad sieci pokaże, że maszyna odebrała pakiet, ale nie odpowiedziała. Następnie pakiet może zostać ponownie przetransmittowany, ponownie nie otrzyma odpowiedzi, a ostatecznie połączenie zostanie zresetowane.

Empiryczne i inne działania

Porty efemeryczne

Brak portów efemerycznych jest stosunkowo częstą przyczyną sporadycznego przekroczenia limitu czasu połączenia, zwłaszcza jeśli nie widzisz pakietu SYN w sieci.

W przypadku żądań przychodzących na serwerze porty, takie jak 80 lub 1433, może potrwać do 64 000 połączeń przychodzących na adres IP klienta i są zazwyczaj "nieograniczone" dla wszystkich celów praktycznych.

Z drugiej strony w przypadku połączeń wychodzących liczba portów jest ograniczona i współdzielona między wszystkimi połączeniami serwera. W przypadku systemu Windows Vista, Windows 2008 i nowszych domyślny zakres to od portu 49152 do 65535 (2^16 = 16 384 portów).

Zwykle porty są przechowywane przez cztery minuty (240 sekund) przez system operacyjny przed ich recyklingu i mogą być ponownie używane przez aplikacje. Zapobiega to fałszowaniu portów przez złośliwe oprogramowanie lub przypadkowe przekierowanie nowego połączenia z poprzednim posiadaczem tego portu. Z powodu tego opóźnienia w systemie Windows 2003 aplikacja kliencka może wykonywać tylko 17 połączeń na sekundę z programem SQL Server, a zakres portów wychodzących jest wyczerpany w mniej niż cztery minuty. W przypadku systemu Windows Vista liczba ta wzrasta do 68 połączeń na sekundę.

W przypadku aplikacji, takich jak usługi IIS, każdy klient HTTP może mieć jeden port wychodzący do programu SQL Server. W przypadku zajętego serwera internetowego wyczerpanie portów wychodzących jest realną możliwością, gdy obciążenie jest wysokie. Farma internetowa może złagodzić tę sytuację.

Dostosowywanie maksymalnej pamięci serwera (MB)

Aby rozwiązać problemy związane z małą ilością pamięci jądra, dostosuj maksymalną pamięć serwera (MB).

Wyłączanie odciążania

W celach testowych można wyłączyć odciążanie za pomocą administracyjnego wiersza polecenia:

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global NetDMS=disabled
netsh int tcp set global autotuninglevel=disabled

Nie należy wyłączać tych ustawień przez długi czas, chyba że złagodzią problem. Powinny one być domyślnie włączone w systemie Windows 2008 lub nowszym.

W przypadku innych odciążania należy przejść do właściwości karty sieciowej, aby je wyświetlić i wyłączyć.

Problemy z buforem sieci VMware

Host ESX zawierający maszynę wirtualną ma mały bufor sieciowy, który może powodować problemy z niezawodnością, jeśli występuje wzrost ruchu. W poniższym artykule VMware opisano sposób zwiększania rozmiaru buforu. Nie jest wymagany ponowny rozruch. Tę operację należy wykonać na maszynie hosta ESX, a nie na maszynie wirtualnej.

Duża utrata pakietów w systemie operacyjnym gościa przy użyciu VMXNET3 w programie ESXi

Ponadto spróbuj przenieść maszyny wirtualne na inny serwer hosta ESX lub przenieść klienta i serwera na ten sam serwer hosta ESX i sprawdzić, czy problem zniknie. Jeśli tak, jest to podstawowy problem z siecią.

Migawki programu VMware

Sprawdź, czy migawki programu VMware są wykonywane podczas błędu i je wyłączają.

Skalowanie po stronie odbierającej (RSS) jest wyłączone na maszynie hosta

Gdy funkcja RSS jest wyłączona, host programu SQL Server używa tylko jednego procesora CPU do przetwarzania wszystkich żądań sieciowych. Może to spowodować wzrost użycia procesora CPU do 100% i spowodować problemy, nawet jeśli inne procesory CPU (i ogólne użycie procesora CPU) są niskie.

Aby uzyskać więcej informacji, zobacz Wprowadzenie do skalowania po stronie odbierającej i skalowania po stronie odbierającej w wersji 2 (RSSv2).

Więcej informacji

Sporadyczne lub okresowe problemy z uwierzytelnianiem w programie SQL Server

Zbieranie śledzenia sieci

Zastrzeżenie dotyczące innych firm

Produkty innych firm omówione w tym artykule są wytwarzane przez producentów niezależnych od firmy Microsoft. Firma Microsoft nie udziela żadnych gwarancji, dorozumianych ani żadnego innego rodzaju, w odniesieniu do wydajności lub niezawodności tych produktów.