Dopo aver applicato questo hotfix, è necessario abilitare il flag di traccia 1800 come parametro di avvio in tutti i server o le repliche che hanno dimensioni fisiche del settore di 512 byte e riavviarli, per fare in modo che questo hotfix funzioni correttamente.
Sintomi
Considerare lo scenario descritto di seguito:
-
Abilitare la funzionalità Gruppi di disponibilità AlwaysOn o Logshipping in Microsoft SQL Server.
-
I dischi in cui sono archiviati i file di log della replica primaria e secondaria in un gruppo di disponibilità AlwaysOn (AG) hanno dimensioni del settore diverse. Oppure, negli ambienti logshipping, i dischi in cui sono archiviati i file di log per i server primari di logshipping e i server secondari di Logshipping hanno dimensioni del settore diverse. Ad esempio:
-
Il file di log della replica principale si trova in un disco con dimensioni del settore di 512 byte. Tuttavia, il file di log della replica secondaria si trova in un disco con dimensioni del settore di 4 kilobyte (KB).
-
Il file di log della replica principale si trova in un sistema locale con una dimensione del settore di 512 byte. Tuttavia, la replica secondaria si trova in un disco di archiviazione di Windows Azure con dimensioni del settore di 4 kilobyte (KB).
-
In questo scenario viene registrato il seguente messaggio di errore nel registro degli errori di SQL Server. Il messaggio di errore potrebbe continuare per un po' di tempo dopo il riavvio se sono presenti log che non sono stati applicati a secondary prima di riavviare il server.
Ci sono stati X iOS log disallineati che hanno richiesto il ritorno a I/O sincrono. L'I/O corrente è nel file....
Inoltre, la sincronizzazione di AG o Logshipping viene eseguita molto lentamente a causa del sistema operativo sincrono. Se la replica secondaria si trova in Archiviazione di Windows Azure, il completamento del processo di sincronizzazione richiede più tempo del previsto.
Nota Questo problema si verifica quando si utilizzano sia le nuove unità con dimensioni del settore da 4 KB che le unità precedenti con una dimensione del settore di 512 byte. Per ulteriori informazioni sulle nuove unità, vedi SQL Server - Nuove unità Utilizza le dimensioni del settore 4K e SQL Server– Spazi di archiviazione/VHDx e dimensioni del settore 4K.
Risoluzione
Il problema è stato risolto per la prima volta nel seguente aggiornamento cumulativo di SQL Server.
Aggiornamento cumulativo 5 per SQL Server 2014 /en-us/help/3011055
Aggiornamento cumulativo 3 per SQL Server 2012 SP2 /en-us/help/3002049
Aggiornamento cumulativo 13 per SQL Server 2012 SP1 /en-us/help/3002044
Dopo aver applicato l'hotfix e aver abilitato il flag di traccia 1800 come parametro di avvio in tutti i server in esecuzione su un disco con dimensioni del settore di 512 byte, si noterà un piccolo aumento delle dimensioni dei file seguenti:
-
File di log delle transazioni
-
Backup del log
Inoltre, si noterà che i seguenti messaggi vengono registrati nel registro degli errori di SQL Server del server primario:
La coda del registro per il database '<nome database>' viene riscritta in modo da corrispondere alla nuova dimensione del settore di 4096 byte
Si tratta di un messaggio informativo che può essere tranquillamente ignorato.
Ogni nuovo aggiornamento cumulativo per SQL Server contiene tutti gli aggiornamenti rapidi e tutte le correzioni per la sicurezza inclusi nell'aggiornamento cumulativo precedente. Vedi gli aggiornamenti cumulativi più recenti per SQL Server:
Soluzione alternativa
Per ovviare a questo problema, spostare il file di log delle transazioni nella destinazione in un'unità con Byte per settore fisico impostato su 512 byte.
Stato
Microsoft ha confermato che questo problema si verifica nei prodotti elencati nella sezione "Si applica a".
Ulteriori informazioni
Come procedura consigliata, provare a verificare che tutti i dischi in tutte le repliche (almeno tutti i dischi che ospitano i file di log) abbiano le stesse dimensioni del settore. In ambienti misti, in cui il secondario ha un settore fisico di 512 byte e il primario ha una dimensione del settore di 4 KB, TF 1800 deve essere utilizzato come flag di avvio su tutti i server o le repliche con dimensione fisica del settore a 512 byte e riavviato. In questo modo si garantisce che il formato di creazione del log in corso usi dimensioni del settore da 4 KB.
Per ulteriori informazioni su come SQL Server funziona con settori di dimensioni maggiori, vedi il seguente post sul blog di supporto:
SQL Server–Spazi di archiviazione/VHDx e dimensioni
del settore 4K
È possibile utilizzare l'utilità del prompt dei comandi Fsutil per determinare il valore byte per settore fisico. Se questo parametro non è visibile nell'output, è necessario applicare l'hotfix specificato nell'articolo della Knowledge Base 982018.
Per verificare il tipo di unità in uso, procedere come segue:
-
Eseguire il comando seguente a un prompt dei comandi con privilegi elevati:
Fsutil fsinfo ntfsinfo x: Nota Il segnaposto x rappresenta l'unità che si sta controllando.
-
Usa i valori per Byte per settore e Byte per settore fisico per determinare il tipo di unità che hai. A questo scopo, usare la tabella seguente:
Valore "Byte per settore"
Valore "Byte per settore fisico"
Tipo di unità
4096
4096
Nativo 4K
512
4096
Formato avanzato (noto anche come 512E)
512
512
Nativo di 512 byte
