Partager via

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, la création d’un instantané de base de données ou la croissance des fichiers.

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

Symptômes

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

  • Vous créez un instantané de base de données 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 un instantané de base de données sur une base de données miroir.
  • Vous exécutez la DBCC CHECKDB famille de commandes pour vérifier 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.

Note

SQL Server utilise des fichiers épars 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.

En raison de ces opérations, vous remarquerez peut-être qu’une ou plusieurs de ces erreurs 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 verrou 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 le 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 un vidage de 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é dans NTFS. Si l’espace est en regard 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 de fichiers lourde peut entraîner l’épuisement des attributs et l’erreur 665 résultante. Ce comportement est expliqué dans l’article de la base de connaissances suivant : un fichier fortement fragmenté dans un volume NTFS peut ne pas dépasser une certaine taille.

Les fichiers réguliers et partiellement alloués 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 d’instantanés.

Si vous effectuez des sauvegardes de base de données sur un ensemble de fichiers répartis 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 en décalage entre 201 et 400, l’autre flux écrit de 401 à 600, le troisième flux peut écrire de 601 à 800. Ce processus continue également pour d’autres flux. Cela entraînera la 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 un stockage adjacent.

Pour obtenir un arrière-plan complet de la façon dont le moteur SQL Server 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 présente. 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.

    Note

    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 sur des fichiers SQL Server 2012 dans ReFS peut entraîner des erreurs. Pour plus d’informations, consultez la remarque dans comment DBCC CHECKDB crée une base de données d’instantané interne à partir de SQL Server 2014.

  2. Délimitez le volume où résident les fichiers de base de données. Vérifiez que votre utilitaire de défragmentation est transactionnel. Pour plus d’informations sur les lecteurs de défragmentation où résident les fichiers SQL Server, consultez Précautions lorsque vous défragmentez les lecteurs de base de données SQL Server et les recommandations. Vous devez arrêter SQL Server pour effectuer cette opération sur les fichiers. Nous vous recommandons de créer des sauvegardes complètes de base de données avant de défragmenter les fichiers en tant que mesure de sécurité. La défragmentation fonctionne différemment sur les lecteurs SSD (Solid-State Drive) et ne traite généralement pas le problème. La copie du ou des fichiers et l’autorisation du microprogramme SSD pour repackiser 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) plus seulement pour DBCC.

  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 vers le volume d’origine.

  4. Mettez en forme le volume NTFS à l’aide de l’option /L pour obtenir un grand FRS. Ce choix peut apporter un soulagement à ce problème, car il rend plus ATTRIBUTE_LIST_ENTRY grand. Ce choix peut ne pas être utile lors de l’utilisation DBCC CHECKDB , car ce dernier crée un fichier partiellement alloué pour l’instantané de base de données.

    Note

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

  5. Décomposez 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 vous aider, car moins de modifications se produisent sur des fichiers plus petits, donc moins susceptibles d’introduire l’é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, qui répartissent 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-la pour accomplir la même opération.
    3. Réduisez le fichier 8 To d’origine, qui est maintenant plein à environ 12 %.

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

  7. Réduisez la durée de vie des commandes à l’aide des améliorations des DBCC CHECK 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. N’oubliez pas que l’exécution DBCC CHECKDB avec PHYSICAL_ONLY commutateur ne fournit pas de garantie que vous éviterez cette erreur, mais cela réduit la probabilité dans de nombreux cas.

  8. Si vous effectuez des sauvegardes de base de données sur de nombreux fichiers (jeu de bandes), planifiez soigneusement le nombre de fichiers et MAXTRANSFERSIZE BLOCKSIZE (voir BACKUP). L’objectif est de réduire les fragments sur le système de fichiers 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 dans 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 où 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 importante des fichiers épars.

  11. Lorsque vous exécutez , si vous exécutez DBCC CHECKDBla commande à la fois lorsqu’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 d’écritures dans les fichiers réduisent la probabilité d’épuiser les attributs sur ntfs. Moins d’activité 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