Condividi tramite

Gli errori del sistema operativo 665 e 1450 vengono segnalati per i file SQL Server

  • Articolo

Questo articolo consente di risolvere il problema in cui vengono segnalati errori del sistema operativo 1450 e 665 per i file di database durante l'esecuzione DBCC CHECKDB, la creazione di uno snapshot del database o l'aumento dei file.

Versione originale del prodotto: SQL Server
Numero KB originale: 2002606

Sintomi

Si supponga di eseguire una delle azioni seguenti in un computer che esegue SQL Server:

  • Si crea uno snapshot del database in un database di grandi dimensioni. Si eseguono quindi numerose operazioni di modifica o manutenzione dei dati nel database di origine.
  • Si crea uno snapshot del database in un database mirror.
  • È possibile eseguire la DBCC CHECKDB famiglia di comandi per verificare la coerenza di un database di grandi dimensioni ed eseguire anche un numero elevato di modifiche ai dati in tale database.

Nota

SQL Server usa file sparse per queste operazioni: snapshot del database e DBCC CHECKDB.

  • Backup o ripristino dei database.
  • È possibile eseguire la copia bulk tramite BCP in più file usando esecuzioni BCP parallele e scrivendo nello stesso volume.

Come risultato di queste operazioni, è possibile notare uno o più di questi errori segnalati nel log degli errori di SQL Server a seconda dell'ambiente in cui è in esecuzione SQL Server.

The operating system returned error 665(The requested operation could not be completed due to a file system limitation) to SQL Server during a write at offset 0x00002a3ef96000 in file 'Sam.mdf:MSSQL_DBCC18'

