Avoir une instance SQL Server 2014 exécutée sur Windows 2012 R2 qui exécute chaque semaine les scripts d'intégrité de base de données d'Ola Hallengren et les deux dernières semaines ont commencé à obtenir cette erreur:
DESCRIPTION: 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 0x000036ec240000 in file 'E:\DBFiles\XXXXX.mdf_MSSQL_DBCC42'. Additional
messages in the SQL Server error log and system event log may provide more detail. This
is a severe system-level error condition that threatens database integrity and must be
corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This
error can be caused by many factors; for more information, see SQL Server Books Online.
J'ai vérifié à la fois le journal des événements et le journal des erreurs SQL Server, mais je n'ai pas obtenu beaucoup d'informations supplémentaires qui pourraient aider. Je relance la vérification de DBCC
pour ce db comme je l'ai fait la semaine dernière et il a effacé le fichier MSSQL_DBCC42 et n'a trouvé aucune corruption.
À d'autres endroits où je pourrais trouver plus d'informations autres que le journal des événements et le journal des erreurs SQL Server? Dois-je demander à notre groupe de stockage de voir si quelque chose apparaît sur les rapports pour le SAN ou est-ce purement lié à SQL en raison de certains conflits?
Cette base de données est assez active car elle reproduit les transactions de notre environnement financier et de fabrication JDE sur un iSeries, et est actuellement d'environ 300 Go. Chaque nuit, la base de données est sauvegardée et restaurée sur un serveur de développement. Serait-il préférable pour moi d'exécuter la vérification DBCC
par rapport à cette copie de la base de données? Cette base de données est une source pour la construction de cubes multidimensionnels SSAS pour les rapports de la veille, j'aurais donc la possibilité de reconstruire complètement les données ou d'essayer de récupérer à partir d'une sauvegarde si elle était corrompue, etc.
Appréciez toutes les réflexions sur ce qui pourrait provoquer cette erreur ou la meilleure option pour exécuter DBCC checkdb
en fonction de la situation.
DBCC utilise des instantanés en interne. Les instantanés sont ensuite implémentés sous forme de fichiers épars dans Windows.
Il s'agit donc en fait d'un problème avec la gestion par Windows des fichiers épars, ce qui provoque la rupture occasionnelle des instantanés utilisés par DBCC sur des bases de données volumineuses et très actives. Il est raisonnablement bien documenté avec quelques correctifs recommandés dans http://support.Microsoft.com/kb/2002606
Cependant, si vous pouvez DBCC sur le serveur de développement, je recommanderais cela à la place. (Personnellement, je n'ai vu ce problème qu'avec des bases de données qui servaient encore du trafic tout en étant DBCC/instantanées. Sauvegarde/restauration sur un serveur inactif, DBCC là => plus 665 erreurs.)