Mamy dwa produkcyjne serwery SQL z programem SQL Server 2005 SP4 z aktualizacją zbiorczą 3. Oba serwery działają na fizycznych komputerach, które są identyczne. DELL PowerEdge R815 z 4 x 12 rdzeniowymi procesorami i 512 GB pamięci RAM (tak GB), z 10 GB podłączonymi dyskami iSCSI SAN dla wszystkich baz danych SQL i dzienników. System operacyjny to Microsoft Windows Server 2008 R2 Enterprise Edition ze wszystkimi aktualizacjami SP i Windows. Dysk OS to macierz RAID 5 z 3 x 72 GB dyskami SAS 2,5 "15 kb. SAN to Dell EqualLogic 6510 z dyskami 48 x 10 k SAS 3,5”, skonfigurowany w RAID 50, podzielony na różne jednostki LUN dla 2 serwerów SQL, a także współużytkowany z maszyną Exchange i kilkoma serwerami VMWare.
Mamy ponad 20 baz danych, z których 11 jest dublowanych z wysoką dostępnością przy użyciu serwera-świadka. Serwer-świadek to maszyna o mniejszej mocy, na której działa instancja programu SQL Server, która służy wyłącznie do świadczenia usług świadków. Największa lustrzana baza danych ma pojemność 450 GB i generuje około 100-300 Iops. Monitor dublowania bazy danych zgłasza bieżącą szybkość wysyłania od około 100 kb do 10 MB na sekundę, a narzut lustrzany zatwierdza (zwykle) 0 milisekund. Serwer lustrzany nie ma problemu z nadążaniem za zleceniodawcą.
Konsekwentnie obserwujemy awarie lustrzane. Czasami jedna baza danych zostanie przełączona w tryb failover, innym razem prawie wszystkie bazy danych przejdą w tryb failover jednocześnie. Na przykład zeszłej nocy mieliśmy 10 z 11 przełączeń awaryjnych baz danych, pozostała baza danych była dostępna, dopóki ręcznie nie przełączyłem awaryjnie.
Przeszedłem kilka kroków w celu rozwiązania problemu, ale jak dotąd nie udało mi się rozwiązać problemu:
1) Do urządzenia dołączono 4-portową gigabitową kartę sieciową Broadcom BCM5709C NetXtreme II, którą początkowo używaliśmy jako podstawowe połączenie sieciowe. Od tego czasu zainstalowaliśmy dwuportowy adapter serwera Intel (R) PRO / 1000 PT na obu komputerach, aby wyeliminować problem z kartą sieciową.
2) Wszystkie bazy danych mają automatyczną pełną kopię zapasową co noc wraz z kopią zapasową dziennika dla baz danych zaangażowanych w dublowanie. Wykorzystanie pliku dziennika jest monitorowane i rzadko przekracza 15%. Plik dziennika dla głównej bazy danych ma rozmiar 125 GB i składa się ze 159 wirtualnych plików dziennika o wielkości od 511 MB do 1 GB. TempDB ma własną jednostkę LUN i składa się z 24 x 2 GB plików.
3) Dziennik SQL Server w dzienniku nie pokazuje żadnych błędów poza: Połączenie lustrzane z „TCP: //SQL02.DOMAIN.INET: 5022” przekroczyło limit czasu dla bazy danych „Data” po 30 sekundach bez odpowiedzi. Sprawdź usługi i połączenia sieciowe.
Dziennik programu SQL Server na serwerze głównym i pomocniczym pokazuje komunikaty dotyczące kopii lustrzanej:
Połączenie dublowania z „TCP: //SQL01.DOMAIN.INET: 5022” przekroczyło limit czasu dla bazy danych „Data” po 30 sekundach bez odpowiedzi. Sprawdź usługi i połączenia sieciowe.
Dublowana baza danych „Data” zmienia role z „PRINCIPAL” na „MIRROR” z powodu synchronizacji ról. (Celowo synchronizacja jest błędnie napisana, ponieważ właśnie tak wyświetla się rzeczywisty komunikat.)
Dublowana baza danych „Data” zmienia role z „PRINCIPAL” na „MIRROR” z powodu przełączenia awaryjnego.
Dublowana baza danych „Data” zmienia role z „MIRROR” na „PRINCIPAL” z powodu przełączenia awaryjnego od partnera.
Usługi SQL Server nadal działają, a połączenia sieciowe wydają się pozostawać bezczynne. Konsekwentnie mamy od 500 do 2500 sesji połączonych z każdym serwerem (głównie aplikacje robotyczne, które łączą się z kolejkami brokerów usług w jednej bazie danych).
4) Komin TCP i RSS itp. Są wyłączone przy użyciu składni NET SH.
5) Uruchomiłem SQL Server 2005 Best Practices Analyzer na obu komputerach i nie znalazłem nic poza bardzo sporadycznym błędem dziennika zdarzeń aplikacji 833, z których żaden nie jest zbieżny ze zdarzeniami przełączania awaryjnego:
Program SQL Server napotkał 1 wystąpień żądań we / wy, których wypełnienie w pliku [F: \ Data.MDF] w bazie danych [Data] trwa dłużej niż 15 sekund (9). Uchwyt pliku systemu operacyjnego to 0x00000000000010A0. Przesunięcie ostatniego długiego wejścia / wyjścia wynosi: 0x000007d4b10000).
6) Czasami pojawia się komunikat „Klient nie mógł ponownie użyć sesji z SPID XXX, który został zresetowany do puli połączeń. Ten błąd mógł być spowodowany niepowodzeniem wcześniejszej operacji. Sprawdź dzienniki błędów pod kątem operacji zakończonych niepowodzeniem bezpośrednio przed tym komunikatem o błędzie . ” wygenerowane przez oba serwery. Wygląda na to, że nie ma żadnych „wcześniejszych” komunikatów wskazujących na jakiekolwiek problemy.
7) Czasami poczta bazy danych zapisuje błąd w dzienniku zdarzeń aplikacji:
Typ wyjątku: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException Komunikat: Wystąpił błąd połączenia. Powód: Upłynął limit czasu. Limit czasu upłynął przed zakończeniem operacji lub serwer nie odpowiada., Parametry połączenia: Nazwa serwera: MGSQL02, Nazwa bazy danych: msdb Dane: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection (Microsoft.SqlServer.Management.Common. SqlConnectionInfo) HelpLink: NULL Źródło: DatabaseMailEngine
StackTrace Informacja na Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo CI) w Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccessAdapter.OpenConnection (String dbServerName, String dbname, nazwę użytkownika String, String hasło ) w Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (String dbName, String dbServerName, Int32 lifetimeMinimumSec, LogLevel loggingLevel)
Wierzę, że limity czasu powodują przełączenie awaryjne; co może spowodować te przerwy? Oczywiście, jeśli rzeczywiście wystąpił problem z siecią, taki jak zły kabel lub zły przełącznik, który może powodować utratę pakietów, a tym samym przekroczenie limitu czasu, ale jakie inne rzeczy mogą powodować limity czasu? Bloking? Jeśli MSDB lub inna systemowa baza danych miała limit czasu wejścia / wyjścia, czy mogłoby to spowodować przełączenie awaryjne lustrzane?
Dziękuję za wszelkie porady!
MSDN ma do powiedzenia na temat samego mechanizmu limitu czasu :
Mechanizm przekroczenia limitu czasu
Ponieważ błędy miękkie nie są wykrywane bezpośrednio przez instancję serwera, błąd miękki może potencjalnie spowodować, że instancja serwera będzie czekać w nieskończoność. Aby temu zapobiec, dublowanie bazy danych implementuje własny mechanizm limitu czasu, oparty na każdej instancji serwera w sesji dublowania wysyłającej polecenie ping dla każdego otwartego połączenia w ustalonych odstępach czasu.
Aby połączenie pozostało otwarte, instancja serwera musi odebrać polecenie ping dla tego połączenia w określonym czasie oczekiwania oraz czas wymagany do wysłania jeszcze jednego polecenia ping. Odebranie polecenia ping w trakcie limitu czasu wskazuje, że połączenie jest nadal otwarte i że instancje serwera komunikują się za jego pośrednictwem. Po otrzymaniu polecenia ping instancja serwera resetuje licznik przekroczenia limitu czasu dla tego połączenia.
Jeśli ping nie zostanie odebrany dla połączenia w czasie przekroczenia limitu czasu, instancja serwera uważa, że połączenie wygasło. Instancja serwera zamyka połączenie przekroczenia limitu czasu i obsługuje zdarzenie przekroczenia limitu czasu zgodnie ze stanem i trybem pracy sesji.
netsh interface tcp show global przedstawia:
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disablednetsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510SELECT name, value_in_use FROM sys.configurations
Rozproszone zapytania ad hoc 0
maska powinowactwa we / wy 0
maska powinowactwa 0
affinity64 I/O mask 0
affinity64 mask 0
Agent XPs 1
allow updates 0
awe enabled 0
blocked process threshold 5
c2 audit mode 0
clr enabled 1
common criteria compliance enabled 0
cost threshold for parallelism 4
cross db ownership chaining 0
cursor threshold -1
Database Mail XPs 1
default full-text language 1033
default language 0
default trace enabled 1
disallow results from triggers 0
fill factor (%) 0
ft crawl bandwidth (max) 100
ft crawl bandwidth (min) 0
ft notify bandwidth (max) 100
ft notify bandwidth (min) 0
index create memory (KB) 0
in-doubt xact resolution 0
lightweight pooling 0
locks 0
max degree of parallelism 6
max full-text crawl range 4
max server memory (MB) 393216
max text repl size (B) 65536
max worker threads 0
media retention 0
min memory per query (KB) 2048
min server memory (MB) 52427
nested triggers 1
network packet size (B) 1400
Ole Automation Procedures 1
open objects 0
PH timeout (s) 60
precompute rank 0
priority boost 0
query governor cost limit 0
query wait (s) -1
recovery interval (min) 0
remote access 1
remote admin connections 0
remote login timeout (s) 20
remote proc trans 0
remote query timeout (s) 600
Replication XPs 0
scan for startup procs 0
server trigger recursion 1
set working set size 0
show advanced options 1
SMO and DMO XPs 1
SQL Mail XPs 0
transform noise words 0
two digit year cutoff 2049
user connections 0
user options 4216
Procedury asystenta internetowego 0
xp_cmdshell 1
Jakiś czas temu ręcznie zmodyfikowałem mirroring_connection_timeoutwartość wszystkich lustrzanych baz danych do 30 sekund, aby spróbować rozwiązać problem; to po prostu zwiększyło czas między zdarzeniami przełączania awaryjnego. Przy mirroring_connection_timeoutustawieniu domyślnym 10 sekund widzimy znacznie więcej przełączeń awaryjnych.
Komentarz poprosił mnie o upewnienie się, że IPSec jest wyłączony, dlatego publikuję treść kilku netshpoleceń wyświetlających konfigurację IPSec systemu operacyjnego:
C: \> netsh ipsec dynamic pokaż wszystko Brak aktualnie przypisanych zasad Zasady trybu głównego niedostępne. Zasady trybu szybkiego nie są dostępne. Ogólne filtry trybu głównego niedostępne. Określone filtry trybu głównego są niedostępne. Ogólne filtry Quickmode nie są dostępne. Określone filtry trybu szybkiego nie są dostępne. Powiązania zabezpieczeń głównego trybu IPsec nie są dostępne. Powiązania zabezpieczeń IPsec QuickMode nie są dostępne. Parametry konfiguracji IPsec ------------------------------ StrongCRLCheck: 1 IPsecexempt: 3 Statystyki IPsec ---------------- Aktywny Assoc: 0 Odciąż SA: 0 Klucz oczekujący: 0 Kluczowe dodatki: 0 Kasowanie klucza: 0 ReKeys: 0 Aktywne tunele: 0 Złe parametry SPI: 0 Komputery niezszyfrowane: 0 Komputery nie uwierzytelnione: 0 Komputery z wykrywaniem powtórek: 0 Wysłane poufne bajty: 0 Otrzymane poufne bajty: 0 Wysłane uwierzytelnione bajty: 0 Otrzymane uwierzytelnione bajty: 0 Wysłane bajty transportowe: 0 Otrzymane bajty transportowe: 0 Bajty wysłane w tunelach: 0 Bajty odebrane w tunelach: 0 Wysłane bajty wysłane: 0 Odebrane pobrane bajty: 0 C: \> netsh ipsec static pokaż wszystko ERR IPsec [05072]: Brak zasad w magazynie zasad
AKTUALIZACJA: 2012-12-20
Teraz przenieśliśmy nasze systemy produkcyjne na SQL Server 2012. Działamy od 17 grudnia rano - do tej pory żadnych przełączeń awaryjnych. Jednak kilka dni jest w granicach tego, co widzieliśmy w systemach opartych na 2005 roku.
Starając się udokumentować wydajność naszych nowych systemów, przyjrzałem się sys.dm_os_wait_statsuważniej; i zauważyłem DBMIRROR_DBM_EVENT, że jest to nieudokumentowany typ oczekiwania. Graham Kent z firmy Microsoft ma ciekawy artykuł na temat rozwiązywania problemów z nieoczekiwanymi przełączeniami awaryjnymi i tego typu oczekiwania. Podsumuję jego ustalenia tutaj:
Klient miał do czynienia z ogromnym łańcuchem blokującym zbudowanym na dużej bazie danych OLTP, gdzie wszyscy główni blokujący czekali na DBMIRROR_DBM_EVENT. Oto sekwencja wydarzeń, przez które przeszedłem:
Sprawdź sam łańcuch blokujący - tutaj możesz pomóc, ponieważ wszystko, co widzimy, to czekanie na DBMIRROR_DBM_EVENT
Przejrzyj źródło nieudokumentowanego typu oczekiwania. Oczywiście nie możesz tego zrobić poza stwardnieniem rozsianym, ale mogę powiedzieć, że w momencie pisania tego typu oczekiwania reprezentuje oczekiwanie używane, gdy główny zobowiązany czeka na zahartowanie LSN, co oznacza, że transakcja, której jest częścią, nie może zatwierdzić . To natychmiast wskazuje konkretnie na problem polegający na tym, że zleceniodawca nie może zatwierdzać transakcji, ponieważ czeka na kopię lustrzaną. Teraz musimy zbadać, dlaczego serwer lustrzany nie dokonuje transakcji lub dlaczego główny zobowiązany nie wie, czy tak jest.
Przejrzyj tabele systemowe msdb
(a) Spójrz na tabelę [backupset], aby zobaczyć, czy rozmiar dzienników wyprodukowanych w momencie wystąpienia problemu jest znacznie większy niż normalny. Gdyby były wyjątkowo duże, być może lustro zostało zalane transakcjami i po prostu nie mogło nadążyć za wolumenem. Właśnie dlatego książki online podpowiadają czasami, aby wyłączyć dublowanie, jeśli konieczne jest wykonanie wyjątkowo dużej zarejestrowanej operacji, takiej jak odbudowanie indeksu. (informacje na ten temat znajdują się na stronie http://technet.microsoft.com/en-us/library/cc917681.aspx ). Tutaj użyłem następującego TSQL
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'(b) po drugie przejrzałem dane w tabelach [dbm_monitor_data]. Kluczem tutaj jest zlokalizowanie ramy czasowej, w której mieliśmy problem, a następnie sprawdzenie, czy zauważamy znaczące zmiany w którymkolwiek z poniższych:
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rateSą to wszystkie wskaźniki podobne do części (a), ponieważ mogą pokazywać komponent lub element architektury, który nie reaguje. Na przykład jeśli kolejka send_queue nagle zacznie rosnąć, ale kolejka re_do się nie powiększy, oznacza to, że zleceniodawca nie może wysłać rekordów dziennika do kopii lustrzanej, więc może warto przyjrzeć się łączności lub kolejce brokera usług zajmowanie się faktycznymi transmisjami.
W tym konkretnym scenariuszu zauważyliśmy, że wszystkie liczniki wydają się mieć dziwne wartości, ponieważ trwały kopie zapasowe dziennika o normalnych rozmiarach, ale nie było zmian statusu, 0 kolejki wysyłania, 0 kolejki powtarzania, płaska szybkość wysyłania i płaska częstość ponawiania. Jest to bardzo dziwne, ponieważ sugeruje, że DBM Monitor nie mógł zapisać żadnych wartości z dowolnego miejsca w okresie problemu.
Przejrzyj dzienniki błędów programu SQL Server. W tym przypadku nie było żadnych błędów ani komunikatów informacyjnych, ale w innych scenariuszach, takich jak ten, bardzo często zgłaszane są błędy w zakresie 1400, których przykłady można znaleźć w innych miejscach na moich innych blogach lustrzanych, takich jak ten przykład błędu 1413
Przejrzyj domyślne pliki śledzenia - w tym scenariuszu nie podano domyślnych danych śledzenia, jednak są one fantastycznymi źródłami informacji o problemach DBM, ponieważ rejestrują zdarzenia zmiany stanu u wszystkich partnerów. Jest to udokumentowane tutaj:
Dublowanie bazy danych Zmień klasę zdarzenia
Często daje to doskonały obraz scenariuszy, takich jak awaria połączenia sieciowego między jednym lub wszystkimi partnerami, a następnie stan partnerstwa.
WNIOSKI:
W tym konkretnym scenariuszu obecnie brakuje mi 2 kluczowych punktów danych, ale oprócz tego wciąż mogę wysunąć rozsądną hipotezę na podstawie powyższych informacji. Z pewnością możemy powiedzieć, że blokowanie było spowodowane faktem, że DBM został włączony z powodu wszystkich blokerów oczekujących na typ oczekiwania DBMIRROR_DBM_EVENT. Ponieważ wiemy, że nie zalaliśmy kopii lustrzanej dużą rejestrowaną operacją i że to wdrożenie zwykle działa w tym trybie szczęśliwie, możemy wykluczyć nietypowe duże operacje. Oznacza to, że na tym etapie mamy 2 potencjalnych kandydatów:
Problemy sprzętowe w łączności między niektórymi lub wszystkimi partnerami.
Wyczerpanie procesora na serwerze kopii lustrzanych - po prostu nie nadążając za redos - wyczerpanie procesora może samo w sobie wynikać z procesu poza SQL Server lub poza tym powiązaniem kopii lustrzanych.
Problem z samym kodem kopii lustrzanej (aby to potwierdzić, naprawdę potrzebowalibyśmy zrzutów pamięci).
Opierając się na doświadczeniu, które podejrzewam o 1 lub 2, ale zawsze mam otwarty umysł również na 3, staramy się teraz zebrać więcej danych, aby bardziej szczegółowo przyjrzeć się temu problemowi.
źródło
Odpowiedzi:
Wygląda na to, że zabrakło portów TCP na serwerze SQL. Ile połączeń widzisz jednocześnie z serwerem?
Takie przerwy na pewno spowodowałyby problem.
źródło
Można sprawdzić
sys.dm_os_schedulers? W szczególności, czywork_queue_countodbiega od 0 przez jakiś znaczący czas? Oznaczałoby to głód pracowników i wyjaśniałoby wiele twoich objawów.źródło
sys.dm_os_schedulersnie pokazuje wyników dlaSELECT * FROM sys.dm_os_schedulers WHERE work_queue_count > 0;- czy powinienem to nagrywać co minutę?