The operating system returned error 1450 (Insufficient system resources exist to complete the requested service.) to SQL Server during a write at offset 0x00002a3ef96000 in file with handle 0x0000000000000D5C. This is usually a temporary condition and the SQL Server will keep retrying the operation. If the condition persists, then immediate action must be taken to correct it.`

Oltre a questi errori, è possibile notare anche i seguenti errori di timeout di latch:

Timeout occurred while waiting for latch: class *'DBCC_MULTIOBJECT_SCANNER'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  

Timeout occurred while waiting for latch: class *'ACCESS_METHODS_HOBT_COUNT'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.

Si potrebbe anche notare un blocco quando si visualizzano diverse viste a gestione dinamica (DMV), ad sys.dm_exec_requests esempio e sys.dm_os_waiting_tasks.

In rari casi, è possibile osservare un problema dell'utilità di pianificazione non cedente segnalato nel log degli errori SQL Server e che SQL Server genera un dump di memoria.

Causa

Questo problema si verifica se è necessario un numero elevato di ATTRIBUTE_LIST_ENTRY istanze per gestire un file molto frammentato in NTFS. Se lo spazio si trova accanto a un cluster già rilevato dal file system, gli attributi vengono compressi in una singola voce. Tuttavia, se lo spazio è frammentato, deve essere rilevato con più attributi. Pertanto, la frammentazione dei file pesante può causare l'esaurimento degli attributi e l'errore 665 risultante. Questo comportamento è illustrato nell'articolo della Knowledge Base seguente: Un file molto frammentato in un volume NTFS potrebbe non aumentare oltre una determinata dimensione.

Sia i file regolari che i file sparse creati da SQL Server o da altre applicazioni possono essere frammentati a questi livelli quando si verificano grandi quantità di modifiche dei dati per la durata di questi file di snapshot.

Se si eseguono backup del database in un set di striping di file che si trovano tutti nello stesso volume o se si esegue la copia bulk (BCP-ing) di dati in più file nello stesso volume, le scritture potrebbero finire in posizioni adiacenti ma appartenenti a file diversi. Ad esempio, un flusso scrive per offset tra 201 e 400, l'altro scrive da 401 a 600, il terzo flusso può scrivere da 601 a 800. Questo processo continua anche per altri flussi. Ciò comporterà la frammentazione dei file sullo stesso supporto fisico. Ognuno dei file di backup o dei flussi di output BCP può esaurire l'archiviazione degli attributi perché nessuno di essi ottiene l'archiviazione adiacente.

Per informazioni complete su come SQL Server Engine usa file sparse NTFS e flussi di dati alternativi, vedere Altre informazioni.

Risoluzione

Provare a usare una o più delle opzioni seguenti per risolvere il problema:

  1. Inserire i file di database in un volume ReFS (Resilient File System), che non presenta gli stessi ATTRIBUTE_LIST_ENTRY limiti previsti da NTFS . Se si vuole usare il volume NTFS corrente, è necessario riformattare usando ReFS dopo aver spostato temporaneamente i file di database altrove. L'uso di ReFS è la migliore soluzione a lungo termine per risolvere questo problema.

    Nota

    SQL Server 2012 e versioni precedenti usavano flussi di file denominati anziché file sparse per creare CHECKDB snapshot. ReFS non supporta i flussi di file. L'esecuzione DBCC CHECKDB in SQL Server file 2012 in ReFS potrebbe causare errori. Per altre informazioni, vedere la nota in Come DBCC CHECKDB crea un database snapshot interno a partire da SQL Server 2014.

  2. Frammenta il volume in cui si trovano i file di database. Assicurarsi che l'utilità di deframmentazione sia transazionale. Per altre informazioni sulla deframmentazione delle unità in cui si trovano SQL Server file, vedere Precauzioni quando si deframmentano SQL Server unità di database e Consigli. È necessario arrestare SQL Server per eseguire questa operazione sui file. È consigliabile creare backup completi del database prima di deframmentare i file come misura di sicurezza. La deframmentazione funziona in modo diverso sui supporti SSD (Solid State Drive) e in genere non risolve il problema. Copiare i file e consentire al firmware SSD di riconfettare l'archiviazione fisica è spesso una soluzione migliore. Per altre informazioni, vedere Errore del sistema operativo (665 - Limitazione del file system) Non solo per DBCC.

  3. Copia del file: l'esecuzione di una copia del file può consentire un'acquisizione di spazio migliore perché i byte potrebbero essere strettamente compressi nel processo. La copia del file (o lo spostamento in un volume diverso) può ridurre l'utilizzo degli attributi e impedire l'errore del sistema operativo 665. Copiare uno o più file di database in un'altra unità. È quindi possibile lasciare il file nel nuovo volume o copiarlo di nuovo nel volume originale.

  4. Formattare il volume NTFS usando l'opzione /L per ottenere un file FRS di grandi dimensioni. Questa scelta può fornire sollievo a questo problema perché rende il ATTRIBUTE_LIST_ENTRY più grande. Questa scelta potrebbe non essere utile quando si usa DBCC CHECKDB perché quest'ultimo crea un file sparse per lo snapshot del database.

    Nota

    Per i sistemi che eseguono Windows Server 2008 R2 e Vista, è prima necessario applicare l'hotfix dell'articolo della Knowledge Base 967351 prima di usare l'opzione /L con il format comando .

  5. Suddividere un database di grandi dimensioni in file più piccoli. Ad esempio, se si dispone di un file di dati da 8 TB, è possibile suddividerlo in otto file di dati da 1 TB. Questa opzione potrebbe essere utile perché si verificherebbero meno modifiche nei file più piccoli, pertanto è meno probabile che introduca l'esaurimento degli attributi. Inoltre, durante il processo di spostamento dei dati, i file verranno organizzati in modo compatto e la frammentazione verrà ridotta. Di seguito sono riportati i passaggi generali che descrivono il processo:

    1. Aggiungere i sette nuovi file da 1 TB allo stesso gruppo di file.
    2. Ricompilare gli indici cluster delle tabelle esistenti, che distribuiranno automaticamente i dati di ogni tabella tra gli otto file. Se una tabella non ha un indice cluster, crearne uno ed eliminarlo per ottenere lo stesso risultato.
    3. Compattare il file originale da 8 TB, che ora è pieno di circa il 12%.

  6. Impostazione di aumento automatico del database: modificare l'impostazione del database con incremento della crescita automatica per acquisire dimensioni favorevoli alle prestazioni di produzione e alla compressione degli attributi NTFS. Meno frequenti sono le occorrenze di crescita automatica e maggiore è la dimensione dell'incremento della crescita, minore è la probabilità di frammentazione dei file.

  7. Ridurre la durata dei DBCC CHECK comandi usando i miglioramenti delle prestazioni ed evitare quindi gli errori 665: i miglioramenti per il comando DBCC CHECKDB possono comportare prestazioni più veloci quando si usa l'opzione PHYSICAL_ONLY. Tenere presente che l'esecuzione DBCC CHECKDB con PHYSICAL_ONLY switch non garantisce che si eviterà questo errore, ma in molti casi ne ridurrà la probabilità.

  8. Se si eseguono backup del database in molti file (stripe set), pianificare attentamente il numero di file MAXTRANSFERSIZE e BLOCKSIZE (vedere BACKUP). L'obiettivo è ridurre i frammenti nel file system che in genere vengono eseguiti scrivendo i blocchi di byte più grandi insieme in un file. È possibile prendere in considerazione lo striping dei file tra più volumi per ottenere prestazioni più veloci e ridurre la frammentazione.

  9. Se si usa BCP per scrivere più file contemporaneamente, modificare le dimensioni di scrittura dell'utilità, ad esempio aumentare le dimensioni del batch BCP. Valutare anche la possibilità di scrivere più flussi in volumi diversi per evitare la frammentazione o ridurre il numero di scritture parallele.

  10. Per eseguire DBCC CHECKDB, è possibile configurare un gruppo di disponibilità o un server log shipping/standby. In alternativa, usare un secondo server in cui è possibile eseguire i DBCC CHECKDB comandi per scaricare il lavoro ed evitare di riscontrare i problemi causati dalla frammentazione pesante dei file di tipo sparse.

  11. Quando si esegue DBCC CHECKDB, se si esegue il comando in un momento in cui è presente poca attività nel server di database, i file di tipo sparse verranno popolati leggermente. Meno scritture nei file ridurranno la probabilità di esaurimento degli attributi in NTFS. Meno attività è un altro motivo per eseguire DBCC CHECKDB in un secondo server di sola lettura, quando possibile.

  12. Se si esegue SQL Server 2014, eseguire l'aggiornamento al Service Pack più recente. Per altre informazioni, vedere FIX: OS error 665 when you execute DBCC CHECKDB command for database that contains columnstore index in SQL Server 2014.For more information, see FIX: OS error 665 when you execute DBCC CHECKDB command for database that contains columnstore index in SQL Server 2014.

Ulteriori informazioni