Pule połączeń są resetowane z błędem: 18056, wskaźnik ważności: 20, stan: 46. & Liczniki Perfmon nie są wyświetlane

Używamy uwierzytelniania SQL (w celu zmniejszenia liczby pul połączeń) i parametrów połączenia .NET 4.0 do połączenia z SQL Server Enterprise Edition 2012 SP1 na Windows 2008 R2 Enterprise Server:

Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64)
19 października 2012 13:38:57
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) w systemie Windows NT 6.1 (kompilacja 7601: Service Pack 1)

Korzystamy z około 50 serwerów podzielonych na 8 różnych grup różnych części witryny.

Nasza strona internetowa używa tego serwera SQL do rejestrowania danych śledzenia odwiedzin. W ciągu ostatnich kilku dni wyrzucił następujące komunikaty dotyczące resetowania pul połączeń:

Klient nie mógł ponownie użyć sesji z SPID 1327, który został zresetowany do puli połączeń. Identyfikator niepowodzenia to 46. Ten błąd mógł być spowodowany niepowodzeniem wcześniejszej operacji. Sprawdź dzienniki błędów pod kątem nieudanych operacji bezpośrednio przed tym komunikatem o błędzie.

Dziennik błędów zawiera:

Błąd: 18056, wskaźnik ważności: 20, stan: 46.
Klient nie mógł ponownie użyć sesji z SPID 959, który został zresetowany do puli połączeń. Identyfikator niepowodzenia to 46. Ten błąd mógł być spowodowany niepowodzeniem wcześniejszej operacji. Sprawdź dzienniki błędów pod kątem nieudanych operacji bezpośrednio przed tym komunikatem o błędzie.
Logowanie nie powiodło się dla użytkownika „xxxx”. Powód: Nie udało się otworzyć bazy danych „xxxxxxxx” skonfigurowanej w obiekcie logowania podczas ponownego sprawdzania poprawności logowania w połączeniu. [KLIENT: 10.xx.xx.xxx]

Po pewnym kopaniu znalazłem ten dokument na blogu CSS: Jak to działa: Błąd 18056 - Klient nie mógł ponownie użyć sesji z SPID ##, który został zresetowany do pulowania połączeń i ten przez Aarona Bertranda: Błąd rozwiązywania problemów 18456 . Wiem, że numer błędu jest inny, ale identyfikator błędu jest taki sam, a liczba komunikatów jest identyczna).

Błąd ID 46 sugeruje, że logowanie nie miało uprawnień. Nasze dane logowania są domyślnie w głównej bazie danych, a nazwa db jest określona w ciągu połączenia.

Chciałem sprawdzić liczbę pul ciągów połączeń itp. I sprawdziłem wszystkie liczniki w Perfmon .Net Data Provider for SqlServer. Dało mi to tylko opcję defaultdomain9675dla instancji, więc wybrałem to, zakładając, że jest to generowana przez system nazwa ID dla naszej sieci centrów danych. Niestety wszystkie liczniki odczytują zero. Na jednym z naszych pozostałych głównych serwerów pule połączeń oscylują wokół 10, czego oczekiwałem na zdrowym serwerze z takim obciążeniem.

Moje pytanie jest 3-krotnie

1. Czy ktoś może zasugerować, dlaczego serwer Windows 2008 R2 nie wyświetla się .Net Data Provider for SqlServer?

2. Czy ktoś tego doświadczył, ponieważ oczywiście uważam, że login nieposiadający uprawnień to czerwony śledź?

3. Jeśli różne grupy serwerów WWW mają tę samą składnię ciągu połączenia, ale z nieco inną białą spacją, czy spowodowałoby to użycie przez serwer innej puli połączeń?

Minimalne i maksymalne ustawienia pamięci wynoszą odpowiednio 20 GB i 58 GB. Serwer jest dedykowanym serwerem bazy danych z 64 GB pamięci RAM. Nie sądzę, że problemem jest pamięć, ponieważ pudełko wydaje się mieć przyzwoitą oczekiwaną stronę. Automatyczne zamykanie nie jest włączone. Serwer zawsze działa: jest to witryna 24x7 o dużym obciążeniu.

1 - nie mogę powiedzieć na pewno, musiałbym znaleźć serwer, żeby się w to zagłębić.

2 - tak, widzę to okresowo w moim środowisku, chociaż nie mamy jeszcze SQL 2012 w systemach, z których to widzimy. Możesz także sprawdzić http://blogs.msdn.com/b/psssql/archive/2013/02/13/breaking-down-18065.aspx, chociaż stan 46 wydaje się być powiązany z posiadaniem określonej bazy danych = xxx w ciąg połączenia, czy ta baza danych nadal istnieje?

Sposób konfiguracji mojej sieci Podejrzewam, że to automatyczne zamykanie sesji TCP przez sieć po 5 minutach bezczynności, to jest problem - ani db, ani klient nie zamykają sesji, więc pula połączeń nadal uważa, że ​​połączenie jest otwarte i próbuje użyć po prostu okazało się, że nie jest już tak naprawdę otwarty. Nie wspominasz o tym, jak skonfigurowana jest sieć między twoimi serwerami a db, może twoja sprawa jest podobna.

Inną możliwością może być (stary, niepewny , czy kiedykolwiek naprawdę rozwiązany, patrz http://support.microsoft.com/kb/942861 ) problem dotyczący ustawień odciążania komina TCP.

3 - Rozumiem, że pula wymaga dokładnych dopasowań ciągów, więc spacja i inna kolejność parametrów spowodowałyby różne pule. (Jeśli się mylę, daj mi znać.)

_{Społeczność Wiki odpowiedź pierwotnie pozostawiona jako komentarz autora pytania}

W moim przypadku okazało się, że jest to niekontrolowana tabela rejestrowania, którą ktoś zmienił w gadatliwy, aby rozwiązać problem, ale zapomniał wyłączyć. Skończyło się to rejestrowaniem do 1000 rekordów na sekundę.

Innym zadaniem była próba usunięcia starych rekordów z tabeli. skończyło się zapadaniem w węzły, podobnie jak blokowanie podczas próby usunięcia, blokując wszystkie te wstawki, które zabrakły zasobów puli połączeń.

Gdy tylko znalazłem pracę, uderzyłem osobę, która nadużyła swoich praw na tym serwerze, i zatrzymałem pracę, wszystkie komunikaty o błędach dla pul połączeń zostały zatrzymane.