Nota
Dopo aver applicato questo aggiornamento rapido (hotfix), è necessario abilitare il flag di traccia 1800 come parametro di avvio in tutti i server o le repliche con dimensioni del settore fisico di 512 byte e riavviarli per il corretto funzionamento dell'aggiornamento rapido (hotfix).
Sintomi
Si consideri lo scenario seguente:
Si abilitano i gruppi di disponibilità AlwaysOn o la funzionalità di logshipping in Microsoft SQL Server.
I dischi che archiviano i file di log della replica primaria e secondaria in un gruppo di disponibilità AlwaysOn hanno dimensioni di settore diverse. Oppure, negli ambienti di logshipping, i dischi in cui sono memorizzati i file di log per i server primari di logshipping e i server secondari di logshipping hanno dimensioni di settore diverse. Ad esempio:
- Il file di log della replica primaria si trova su un disco con una dimensione 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 primaria si trova in un sistema locale 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, il messaggio di errore seguente viene registrato nel log degli errori di SQL Server. Il messaggio di errore può continuare per un po' di tempo dopo il riavvio se sono stati presenti log che non sono stati applicati al database secondario prima del riavvio del server.
Nota
Ci sono stati X I/O logaritmici disallineati che hanno richiesto il ripiego all'I/O sincrono. L'OI corrente è in archivio ....
Inoltre, la sincronizzazione del gruppo di disponibilità o del logshipping viene eseguita molto lentamente a causa degli I/O sincroni. Se la replica secondaria si trova in Archiviazione di Windows Azure, il completamento del processo di sincronizzazione richiede molto più tempo del previsto.
Nota: questo problema si verifica quando si usano sia le nuove unità con una dimensione del settore di 4 KB sia le vecchie unità con una dimensione del settore di 512 byte. Per altre informazioni sulle nuove unità, vedere SQL Server - Nuove unità Usare dimensioni del settore 4K e SQL Server–Spazi di archiviazione/Dimensioni del settore VHDx e 4K.
Risoluzione
Il problema è stato risolto per la prima volta nell'aggiornamento cumulativo seguente di SQL Server.
Aggiornamento cumulativo 5 per SQL Server 2014 /it-IT/help/3011055
Aggiornamento cumulativo 3 per SQL Server 2012 SP2 /it-it/help/3002049
Aggiornamento cumulativo 13 per SQL Server 2012 SP1 /it-IT/help/3002044
Dopo aver applicato l'hotfix e abilitato il flag di traccia 1800 come parametro di avvio in tutte le repliche di server in esecuzione su un disco con una dimensione del settore di 512 byte, si nota un piccolo aumento delle dimensioni dei file seguenti:
- File di registro delle transazioni
- Backup dei log
Inoltre, i messaggi seguenti vengono registrati nel log degli errori di SQL Server del server primario:
Nota
La coda del log per il database 'database name><' è stata riscritta per adattarsi alla nuova dimensione del settore di 4096 byte
Si tratta di un messaggio informativo che può essere ignorato in modo sicuro.
Informazioni sugli aggiornamenti cumulativi per SQL Server
Ogni nuovo aggiornamento cumulativo per SQL Server contiene tutte le correzioni rapide e di sicurezza incluse nell'aggiornamento cumulativo precedente. Vedere gli aggiornamenti cumulativi più recenti per SQL Server:
- Aggiornamento cumulativo più recente per SQL Server 2014
- Aggiornamento cumulativo più recente per SQL Server 2012 SP2
- Aggiornamento cumulativo più recente per SQL Server 2012 SP1
Soluzione alternativa
Per risolvere 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 si tratta di un problema relativo ai prodotti elencati nella sezione "Si applica a".
Altre informazioni
Come procedura consigliata, provare ad assicurarsi 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 un settore fisico di 512 byte e riavviato. In questo modo si garantisce che il formato di creazione del log in corso usi una dimensione del settore di 4 KB.
Per altre informazioni sul funzionamento di SQL Server con settori di dimensioni maggiori, vedere il post seguente nel blog del supporto tecnico:
SQL Server - Spazi di archiviazione/Dimensioni del settore VHDx e 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, eseguire le operazioni seguenti:
Esegui questo comando in un prompt dei comandi con privilegi elevati:
Fsutil fsinfo ntfsinfo x: Nota Il segnaposto x rappresenta l'unità che si sta controllando.Usare i valori Byte per settore e Byte per settore fisico per determinare il tipo di unità disponibile. A tale scopo, utilizzare la tabella seguente:
Valore "Byte per settore" Valore "Byte per settore fisico" Tipo di unità 4096 4096 4K nativo 512 4096 Formato avanzato (noto anche come 512E) 512 512 512 byte nativi