Condividi tramite

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

  • Articolo

Questo articolo illustra come risolvere il problema in cui vengono segnalati gli errori del sistema operativo 1450 e 665 per i file di database durante l'esecuzione DBCC CHECKDBdi , la creazione di uno snapshot del database o l'aumento delle dimensioni 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 nel database.

Note

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

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

In seguito a 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, è anche possibile notare gli errori di timeout di latch seguenti:

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.

Inoltre, è anche possibile notare il blocco quando si visualizzano varie viste a gestione dinamica (DMV), ad esempio sys.dm_exec_requests e sys.dm_os_waiting_tasks.

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

Causa

Questo problema si verifica se è necessario un numero elevato di ATTRIBUTE_LIST_ENTRY istanze per mantenere un file molto frammentato in NTFS. Se lo spazio è 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, una forte frammentazione dei file 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 normali che i file sparse creati da SQL Server o altre applicazioni possono essere frammentati a questi livelli quando si verificano grandi quantità di modifiche ai dati per la durata di questi file snapshot.

Se si eseguono backup di database in un set di file con striping in tutti i file che si trovano nello stesso volume o se si esegue la copia bulk dei dati (BCP-ing) in più file nello stesso volume, le operazioni di scrittura possono terminare in posizioni adiacenti ma appartenenti a file diversi. Ad esempio, un flusso scrive in offset tra 201 e 400, l'altro flusso 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 nello 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 sul modo in cui il motore di SQL Server usa file di tipo sparse NTFS e flussi di dati alternativi, vedere Altre informazioni.

Risoluzione

Per risolvere questo problema, prendere in considerazione l'uso di una o più delle opzioni seguenti:

  1. Posizionare 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 desidera utilizzare il volume NTFS corrente, è necessario riformattare l'uso di ReFS dopo lo spostamento temporaneamente dei file di database. L'uso di ReFS è la soluzione migliore a lungo termine per risolvere questo problema.

    Note

    SQL Server 2012 e versioni precedenti usano flussi di file denominati anziché file di tipo sparse per creare CHECKDB snapshot. ReFS non supporta i flussi di file. L'esecuzione DBCC CHECKDB nei file di SQL Server 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. De-frammento del volume in cui risiedono i file di database. Assicurarsi che l'utilità di deframmentazione sia transazionale. Per altre informazioni sulla deframmentazione delle unità in cui risiedono i file di SQL Server, vedere Precauzioni quando si deframmenta le unità di database di SQL Server e le raccomandazioni. Per eseguire questa operazione sui file, è necessario arrestare SQL Server. È 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 ricomprimere 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 di file: l'esecuzione di una copia del file può consentire una migliore acquisizione dello spazio perché i byte potrebbero essere compressi strettamente nel processo. La copia del file (o lo spostamento in un volume diverso) può ridurre l'utilizzo degli attributi e può 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 più ATTRIBUTE_LIST_ENTRY grande. Questa scelta potrebbe non essere utile quando si usa DBCC CHECKDB perché quest'ultimo crea un file sparse per lo snapshot del database.

    Note

    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 può essere utile perché un minor numero di modifiche si verificherebbe su file più piccoli, quindi meno probabile che introduca l'esaurimento degli attributi. Inoltre, nel processo di spostamento dei dati, i file verranno organizzati in modo compatto e la frammentazione verrebbe 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 una e rilasciarla per ottenere lo stesso risultato.
    3. Compattare il file originale da 8 TB, che ora è pieno circa il 12%.

  6. Impostazione aumento automatico del database: regolare l'impostazione del database per l'incremento automatico della crescita per acquisire dimensioni che favoriscono le prestazioni di produzione e la compressione degli attributi NTFS. Minore frequenza delle occorrenze di crescita automatica e maggiore è la dimensione dell'incremento di 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 eviti questo errore, ma ridurrà la probabilità in molti casi.

  8. Se si eseguono backup del database in molti file (set di striping), pianificare attentamente il numero di file MAXTRANSFERSIZE e BLOCKSIZE (vedere BACKUP). L'obiettivo è ridurre i frammenti nel file system che in genere viene eseguito scrivendo i blocchi di byte più grandi in un file. È possibile prendere in considerazione lo striping dei file in 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 di log shipping/standby. In alternativa, usare un secondo server in cui è possibile eseguire i DBCC CHECKDB comandi per eseguire l'offload del lavoro ed evitare l'esecuzione dei problemi causati dalla pesante frammentazione dei file sparse.

  11. Quando si esegue DBCC CHECKDB, se si esegue il comando alla volta in cui è presente poca attività nel server di database, i file di tipo sparse verranno popolati in modo leggero. Il minor numero di scritture nei file ridurrà la probabilità di esaurimento degli attributi in NTFS. Minore attività è un altro motivo per l'esecuzione 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.

Ulteriori informazioni