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

VIKTIG: Denne artikkelen ble oversatt med maskinoversettelsesprogramvare fra Microsoft og muligens redigert av Microsoft Community via CTF-teknologi i stedet for av en oversetter. Microsoft tilbyr både menneskelig oversatte og maskinoversatte/Community-redigerte artikler, slik at du får tilgang til alle artiklene i vår Knowledge Base på ditt eget språk. En maskinoversatt eller Community-redigert artikkel er imidlertid ikke alltid perfekt. Den kan inneholde feil i vokabular, syntaks eller grammatikk, mye likt en fremmedspråklig som forsøker å snakke språket ditt. Microsoft har ikke ansvar for unøyaktige opplysninger, feil eller skade forårsaket av feilaktig oversettelse av innholdet eller kundenes bruk av informasjonen. Microsoft oppdaterer jevnlig maskinoversettelsesprogramvaren og -verktøyene for å forbedre redigering av maskinoversatte tekster.

Den engelske versjonen av denne artikkelen er den følgende: 3009974
Merknad
Obs! Når du har installert denne hurtigreparasjonen, må du aktivere sporingsflagg 1800 på alle servere å gjøre denne hurtigreparasjonen fungerer på riktig måte.
Symptom
Tenk deg følgende:
  • Du aktiverer funksjonen AlwaysOn tilgjengelighetsgrupper eller Logshipping i Microsoft SQL Server 2012 eller SQL Server-2014.
  • 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:

Det har vært X skjeve logge IOs hvilke nødvendig faller tilbake til synkrone IU. Gjeldende i/u er på fil...

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, se SQLServer - nye stasjoner Bruk 4K sektorstørrelse og SQL Server – lagring mellomrom/VHDx og 4 K sektorstørrelse.
Løsning
Problemet ble først løst i den følgende kumulative oppdateringen av SQL Server.

Kumulativ oppdatering 5 for SQLServer 2014

Samleoppdatering 3 for SQL Server 2012 SP2

Kumulativ oppdatering 13 for SQL Server 2012 SP1

Når du har installert hurtigreparasjonen, og aktiverer sporingsflagg 1800 på de primære serverne, merker du en liten økning i størrelsen på følgende filer:
  • Transaksjonsloggfilen
  • Gjenopprettingsmodellen
I tillegg kan du se at følgende meldinger logges i feilloggen for SQL-Server til den primære serveren:

Halen av logg for databasen 'databasenavn>' er som blir skrevet på nytt for å samsvare med den nye sektorstørrelsen på 4096 byte

Dette er en Informasjonsmelding som trygt kan ignoreres.

Om kumulative oppdateringer for SQL Server

Hver nye kumulative oppdateringen for SQL Server inneholder alle hurtigreparasjonene og alle sikkerhetsreparasjoner som fulgte med den forrige kumulative oppdateringen. Du kan se de nyeste kumulative oppdateringene for SQL Server:

Workaround
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".
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. Blandede miljøer, der sekundært har en fysiske sektoren på 512 byte, og primært har en sektorstørrelse på 4 KB, skal TF 1800 brukes som en oppstart flagg på alle servere (spesielt servere som har en fysisk sektor 512-byte) som kan overgangen til rollen som primær enhet. 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 Fsutil-verktøyet ledetekst 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
    409640964 kB ukomprimert
    5124096Avansert Format (også kjent som 512E)
    512512Opprinnelig 512-byte

Advarsel: Denne artikkelen er autooversatt

Egenskaper

Artikkel-ID: 3009974 – Forrige gjennomgang: 01/19/2016 20:01:00 – Revisjon: 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 KbMtno
Tilbakemelding