Les erreurs de système d’exploitation 665 et 1450 sont signalées pour les fichiers SQL Server

  • Article

Cet article vous aide à résoudre le problème où les erreurs de système d’exploitation 1450 et 665 sont signalées pour les fichiers de base de données lors de l’exécution DBCC CHECKDB, de la création d’un instantané de base de données ou de la croissance des fichiers.

Version du produit d’origine : SQL Server
Numéro de la base de connaissances d’origine : 2002606

Symptômes

Supposons que vous effectuez l’une des actions suivantes sur un ordinateur qui exécute SQL Server :

  • Vous créez une base de données instantané sur une base de données volumineuse. Ensuite, vous effectuez de nombreuses opérations de modification ou de maintenance des données dans la base de données source.
  • Vous créez une base de données instantané sur une base de données miroir.
  • Vous exécutez la DBCC CHECKDB famille de commandes pour case activée la cohérence d’une base de données volumineuse, et vous effectuez également un grand nombre de modifications de données dans cette base de données.

Remarque

SQL Server utilise des fichiers partiellement alloués pour ces opérations : instantané de base de données et DBCC CHECKDB.

  • Sauvegarde ou restauration de bases de données.
  • Vous effectuez une copie en bloc via BCP vers plusieurs fichiers à l’aide d’exécutions BCP parallèles et de l’écriture dans le même volume.

