it-swarm-eu.dev

Co může způsobit vypršení časového limitu zrcadlení relace a poté převzetí služeb při selhání?

Máme dva produkční servery SQL se spuštěným serverem SQL Server 2005 SP4 s kumulativní aktualizací 3. Oba servery běží na stejných fyzických počítačích. Dell PowerEdge R815 s 4 x 12 jádrovými procesory a 512 GB (ano GB) RAM, s 10 GB iSCSI SAN připojených jednotek pro všechny databáze a protokoly SQL. OS je Microsoft Windows Server 2008 R2 Enterprise Edition s všechny aktualizace SP a oken. Jednotka OS je pole RAID 5 o velikosti 3 x 72 GB 2,5 "15k SAS jednotky. SAN je Dell EqualLogic 6510 s 48 x 10K SAS= 3,5 "disky, nakonfigurované v RAID 50, nakrájené na různé LUN pro 2 SQL servery a také sdíleny se strojem Exchange a několika servery VMWare.

Máme více než 20 databází, z nichž 11 je zrcadlených s vysokou dostupností pomocí serveru svědků. Server svědků je stroj s nižším výkonem, který běží instanci serveru SQL Server a který se používá pouze pro poskytování služeb svědků. Největší zrcadlená databáze je 450 GB a generuje kolem 100-300 iops. Program Database Mirroring Monitor hlásí aktuální rychlost odesílání přibližně 100 kb až 10 MB za sekundu a zrcadlení potvrzuje režii (obvykle) 0 milisekund. Zrcadlový server nemá problém udržet krok s hlavním.

Neustále prožíváme zrcadlení převzetí služeb při selhání. Někdy jediná databáze selže, jindy téměř všechny databáze selže současně. Například včera jsme měli 10 z 11 převzetí služeb při selhání databází, zbývající databáze zůstala přístupná, dokud jsem ji ručně nezklamal.

Prošel jsem několika kroky pro řešení problémů, abych se pokusil problém identifikovat, ale dosud jsem nebyl schopen problém vyřešit:

1) Stroj byl dodán s gigabitovým síťovým adaptérem Broadcom BCM5709C NetXtreme II 4 port Gigabit, který jsme původně používali jako primární síťové připojení. Od té doby jsme do obou počítačů nainstalovali serverový adaptér Intel (R) PRO/1000 PT pro duální port, abychom eliminovali problém NIC).

2) Všechny databáze mají automatickou plnou zálohu přes noc a zálohu protokolu pro databáze zapojené do zrcadlení. Použití souboru protokolu je monitorováno a jen zřídka se používá nad 15%. Soubor žurnálu pro hlavní databázi je 125 GB a skládá se ze 159 virtuálních souborů žurnálu s velikostí od 511 MB do 1 GB. TempDB je na své vlastní LUN a skládá se z 24 x 2 GB souborů.

3) Protokol SQL Server na svědka nevykazuje žádné chyby kromě: Zrcadlení připojení k „TCP: //SQL02.DOMAIN.INET: 5022“ vypršelo vypršení časového limitu pro databázi „Data“ po 30 sekundách bez odpovědi. Zkontrolujte servisní a síťové připojení.

Protokol SQL Server na primárním a sekundárním serveru zobrazuje zprávy týkající se zrcadlení:

Zrcadlení připojení k protokolu „TCP: //SQL01.DOMAIN.INET: 5022“ vypršelo pro databázi „Data“ po 30 sekundách bez odpovědi. Zkontrolujte servisní a síťové připojení.

Zrcadlená databáze „Data“ mění role z „PRINCIPÁLNÍ“ na „ZRCADLENÍ“ v důsledku synchronizace rolí. (Synchronizace je zde záměrně chybně napsána, protože přesně tak se zobrazuje skutečná zpráva.)

Zrcadlená databáze "Data" mění role z "PRINCIPAL" na "MIRROR" kvůli Failover.

