KB3009974 – RETTELSE: Langsom synkronisering, når diske har forskellige sektorstørrelser for primære og sekundære replikalogfiler i SQL Server AG- og Logshipping-miljøer

Symptomer

Overvej følgende scenarie:

• Du aktiverer funktionen AlwaysOn Availability Groups eller Logshipping i Microsoft SQL Server.

• De diske, der gemmer logfilerne for den primære og sekundære replika i en AlwaysOn-tilgængelighedsgruppe (AG), har forskellige sektorstørrelser. Eller i Logshipping-miljøer har de diske, som lagrer logfilerne for logshipping primære servere og Logshipping sekundære servere, forskellige sektorstørrelser. For eksempel:

  • Den primære replikalogfil er placeret på en disk, der har en sektorstørrelse på 512 byte. Den sekundære replikalogfil er dog placeret på en disk, der har sektorstørrelsen 4 kilobyte (KB).

  • Den primære replikalogfil er placeret på et lokalt lokalt system, der har en sektorstørrelse på 512 byte. Den sekundære replika er dog placeret på en Windows Azure Storage-disk, der har en sektorstørrelse på 4 kilobyte (KB).

I dette scenarie logføres følgende fejlmeddelelse i SQL Server fejllog. Fejlmeddelelsen kan fortsætte et stykke tid efter genstart, hvis der var logfiler, der ikke blev anvendt på sekundært, før serveren blev genstartet.

Desuden kører AG- eller Logshipping-synkronisering meget langsomt på grund af det synkrone I/Os. Hvis den sekundære replika findes i Windows Azure Storage, tager det meget længere tid end forventet at afslutte synkroniseringsprocessen.

Bemærk! Dette problem opstår, når du bruger både de nye drev, der har en sektorstørrelse på 4 KB, og de gamle drev, der har en sektorstørrelse på 512 byte. Du kan få mere at vide om de nye drev under SQL Server – Nye drev Brug 4K-sektorstørrelse og SQL Server –Lagerpladser/VHDx og 4K-sektorstørrelse.

Løsning

Problemet blev først rettet i følgende kumulative opdatering af SQL Server.

Løsning

Du kan løse dette problem ved at flytte transaktionslogfilen på destinationen til et drev, hvor Byte pr. fysisk sektor er angivet som 512 byte.

Status

Microsoft har bekræftet, at problemet findes i de Microsoft-produkter, der er angivet i afsnittet "Gælder for".

Flere oplysninger

Som bedste fremgangsmåde kan du prøve at sikre, at alle diske på alle replikaer (mindst alle diske, der hoster logfiler) har samme sektorstørrelse. I blandede miljøer, hvor den sekundære har en fysisk sektor på 512 byte, og den primære har en sektorstørrelse på 4 KB, bør TF 1800 bruges som et startflag på alle servere eller replikaer, der har en fysisk sektorstørrelse på 512 byte og genstartes. Dette sikrer, at det igangværende logoprettelsesformat bruger en sektorstørrelse på 4 KB.

Du kan få mere at vide om, hvordan SQL Server fungerer med større sektorstørrelser, i følgende indlæg på supportbloggen:

SQL Server –Lagerpladser/VHDx- og 4K-sektorstørrelse

Du kan bruge kommandopromptværktøjet Fsutil til at bestemme værdien Byte pr. fysisk sektor. Hvis denne parameter ikke er synlig i outputtet, skal du anvende det hotfix, der er angivet i vidensbaseartikel 982018.

Følg disse trin for at bekræfte, hvilken type drev du har:

1. Kør følgende kommando ved en kommandoprompt med administratorrettigheder:

   Fsutil fsinfo ntfsinfo x: Bemærk! Pladsholderen x repræsenterer det drev, du kontrollerer.

2. Brug værdierne for Byte pr. sektor og Byte pr. fysisk sektor til at bestemme, hvilken type drev du har. Det kan du gøre ved at bruge følgende tabel:

   Værdien "Byte pr. sektor"	Værdien "Byte pr. fysisk sektor"	Drevtype
   4096	4096	4K native
   512	4096	Avanceret format (også kaldet 512E)
   512	512	512-byte native