À la suite de ces opérations, vous pouvez remarquer qu’une ou plusieurs de ces erreurs sont signalées dans le journal des erreurs SQL Server en fonction de l’environnement sur lequel SQL Server s’exécute.

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.`

En plus de ces erreurs, vous pouvez également remarquer les erreurs de délai d’expiration de latch suivantes :

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.

En outre, vous pouvez également remarquer un blocage lorsque vous affichez différentes vues de gestion dynamique (DMV), telles que sys.dm_exec_requests et sys.dm_os_waiting_tasks.

Dans de rares cas, vous pouvez observer un problème de planificateur sans rendement signalé dans le journal des erreurs SQL Server et que SQL Server génère une image mémoire.

Cause

Ce problème se produit si un grand nombre d’instances ATTRIBUTE_LIST_ENTRY sont nécessaires pour gérer un fichier fortement fragmenté en NTFS. Si l’espace est à côté d’un cluster déjà suivi par le système de fichiers, les attributs sont compressés en une seule entrée. Toutefois, si l’espace est fragmenté, il doit être suivi avec plusieurs attributs. Ainsi, une fragmentation importante des fichiers peut entraîner l’épuisement des attributs et l’erreur 665 qui en résulte. Ce comportement est expliqué dans l’article suivant de la Base de connaissances : Un fichier fortement fragmenté dans un volume NTFS peut ne pas dépasser une certaine taille.

Les fichiers réguliers et épars créés par SQL Server ou d’autres applications peuvent être fragmentés à ces niveaux lorsque de grandes quantités de modifications de données se produisent pendant la durée de vie de ces fichiers instantané.

Si vous effectuez des sauvegardes de base de données sur un ensemble à bandes de fichiers tous situés sur le même volume, ou si vous copiez en bloc (BCP-ing) des données vers plusieurs fichiers sur le même volume, les écritures peuvent se retrouver dans des emplacements adjacents, mais appartenant à des fichiers différents. Par exemple, un flux écrit pour décaler entre 201 et 400, l’autre flux écrit de 401 à 600, le troisième flux peut écrire de 601 à 800. Ce processus se poursuit également pour d’autres flux. Cela entraîne une fragmentation des fichiers sur le même support physique. Chacun des fichiers de sauvegarde ou flux de sortie BCP peut épuiser le stockage d’attributs, car aucun d’entre eux n’obtient de stockage adjacent.

Pour obtenir un arrière-plan complet de la façon dont SQL Server Engine utilise des fichiers éparses NTFS et d’autres flux de données, consultez Plus d’informations.

Résolution

Envisagez d’utiliser une ou plusieurs des options suivantes pour résoudre ce problème :

  1. Placez les fichiers de base de données sur un volume ReFS (Resilient File System), qui n’a pas les mêmes ATTRIBUTE_LIST_ENTRY limites que NTFS . Si vous souhaitez utiliser le volume NTFS actuel, vous devez reformater à l’aide de ReFS après avoir déplacé temporairement vos fichiers de base de données ailleurs. L’utilisation de ReFS est la meilleure solution à long terme pour résoudre ce problème.

    Remarque

    SQL Server 2012 et versions antérieures utilisaient des flux de fichiers nommés au lieu de fichiers partiellement alloués pour créer CHECKDB des instantanés. ReFS ne prend pas en charge les flux de fichiers. L’exécution DBCC CHECKDB de fichiers SQL Server 2012 dans ReFS peut entraîner des erreurs. Pour plus d’informations, consultez la note dans Comment DBCC CHECKDB crée une base de données instantané interne à partir de SQL Server 2014.

  2. Dé fragmenter le volume dans lequel résident les fichiers de base de données. Assurez-vous que votre utilitaire de défragmentation est transactionnel. Pour plus d’informations sur la défragmentation des lecteurs où résident SQL Server fichiers, consultez Précautions lors de la défragmentation SQL Server lecteurs de base de données et Recommandations. Vous devez arrêter SQL Server pour effectuer cette opération sur les fichiers. Nous vous recommandons de créer des sauvegardes de base de données complètes avant de défragmenter les fichiers comme mesure de sécurité. La défragmentation fonctionne différemment sur les disques SSD et ne traite généralement pas le problème. Copier le ou les fichiers et autoriser le microprogramme SSD à remballer le stockage physique est souvent une meilleure solution. Pour plus d’informations, consultez Erreur du système d’exploitation (665 - Limitation du système de fichiers) Pas seulement pour DBCC Anymore.

  3. Copie de fichier : l’exécution d’une copie du fichier peut permettre une meilleure acquisition d’espace, car les octets peuvent être étroitement regroupés dans le processus. La copie du fichier (ou son déplacement vers un autre volume) peut réduire l’utilisation des attributs et empêcher l’erreur de système d’exploitation 665. Copiez un ou plusieurs fichiers de base de données sur un autre lecteur. Ensuite, vous pouvez laisser le fichier sur le nouveau volume ou le copier dans le volume d’origine.

  4. Mettez en forme le volume NTFS à l’aide de l’option /L pour obtenir un frs volumineux. Ce choix peut soulager ce problème, car il augmente la ATTRIBUTE_LIST_ENTRY taille. Ce choix peut ne pas être utile lors de l’utilisationDBCC CHECKDB, car ce dernier crée un fichier partiellement alloué pour la base de données instantané.

    Remarque

    Pour les systèmes exécutant Windows Server 2008 R2 et Vista, vous devez d’abord appliquer le correctif logiciel de l’article de la Base de connaissances 967351 avant d’utiliser l’option /L avec la format commande .

  5. Divisez une base de données volumineuse en fichiers plus petits. Par exemple, si vous avez un fichier de données de 8 To, vous pouvez le diviser en huit fichiers de données de 1 To. Cette option peut être utile, car moins de modifications se produisent sur les fichiers plus petits, donc moins susceptibles d’introduire un épuisement des attributs. En outre, dans le processus de déplacement des données, les fichiers seront organisés de manière compacte et la fragmentation serait réduite. Voici les étapes générales qui décrivent le processus :

    1. Ajoutez les sept nouveaux fichiers de 1 To au même groupe de fichiers.
    2. Régénérez les index cluster des tables existantes, ce qui répartit automatiquement les données de chaque table entre les huit fichiers. Si une table n’a pas d’index cluster, créez-en un et supprimez-le pour effectuer la même opération.
    3. Réduisez le fichier d’origine de 8 To, qui est maintenant plein d’environ 12 %.

  6. Paramètre de croissance automatique de base de données : ajustez le paramètre de base de données d’incrémentation de croissance automatique pour acquérir des tailles propices aux performances de production et à l’empaquetage des attributs NTFS. Moins les occurrences de croissance automatique sont fréquentes et plus la taille de l’incrément de croissance est élevée, moins la probabilité de fragmentation des fichiers est faible.

  7. Réduisez la durée de vie des DBCC CHECK commandes à l’aide des améliorations des performances et évitez ainsi les erreurs 665 : les améliorations apportées à la commande DBCC CHECKDB peuvent entraîner des performances plus rapides lorsque vous utilisez l’option PHYSICAL_ONLY. Gardez à l’esprit que l’exécution DBCC CHECKDB avec PHYSICAL_ONLY commutateur n’offre pas de garantie que vous éviterez cette erreur, mais qu’elle réduit la probabilité dans de nombreux cas.

  8. Si vous effectuez des sauvegardes de base de données sur de nombreux fichiers (par bandes), planifiez soigneusement le nombre de fichiers, MAXTRANSFERSIZE et BLOCKSIZE (voir SAUVEGARDE). L’objectif est de réduire les fragments sur le système de fichiers, ce qui est généralement accompli en écrivant les blocs d’octets plus volumineux ensemble dans un fichier. Vous pouvez envisager de répartir les fichiers sur plusieurs volumes pour accélérer les performances et réduire la fragmentation.

  9. Si vous utilisez BCP pour écrire plusieurs fichiers simultanément, ajustez les tailles d’écriture de l’utilitaire, par exemple, augmentez la taille du lot BCP. Envisagez également d’écrire plusieurs flux sur différents volumes pour éviter la fragmentation ou réduire le nombre d’écritures parallèles.

  10. Pour exécuter DBCC CHECKDB, vous pouvez envisager de configurer un groupe de disponibilité ou un serveur de copie des journaux de transaction/de secours. Vous pouvez également utiliser un deuxième serveur sur lequel vous pouvez exécuter les DBCC CHECKDB commandes pour décharger le travail et éviter de rencontrer les problèmes causés par la fragmentation intensive des fichiers épars.

  11. Lorsque vous exécutez DBCC CHECKDB, si vous exécutez la commande à un moment où il y a peu d’activité sur le serveur de base de données, les fichiers partiellement alloués sont légèrement renseignés. Moins les écritures dans les fichiers réduisent la probabilité d’épuisement des attributs sur le NTFS. Une activité moindre est une autre raison de s’exécuter DBCC CHECKDB sur un deuxième serveur en lecture seule, si possible.

  12. Si vous exécutez SQL Server 2014, effectuez une mise à niveau vers le dernier Service Pack. Pour plus d’informations, consultez CORRECTIF : Erreur de système d’exploitation 665 lorsque vous exécutez la commande DBCC CHECKDB pour la base de données qui contient l’index columnstore dans SQL Server 2014.

Plus d’informations