Zrcadlená databáze „Data“ mění role z „MIRROR“ na „PRINCIPAL“ kvůli převzetí služeb při selhání od partnera.

Služby serveru SQL nadále běží a zdá se, že síťová připojení zůstávají nahoře. Ke každému serveru je trvale připojeno 500 až 2500 relací (především robotické aplikace, které se připojují ke frontám servisních brokerů na jedné databázi).

4) TCP Komín a RSS atd. Jsou deaktivovány pomocí syntaxe NET SH).

5) Spustil jsem analyzátor osvědčených postupů serveru SQL Server 2005 proti oběma strojům a nenašel jsem nic jiného než samotnou chybu 833 protokolu událostí aplikace, z nichž žádná není shodná s událostmi převzetí služeb při selhání:

SQL Server zaznamenal 1 výskyt (i) I/O požadavků, které trvalo déle než 15 sekund, než bylo dokončeno v souboru [F:\Data.MDF] v databázi [Data] (9). Popisovač souboru OS je 0x0000000000001010. Posun poslední dlouhé I/O je: 0x000007d4b10000).

6) Občas vidíme „Klient nemohl znovu použít relaci se SPID XXX, která byla resetována pro sdružování připojení. Tato chyba mohla být způsobena selháním dřívější operace. Zkontrolujte, zda v protokolech chyb nebyly neúspěšné operace těsně před touto chybovou zprávou. . “ generované oběma servery. Zdá se, že neexistují žádné „dřívější“ zprávy, které by naznačovaly jakýkoli problém.

7) Občas databáze mail zapíše chybu do protokolu událostí aplikace:

Typ výjimky: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException Zpráva: Při připojení došlo k chybě. Důvod: Časový limit vypršel. Časový limit, který uplynul před dokončením operace nebo server neodpovídá., Parametry připojení: Název serveru: MGSQL02, Název databáze: msdb Data: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection) (Microsoft.SqlServer.Management.Common.SqlConnectionInfo) HelpLink: NULL Zdroj: DatabaseMailEngine

Informace o StackTrace na Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo ci) na Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccessAdapter.OpenConnection (String dbServerName, String dbName, String user, String user, String user, String user, String user ) na Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (String dbName, String dbServerName, Int32 lifetimeMinimumSec, LogLevel loggingLevel)

Věřím, že Timeouty způsobují převzetí služeb při selhání; co by mohlo způsobit tyto časové limity? Je zřejmé, že pokud se vyskytl skutečný problém se sítí, jako je špatný kabel nebo špatný přepínač, který by mohl způsobit ztrátu paketů, a tedy i časový limit, jaké další věci však mohou způsobit časový limit? Blokování? Pokud měl MSDB nebo jiná systémová databáze časový limit I/O, mohlo by to způsobit převzetí služeb při selhání zrcadlení?

Díky za radu!

MSDN má následující o samotném mechanismu časového limit :

Mechanismus zrcadlení časového limitu

Protože měkké chyby nelze detekovat přímo serverovou instancí, může měkká chyba potenciálně způsobit, že instance serveru bude čekat neomezeně dlouho. Chcete-li tomu zabránit, zrcadlení databáze implementuje svůj vlastní mechanismus časového limitu, založený na každé instanci serveru v relaci zrcadlení odesílající ping při každém otevřeném připojení v pevném intervalu.

Chcete-li udržovat připojení otevřené, musí instance serveru obdržet ping na toto připojení v definovaném časovém limitu plus čas, který je nutný k odeslání dalšího ping. Přijetí příkazu ping během časového limitu znamená, že připojení je stále otevřené a instance serveru komunikují přes něj. Po přijetí příkazu ping instance serveru resetuje svůj čítač časového limitu při tomto připojení.

Pokud během časového limitu není na připojení přijato žádné ping, instance serveru považuje připojení za vypršené. Instance serveru uzavře připojení s časovým limitem a zpracovává událost časového limitu podle stavu a provozního režimu relace.

