KB3009974 - FIX: trage synchronisatie wanneer schijven verschillende sectorgrootten hebben voor primaire en secundaire replicalogboekbestanden in SQL Server AG- en logboekregistratieomgevingen

Symptomen

Neem het volgende scenario:

• U schakelt de functie AlwaysOn-beschikbaarheidsgroepen of Logboekregistratie in Microsoft SQL Server in.

• De schijven waarin de logboekbestanden van de primaire en secundaire replica in een AlwaysOn-beschikbaarheidsgroep (AG) worden opgeslagen, hebben verschillende sectorgrootten. Of in Logshipping-omgevingen hebben de schijven waarin de logboekbestanden voor primaire logshipping-servers en logshipping secundaire servers worden opgeslagen, verschillende sectorgrootten. Bijvoorbeeld:

  • Het primaire replicalogboekbestand bevindt zich op een schijf met een sectorgrootte van 512 bytes. Het secundaire replicalogboekbestand bevindt zich echter op een schijf met een sectorgrootte van 4 kB (kB).

  • Het primaire replicalogboekbestand bevindt zich op een lokaal on-premises systeem met een sectorgrootte van 512 bytes. De secundaire replica bevindt zich echter op een Windows Azure Storage-schijf met een sectorgrootte van 4 kB (kB).

In dit scenario wordt het volgende foutbericht vastgelegd in het SQL Server Foutenlogboek. Het foutbericht kan een tijdje duren nadat het opnieuw is opgestart als er logboeken waren die niet waren toegepast op secundaire voordat de server opnieuw werd opgestart.

Bovendien wordt de synchronisatie van AG of logboekregistratie zeer langzaam uitgevoerd vanwege de synchrone I/O's. Als de secundaire replica zich in Windows Azure Storage bevindt, duurt het veel langer dan verwacht om het synchronisatieproces te voltooien.

Opmerking Dit probleem treedt op wanneer u zowel de nieuwe stations met een sectorgrootte van 4 kB als de oude stations met een sectorgrootte van 512 bytes gebruikt. Zie voor meer informatie over de nieuwe stations SQL Server - Nieuwe stations 4K sectorgrootte gebruiken en SQL Server–Opslagruimten/VHDx- en 4K-sectorgrootte.

Oplossing

Het probleem is voor het eerst opgelost in de volgende cumulatieve update van SQL Server.

Tijdelijke oplossing

U kunt dit probleem omzeilen door het transactielogboekbestand op de bestemming te verplaatsen naar een station met bytes per fysieke sector ingesteld op 512 bytes.

Status

Microsoft heeft bevestigd dat dit probleem zich kan voordoen in de Microsoft-producten die worden vermeld in de sectie Van toepassing op.

Meer informatie

Als best practice kunt u ervoor zorgen dat alle schijven op alle replica's (ten minste alle schijven waarop logboekbestanden worden gehost) dezelfde sectorgrootte hebben. In gemengde omgevingen, waarbij de secundaire een fysieke sector van 512 bytes heeft en de primaire een sectorgrootte van 4 kB heeft, moet TF 1800 worden gebruikt als opstartvlag op alle servers of replica's met een fysieke sectorgrootte van 512 bytes en opnieuw worden gestart. Dit zorgt ervoor dat de indeling voor het maken van logboeken een sectorgrootte van 4 kB gebruikt.

Voor meer informatie over hoe SQL Server werkt met grotere sectorgrootten, raadpleegt u het volgende bericht op de ondersteuningsblog:

SQL Server-Opslagruimten/VHDx en 4K sectorgrootte

U kunt het opdrachtprompthulpprogramma Fsutil gebruiken om de waarde van bytes per fysieke sector te bepalen. Als deze parameter niet zichtbaar is in de uitvoer, moet u de hotfix toepassen die is opgegeven in het KB-artikel 982018.

Voer de volgende stappen uit om te controleren welk type station u hebt:

1. Voer de volgende opdracht uit bij een opdrachtprompt met verhoogde bevoegdheid:

   Fsutil fsinfo ntfsinfo x: Opmerking De tijdelijke aanduiding x vertegenwoordigt het station dat u controleert.

2. Gebruik de waarden voor bytes per sector en bytes per fysieke sector om het type station te bepalen dat u hebt. Gebruik hiervoor de volgende tabel:

   Waarde 'Bytes per sector'	Waarde 'Bytes per fysieke sector'	Stationstype
   4096	4096	4K systeemeigen
   512	4096	Geavanceerde indeling (ook wel bekend als 512E)
   512	512	Systeemeigen 512-bytes