Oprava: Pomalé synchronizace při disky mají velikost různých odvětví pro primární a sekundární replikovaných souborů protokolu v prostředí SQL Server AG a Logshipping

DŮLEŽITÉ: Tento článek je přeložen pomocí softwaru na strojový překlad Microsoft. Nepřesný či chybný překlad lze opravit prostřednictvím technologie Community Translation Framework (CTF). Microsoft nabízí strojově přeložené, komunitou dodatečně upravované články, a články přeložené lidmi s cílem zajistit přístup ke všem článkům v naší znalostní bázi ve více jazycích. Strojově přeložené a dodatečně upravované články mohou obsahovat chyby ve slovníku, syntaxi a gramatice. Společnost Microsoft není odpovědná za jakékoliv nepřesnosti, chyby nebo škody způsobené nesprávným překladem obsahu nebo jeho použitím našimi zákazníky. Více o CTF naleznete na http://support.microsoft.com/gp/machine-translation-corrections/cs.

Projděte si také anglickou verzi článku: 3009974
Poznámka
Poznámka: Po použití této opravy hotfix musíte povolit příznak trasování 1800 na všech serverech Chcete-li tuto opravu hotfix pracovat správně.
Příznaky
Jde o takovouto situaci:
  • Funkce skupiny dostupnosti AlwaysOn nebo Logshipping v Microsoft SQL Server 2012 a SQL Server 2014.
  • Disky, které ukládají soubory protokolu primární a sekundární replik v AlwaysOn dostupnost skupiny (AG) mají velikost různých odvětví. Nebo v Logshipping prostředí, že úložiště protokolu soubory pro primární a sekundární servery Logshipping Logshipping disky velikosti různých odvětví. Například:
    • Repliku primární soubor protokolu je umístěn na disku, který má velikost sektoru 512 bajtů. Však repliky sekundární soubor protokolu je umístěn na disku, který je 4 kilobajty (KB) velikost sektoru.
    • Soubor protokolu primární replika je umístěna v prostorách místního systému, který má velikost sektoru 512 bajtů. Sekundární replik však je umístěn na disku Windows Azure Storage, který je 4 kilobajty (KB) velikost sektoru.
V tomto případě je v protokolu chyb serveru SQL Server zaznamenána následující chybová zpráva:

Byly X nesprávně zarovnány protokolu IOs který požadované pádu zpět k synchronní vstupně-výstupní. Aktuální IO je v souboru...

Kromě toho AG nebo Logshipping synchronizace je velmi pomalý z důvodu synchronní vstupně-výstupních. Pokud sekundární repliky ve Windows Azure Storage, trvá mnohem déle, než je očekáváno dokončení procesu synchronizace.

Poznámka: K tomuto problému dochází při použití nových jednotek, které mají velikost 4 KB sektoru i staré jednotky, které mají velikost sektoru 512 bajtů. Další informace o nové jednotky viz SQL Server - nové disky použít 4 kB sektoru velikost a SQL Server – skladovací prostory/VHDx a velikost 4 kB sektoru.
Řešení
Tento problém byl poprvé opraven v následující kumulativní aktualizace serveru SQL Server.

Kumulativní aktualizace 5 pro SQL Server 2014

Kumulativní aktualizace 3 pro SQL Server 2012 SP2

Kumulativní aktualizace 13 pro SQL Server 2012 SP1

Opravy hotfix a povolit příznak trasování 1800 na primární servery, Všimněte si malé zvýšení velikosti následující soubory:
  • Soubor protokolu transakcí
  • Záloh protokolu
Navíc zjistíte, že jsou zaznamenány následující zprávy v protokolu chyb serveru SQL Server primárním serverem:

Zadní část protokolu pro databázi.Název databáze> "přepsána tak, aby odpovídala nové velikosti sektoru 4096 bajtů

Toto je informační zpráva, která může být bezpečně ignorována.

O kumulativní aktualizace pro SQL Server

Každé nové kumulativní aktualizace pro SQL Server obsahuje všechny opravy hotfix a všechny opravy zabezpečení, které byly součástí předchozí kumulativní aktualizace. Viz nejnovější kumulativní aktualizace pro SQL Server:

Jak potíže obejít
Chcete-li tento problém vyřešit, přesuňte soubor protokolu transakcí v místě určení na jednotku, která obsahuje počet bajtů za fyzický sektor nastavit jako 512 bajtů.
Prohlášení
Společnost Microsoft potvrdila, že se jedná o problém v produktech společnosti Microsoft, které jsou uvedeny v části "Platí pro".
Další informace
Jako nejvhodnější je pokuste Ujistěte se, že všechny disky u všech replik (alespoň všechny disky, které jsou hostiteli soubory protokolu) mají stejnou velikost sektoru. Ve smíšených prostředích, kde má sekundární fyzického sektoru 512 bajtů a primární má velikost sektoru 4 kB, TF 1800 by měl použít spouštěcí příznak na všech serverech (zvláště servery, které mají fyzického sektoru 512 bajtů), že můžete přechod do primární roli. Tím je zajištěno, že používá formát protokolu průběžné vytváření velikost 4 KB sektoru.

Další informace o serveru SQL Server s větší velikostí sektorů naleznete v následující post na blogu podpory:

SQL Server – skladovací prostory/VHDx a velikost 4 kB sektoru

Můžete použít Nástroj příkazového řádku Fsutil k určení hodnoty bajtů za fyzický sektor. Pokud tento parametr není zobrazen ve výstupu, je třeba použít opravu hotfix, která je určena v Článek znalostní BÁZE 982018.

Chcete-li ověřit typ jednotky, které máte, postupujte takto:
  1. Spusťte následující příkaz na příkazovém řádku se zvýšenými oprávněními:
    Fsutil fsinfo ntfsinfo x:
    Poznámka: Zástupný symbol x představuje jednotku, které kontrolujete.
  2. K určení typu jednotky, které máte použijte hodnoty Bajtů na sektor a bajty na fyzický sektor . Chcete-li to provést, použijte následující tabulku:
    Hodnota "Bajtů na sektor"Hodnota "Bajty na fyzický sektor"Typ jednotky
    40964096Nativní 4 kB
    5124096Rozšířený formát (512E)
    512512nativní 512 bajtů

Upozornění: Tento článek je přeložený automaticky

خصائص

رقم الموضوع: 3009974 - آخر مراجعة: 01/19/2016 19:37:00 - المراجعة: 6.0

Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Standard

  • kbqfe kbhotfixserver kbfix kbsurveynew kbexpertiseadvanced kbmt KB3009974 KbMtcs
تعليقات