netsh interface tcp show global ukazuje:

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                 : disabled

netsh interface ipv4 show dynamicportrange tcp

Protocol tcp Dynamic Port Range

Start Port      : 1025
Number of Ports : 64510

SELECT name, value_in_use FROM sys.configurations

 Ad Hoc Distribuované dotazy 0 
 Afinitní I/O maska ​​0 
 Afinitní maska ​​0 
 Afinitní64 I/O maska ​​0 
 Afinitní64 maska ​​0 
 Agent XP 1 
 Umožňuje aktualizace 0 
 Awe povoleno 0 
 Blokováno práh procesu 5 
 C2 režim auditu 0 
 Clr povoleno 1 
 splnění společných kritérií povoleno 0 
 prahová hodnota nákladů pro paralelismus 4 
 křížové vlastnictví řetězení 0 
 práh kurzoru -1 
 Databázová pošta XP 1 
 výchozí fulltextový jazyk 1033 
 výchozí jazyk 0 
 výchozí trasování povoleno 1 
 zakázat výsledky ze spouštěčů 0 
 faktor výplně (%) 0 
 ft šířka pásma procházení (max.) 100 
 ft šířka pásma procházení (min) 0 
 ft oznámit šířku pásma (max) 100 
 ft oznámit šířku pásma (min) 0 
 index vytváří paměť (KB) 0 
 pochybné rozlišení xact 0 
 lehké sdružování 0 
 zámky 0 
 maximální stupeň rovnoběžnosti 6 
 maximální fulltextový rozsah procházení 4 
 max. paměť serveru (MB) 393216 
 Maximální velikost textové odpovědi (B) 65536 
 Max. Pracovní vlákna 0 
 Uchovávání médií 0 
 Min. Paměť na dotaz (KB) 2048 
 Min paměť serveru (MB) 52427 
 vnořené spouštěče 1 
 velikost síťového paketu (B) 1400 
 Ole Automation Procedures 1 
 otevřené objekty 0 
 Timeout PH (s) 60 
 pořadí předkompaktů 0 
 zvýšení priority 0 
 limit nákladů na správu dotazů 0 
 interval čekání na dotazy -1 
 interval obnovy ( min) 0 
 vzdálený přístup 1 
 Připojení vzdáleného administrátora 0 
 Časový limit vzdáleného přihlášení 20 
 Vzdálený proc trans 0 
 Časový limit vzdáleného dotazu 600 
 Replikace XP 0 
 Vyhledávání spouštěcích procesů 0 
 Spuštění serveru rekurze 1 
 Sada pracovní sady velikost 0 
 Ukazují pokročilé možnosti 1 
 SMO a DMO XP 1 
 SQL Mail XP 0 
 Transformace šumových slov 0 
 Dvoumístné mezní omezení 2049 
 Uživatelská připojení 0 
 Uživatelské možnosti 4216 
 Web Assistant Proce vytvrzuje 0 
 xp_cmdshell 1 

Před chvílí jsem manuálně upravil mirroring_connection_timeout hodnota pro všechny zrcadlené databáze do 30 sekund při pokusu o nápravu problému; toto jednoduše prodloužilo dobu mezi událostmi převzetí služeb při selhání. S mirroring_connection_timeout nastavení nastavené na výchozí 10 sekund, vidíme lot více převzetí služeb při selhání.

