Korriger: Langsom synkronisering når disker har forskjellige sektorstørrelser for primære og sekundære replika loggfiler i SQL Server AG og Logshipping miljøer

Symptomer

Tenk deg følgende:

• Du aktiverer funksjonen AlwaysOn tilgjengelighetsgrupper eller Logshipping i Microsoft SQL Server.

• Diskene som inneholder loggfiler for den primære og sekundære replikaen i et AlwaysOn tilgjengelighet gruppe (AG) har ulike sektorstørrelser. Eller i Logshipping miljøer, diskene at butikken i loggfiler for Logshipping primære servere og Logshipping sekundære servere har forskjellige sektorstørrelser. For eksempel:

  • Den primære replika loggfilen ligger på en disk med en sektorstørrelse på 512 byte. Sekundær replika loggfilen ligger imidlertid på en disk som har sektorstørrelsen til 4 kilobyte (KB).

  • Den primære replika loggfilen ligger på et lokalt system for lokale med en sektorstørrelse på 512 byte. Imidlertid er sekundære replikaen plassert på en disk for Windows Azure-lagring som har sektorstørrelsen til 4 kilobyte (KB).

I denne situasjonen logges følgende feilmelding i feilloggen for SQL Server. Feilen melding kan fortsette en stund etter omstart hvis det hadde vært loggene som ikke ble brukt til sekundære før du starter serveren på nytt.

I tillegg kjører synkronisering AG eller Logshipping svært sakte på grunn av synkron Oppgavebehandling. Hvis den sekundære replikaen er Windows Azure lagring, tar det mye lengre tid enn forventet å fullføre synkroniseringen.

Obs! Dette problemet oppstår når du bruker både nye disker med en sektorstørrelse på 4 KB, og de gamle stasjonene som har en 512-byte sektorstørrelse. Hvis du vil ha mer informasjon om de nye stasjonene, kan du se SQL Server - nye stasjoner Bruk 4 K sektorstørrelsen , og SQL Server – lagring mellomrom/VHDx og 4 K sektorstørrelsen.

Løsning

Problemet ble først løst i den følgende kumulative oppdateringen av SQL Server.

Løsning

Du kan omgå dette problemet ved å flytte transaksjonsloggfilen til målet på en stasjon som er angitt som 512 byte byte per fysiske sektoren .

Status

Microsoft har bekreftet at dette er et problem i Microsoft-produktene som er oppført i delen "Gjelder for".

Hvis du vil ha mer informasjon

Som beste praksis, kan du prøve å sikre at alle disker på alle replikaer (minst alle disker som er vert for loggfiler) har samme sektorstørrelse. TF 1800 i blandede miljøer, der sekundært har en fysiske sektoren på 512 byte, og primært har en sektorstørrelse på 4 KB, skal brukes som et flagg for oppstart på alle replikaer som har fysisk sektorstørrelse på 512 byte eller servere. Dette sørger for at pågående oppretting loggformatet bruker en sektorstørrelse på 4 KB.

Hvis du vil ha mer informasjon om hvordan SQL Server fungerer med større sektorstørrelser, kan du se følgende innlegget i bloggen støtte:

SQL Server – lagring mellomrom/VHDx og 4 K sektorstørrelse

Du kan bruke ledeteksten Fsutil-verktøyet til å bestemme verdien for byte per fysiske sektoren . Hvis denne parameteren ikke vises i utdataene, må du installere hurtigreparasjonen som er angitt i KB-artikkel 982018.

Hvis du vil kontrollere hvilken type stasjon du har, gjør du følgende:

1. Kjør følgende kommando fra en hevet ledetekst:

   Fsutil fsinfo ntfsinfo x: Obs! X-plassholderen representerer stasjonen som du sjekker.

2. Bruke verdier for Byte Per sektor og byte per fysiske sektoren til å bestemme hvilken type stasjon du har. Hvis du vil gjøre dette, bruker du tabellen nedenfor:

   Verdien "Byte Per sektor"	Verdien "Byte per fysiske sektoren"	Stasjonstype
   4096	4096	4 kB ukomprimert
   512	4096	Avansert Format (også kjent som 512E)
   512	512	Opprinnelig 512-byte

Forfatter: harvch
Tekstforfatter: v-shysun
Teknisk redaktør: johnbu; purvish; harvch;
Redaktør: v-emy, v-rhowar