Obs!
Når du har installert denne hurtigreparasjonen, må du aktivere sporingsflagg 1800 som en oppstartsparameter på alle servere eller replikaer som har en fysisk sektorstørrelse på 512 byte, og starte dem på nytt for at hurtigreparasjonen skal fungere som den skal.
Symptomer
Tenk deg følgende:
Du aktiverer AlwaysOn-tilgjengelighetsgrupper eller Logshipping-funksjonen i Microsoft SQL Server.
Diskene som lagrer loggfilene for den primære og sekundære replikaen i en AlwaysOn Availability Group (AG), har ulike sektorstørrelser. Eller i Logshipping-miljøer har diskene som lagrer loggfilene for Logshipping-primærservere og Logshipping-sekundære servere forskjellige sektorstørrelser. Eksempel:
- Den primære replikaloggfilen er plassert på en disk som har en sektorstørrelse på 512 byte. Loggfilen for den sekundære replikaen er imidlertid plassert på en disk som har en sektorstørrelse på 4 kilobyte (kB).
- Loggfilen for den primære replikaen er plassert på et lokalt lokalt system som har en sektorstørrelse på 512 byte. Den sekundære replikaen er imidlertid plassert på en Windows Azure Storage-disk som har en sektorstørrelse på 4 kilobyte (kB).
I dette scenariet loggføres følgende feilmelding i SQL Server-feilloggen. Feilmeldingen kan fortsette en stund etter omstart hvis det har vært logger som ikke ble brukt på sekundær før du starter serveren på nytt.
Obs!
Det har vært X feiljusterte logg-I/U som krevde å gå tilbake til synkron I/O. Gjeldende I/U er arkivert ....
I tillegg kjører AG- eller Logshipping-synkroniseringen svært sakte på grunn av de synkrone I/O-ene. Hvis den sekundære replikaen er i Windows Azure Storage, tar det mye lengre tid enn forventet å fullføre synkroniseringen.
Dette problemet oppstår når du bruker både de nye stasjonene som har en sektorstørrelse på 4 kB og de gamle stasjonene som har en sektorstørrelse på 512 byte. Hvis du vil ha mer informasjon om de nye stasjonene, kan du se SQL Server – nye stasjoner Bruk 4K-sektorstørrelse og SQL Server–lagringsplasser/VHDx og 4K-sektorstørrelse.
Oppløsning
Problemet ble først løst i den følgende kumulative oppdateringen av SQL Server.
Kumulativ oppdatering 5 for SQL Server 2014 /en-us/help/3011055
Kumulativ oppdatering 3 for SQL Server 2012 SP2 /en-us/help/3002049
Kumulativ oppdatering 13 for SQL Server 2012 SP1 /en-us/help/3002044
Når du har aktivert hurtigreparasjonen og aktivert sporingsflagg 1800 som en oppstartsparameter på alle serverreplikaer som kjører på en disk med en sektorstørrelse på 512 byte, merker du en liten økning i størrelsen på følgende filer:
- Transaksjonsloggfil
- Sikkerhetskopiering av logg
I tillegg legger du merke til at følgende meldinger er logget i SQL Server-feilloggen for primærserveren:
Obs!
Halen i loggen for databasenavn>< skrives om for å samsvare med den nye sektorstørrelsen på 4096 byte
Dette er en informativ melding som trygt kan ignoreres.
Om kumulative oppdateringer for SQL Server
Hver nye kumulative oppdatering for SQL Server inneholder alle hurtigreparasjoner og alle sikkerhetsrettinger som fulgte med den forrige kumulative oppdateringen. Se de nyeste kumulative oppdateringene for SQL Server:
- Den nyeste kumulative oppdateringen for SQL Server 2014
- Den nyeste kumulative oppdateringen for SQL Server 2012 SP2
- Den nyeste kumulative oppdateringen for SQL Server 2012 SP1
Midlertidig løsning
Du kan omgå dette problemet ved å flytte transaksjonsloggfilen på målet til en stasjon som har byte per fysisk sektor angitt til 512 byte.
Status
Microsoft har bekreftet at dette er et problem i Microsoft-produktene som er oppført i delen «Gjelder for».
Mer informasjon
Den beste fremgangsmåten er å sørge for at alle disker på alle replikaer (minst alle disker som er vert for loggfiler) har samme sektorstørrelse. I blandede miljøer, der sekundærsektoren har en fysisk sektor på 512 byte og primærsektoren har en sektorstørrelse på 4 kB, bør TF 1800 brukes som oppstartsflagg på alle servere eller replikaer som har en fysisk sektorstørrelse på 512 byte og startes på nytt. Dette sikrer at formatet for kontinuerlig loggoppretting 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 innlegg på støttebloggen:
SQL Server – Lagringsplasser/VHDx og 4K-sektorstørrelse
Du kan bruke ledetekstverktøyet Fsutil til å bestemme verdien for byte per fysisk sektor . Hvis denne parameteren ikke vises i utdataene, må du bruke hurtigreparasjonen som er angitt i KB-artikkelen 982018 .
Kontroller hvilken type stasjon du har, ved å følge disse trinnene:
Kjør følgende kommando fra en hevet ledetekst:
Fsutil fsinfo ntfsinfo x: Obs! X-plassholderen representerer stasjonen du kontrollerer.Bruk verdiene for byte per sektor og byte per fysisk sektor for å finne ut hvilken type stasjon du har. Det gjør du ved å bruke følgende tabell:
Verdien «Byte per sektor» Verdien «Byte per fysisk sektor» Stasjonstype 4096 4096 Opprinnelig 4K 512 4096 Avansert format (også kjent som 512E) 512 512 512-byte opprinnelig