Komentář mě požádal, abych zajistil, že IPSec je zakázán, takže zveřejňuji obsah několika příkazů netsh, které zobrazují konfiguraci IPSec operačního systému:

 
 C: \> netsh ipsec dynamic show all 
 Žádná aktuálně přiřazená politika 
 Mainmode Policies nejsou k dispozici. 
 Quickmode Policies nejsou k dispozici. 
 Obecné filtry Mainmode nejsou k dispozici. 
 Specifické filtry Mainmode nejsou k dispozici. 
 Obecné filtry Quickmode nejsou k dispozici. 
 Specifické filtry Quickmode nejsou k dispozici. 
 Zabezpečení IPsec MainMode Asociace nejsou k dispozici. 
 IPsec QuickMode Security Association nejsou k dispozici. 
 
 Konfigurační parametry IPsec 
 ---------------- -------------- 
 StrongCRLCheck: 1 
 IPsecexempt: 3 
 
 Statistiky IPsec 
 --- ------------- 
 Aktivní Assoc: 0 
 Offload SAs: 0 
 Čekající klíč: 0 
 Přidání klíčů: 0 
 Vymazání klíčů: 0 
 ReKeys: 0 
 Aktivní tunely: 0 
 Špatné SPI Pkts) : 0 
 Pkts dešifrováno: 0 
 Pkts neověřeno: 0 
 Pkts s detekcí opakování: 0 
 Důvěrné bajty odeslány: 0 
 Důvěrné bajty Přijato: 0 
 Ověřené bajty odeslány: 0 
 Ověřené bajty přijaty: 0 
 Přepravní bajty odeslány: 0 
 Přepravní bajty přijaty: 0 
 Byty odeslány V tunelech: 0 
 Bajtů přijatých V tunelech: 0 
 Offloaded Bajtů odesláno: 0 
 Offloaded Bajtů přijato: 0 
 
 C: \> netsh ipsec static show all 
 ERR IPsec [05072]: Žádné zásady v úložišti politik 
 




AKTUALIZACE: 2012-12-20

Nyní jsme přesunuli naše produkční systémy na server SQL Server 2012. To jsme provozovali od rána 17. prosince - zatím žádné převzetí služeb při selhání. Pár dní je však v tom, co jsme viděli u systémů založených na roce 2005.

Ve snaze dokumentovat výkon našich nových systémů jsem se díval na sys.dm_os_wait_stats opatrněji; a všiml si DBMIRROR_DBM_EVENT, což je nezdokumentovaný typ čekání. Graham Kent ve společnosti Microsoft má zajímavý článek řešení problémů s neočekávaným převzetím služeb při selhání a tento typ čekání. Zde své shrnutí shrnu:

Zákazník zažil obrovský blokovací řetězec postavený na velkém objemu OLTP databáze, kde všichni blokátory hlav čekali na DBMIRROR_DBM_EVENT. Zde je sled událostí, kterými jsem procházel:

  1. Prohlédněte si blokovací řetězec samotný - zde je nápověda, protože vidíme pouze to, že čekáme na DBMIRROR_DBM_EVENT

  2. Zkontrolujte zdroj pro nezdokumentovaný typ čekání. Samozřejmě to nemůžete udělat mimo MS, ale mohu říci, že v době psaní tento typ čekání představuje čekání použité, když hlavní čeká, až zrcadlo ztvrdne LSN, což znamená, že transakce, jejíž součástí je, se nemůže zavázat . Okamžitě to zcela konkrétně ukazuje na problém, že hlavní účetní jednotka nemůže provádět transakce, protože čeká na zrcadlo. Nyní musíme prozkoumat, proč zrcadlo neučiní transakce nebo proč ředitel neví, zda je.

  3. Zkontrolujte systémové tabulky msdb

(a) Podívejte se na tabulku [backupset] a zjistěte, zda je velikost protokolů vytvořených v době problému výrazně vyšší než normální. Pokud by byly mimořádně velké, mohlo by se stát, že zrcadlo bylo zaplaveno transakcemi a jednoduše nemohlo držet krok s objemem. To je důvod, proč vám knihy online někdy řeknou, abyste zakázali zrcadlení, pokud potřebujete provést mimořádně velkou protokolovanou operaci, například znovu vytvořit index. (odkaz na důvod --- http://technet.Microsoft.com/en-us/library/cc917681.aspx ). Zde jsem použil následující 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) zadruhé jsem se podíval na data v tabulkách [dbm_monitor_data]. Klíčem je zde najít časový rámec, ve kterém jsme měli problém, a pak zjistit, zda jsme významně zaznamenali změny v některém z následujících:

log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rate

To jsou všechny ukazatele podobné části (a) v tom, že mohou ukazovat komponentu nebo část architektury, která neodpovídala. Například pokud se send_queue náhle začne rozrůstat, ale fronta re_do neroste, pak by to znamenalo, že ředitel nemůže odeslat záznamy protokolu do zrcadla, takže byste se chtěli podívat na možná připojení nebo fronty servisních brokerů zabývat se skutečnými přenosy.

V tomto konkrétním scénáři jsme si všimli, že všechny čítače vypadaly, že mají podivné hodnoty, protože došlo k zálohování protokolů normální velikosti, ale nedošlo k žádným změnám stavu, 0 odesílací fronty, 0 opakování fronty, plochá rychlost odesílání a byt opakovat sazbu. To je velmi podivné, protože to znamená, že monitor DBM nemohl zaznamenat žádné hodnoty odkudkoli během problémového období.

  1. Zkontrolujte protokoly chyb serveru SQL. V tomto případě nedošlo k žádným chybám ani informačním zprávám, ale v jiných scénářích, jako je tento, je velmi běžné, že se budou hlásit chyby v rozsahu 1400, jejichž příklady najdete na jiných místech v mých dalších zrcadlených blogech, jako je například tento příklad chyby 1413

  2. Zkontrolujte výchozí soubory trasování - v tomto scénáři mi nebyly poskytnuty výchozí stopy, jsou však fantastickým zdrojem informací o problému DBM, protože zaznamenávají události změny stavu u všech partnerů. To je dokumentováno zde:

třída událostí zrcadlení stavu změny databáze

To vám často poskytne skvělý obrázek o scénářích, jako například při selhání síťového připojení mezi jedním nebo všemi partnery a poté, co se stav partnerství stal později.

ZÁVĚRY:

V tomto konkrétním scénáři v současné době chybí 2 klíčové body údajů, ale že na rozdíl od výše uvedených informací mohu ještě učinit rozumnou hypotézu. Určitě lze říci, že blokování bylo způsobeno skutečností, že DBM bylo povoleno kvůli tomu, že všichni blokátory čekající na typ čekání DBMIRROR_DBM_EVENT. Jelikož víme, že jsme nezaplavili zrcadlo velkou zaznamenanou operací a že toto nasazení normálně běží šťastně v tomto režimu, můžeme vyloučit neobvyklé velké operace. To znamená, že v této fázi máme 2 potenciální kandidáty:

  1. Problémy s hardwarem týkající se připojení mezi některými nebo všemi partnery.

  2. Vyčerpání CPU na zrcadlovém serveru - jednoduše neschopné držet krok s opakováním - vyčerpání CPU by mohlo být samo o sobě z procesu mimo SQL Server nebo mimo toto zrcadlové partnerství.

  3. Problém se samotným zrcadlícím kódem (k potvrzení toho však potřebujeme nějaké výpisy paměti).

Na základě zkušeností bych měl podezření na 1 nebo 2, ale vždy si také udržuji otevřenou mysl asi na 3, nyní se snažíme shromáždit nějaké další údaje, abychom se na tento problém podívali podrobněji.

22
Max Vernon

Zní to, jako by vám na serveru SQL Server chyběly porty TCP). Kolik připojení vidíte najednou na server?

Časové limity, jako by to určitě způsobovaly problém.

6
mrdenny

Můžete to zkontrolovat sys.dm_os_schedulers ? Konkrétně, work_queue_count se odchyluje od 0 na nějakou významnou dobu? To by naznačovalo hladovění pracovníků a vysvětlovalo by to mnoho vašich příznaků.

2
Remus Rusanu