Поделиться через

Ошибки ОС 665 и 1450 сообщаются для файлов SQL Server

  • Статья

Эта статья поможет устранить проблему, из-за которой ошибки ОС 1450 и 665 передаются для файлов базы данных при выполнении DBCC CHECKDB, создании моментального снимка базы данных или росте файлов.

Исходная версия продукта: SQL Server
Исходный номер базы знаний: 2002606

Симптомы

Предположим, что на компьютере под управлением SQL Server выполняется одно из следующих действий:

  • Создание моментального снимка базы данных в большой базе данных. Затем в исходной базе данных выполняются многочисленные операции изменения или обслуживания данных.
  • Создание моментального снимка базы данных в зеркальной базе данных.
  • Вы выполняете DBCC CHECKDB семейство команд, чтобы проверить согласованность большой базы данных, а также выполнить большое количество изменений данных в этой базе данных.

Примечание.

SQL Server использует разреженные файлы для этих операций: моментальный снимок базы данных и DBCC CHECKDB.

В результате этих операций вы можете заметить одну или несколько этих ошибок, сообщаемых в журнале ошибок SQL Server в зависимости от среды 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.`

Помимо этих ошибок, вы также можете заметить следующие ошибки времени ожидания блокировки:

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.

Кроме того, вы также можете заметить блокировку при просмотре различных динамических административных представлений (DMV), таких как sys.dm_exec_requests и sys.dm_os_waiting_tasks.

В редких случаях в журнале ошибок SQL Server может возникнуть проблема, связанная с неоформляющим планировщиком, и что SQL Server создает дамп памяти.

Причина

Эта проблема возникает, если требуется большое количество ATTRIBUTE_LIST_ENTRY экземпляров для поддержания сильно фрагментированного файла в NTFS. Если пространство находится рядом с кластером, который уже отслеживается файловой системой, атрибуты сжимаются в одну запись. Однако если пространство фрагментировано, его необходимо отслеживать с несколькими атрибутами. Таким образом, фрагментация тяжелых файлов может привести к исчерпанию атрибутов и результирующей ошибке 665. Это поведение объясняется в следующей статье базы знаний: сильно фрагментированные файлы в томе NTFS не могут превышать определенный размер.

Как обычные, так и разреженные файлы, созданные SQL Server или другими приложениями, могут быть фрагментированы на эти уровни, когда большие объемы изменений данных происходят в течение жизни этих файлов моментальных снимков.

Если вы выполняете резервное копирование базы данных между набором файлов, расположенных на одном томе, или если вы выполняете массовое копирование данных (BCP-ing) в несколько файлов на одном томе, записи могут в конечном итоге находиться в смежных расположениях, но принадлежащих разным файлам. Например, один поток записывается в смещение от 201 до 400, другой поток записывает от 401 до 600, третий поток может записывать от 601 до 800. Этот процесс также продолжается для других потоков. Это приведет к фрагментации файлов на одном физическом носителе. Каждый из файлов резервной копии или выходных потоков BCP может исчерпать хранилище атрибутов, так как ни один из них не получает соседнее хранилище.

Полный фон использования разреженных файлов NTFS и альтернативных потоков данных см. в статье "Дополнительные сведения".

Решение

Чтобы устранить эту проблему, рекомендуется использовать один или несколько следующих вариантов:

  1. Поместите файлы базы данных в том отказоустойчивой файловой системы (ReFS), который не имеет одинаковых ATTRIBUTE_LIST_ENTRY ограничений, которые представляют NTFS . Если вы хотите использовать текущий том NTFS, необходимо переформатировать с помощью ReFS после перемещения файлов базы данных в другое место временно. Использование ReFS — это лучшее долгосрочное решение для решения этой проблемы.

    Примечание.

    SQL Server 2012 и более ранних версий использовали именованные потоки файлов вместо разреженных файлов для создания CHECKDB моментальных снимков. ReFS не поддерживает потоки файлов. Выполнение DBCC CHECKDB файлов SQL Server 2012 в ReFS может привести к ошибкам. Дополнительные сведения см. в заметке о том, как DBCC CHECKDB создает внутреннюю базу данных моментальных снимков, начиная с SQL Server 2014.

  2. Отмените фрагмент тома, в котором находятся файлы базы данных. Убедитесь, что служебная программа дефрагментации является транзакционной. Дополнительные сведения о дефрагментации дисков, в которых находятся файлы SQL Server, см. в статье "Меры предосторожности при дефрагментации дисков базы данных SQL Server" и "Рекомендации". Для выполнения этой операции в файлах необходимо завершить работу SQL Server. Перед дефрагментированием файлов в качестве меры безопасности рекомендуется создать полные резервные копии базы данных. Дефрагментация работает по-разному на носителях ssd и обычно не решает проблему. Копирование файлов и разрешение встроенного ПО SSD для повторного упаковки физического хранилища часто является лучшим решением. Дополнительные сведения см. на странице Ошибка операционной системы (665 — ограничение файловой системы), а не только для DBCC.

  3. Копирование файлов — выполнение копии файла может позволить лучшее приобретение места, так как байты могут быть тесно упакованы вместе в процессе. Копирование файла (или перемещение его в другой том) может снизить использование атрибутов и может предотвратить ошибку ОС 665. Скопируйте один или несколько файлов базы данных на другой диск. Затем вы можете оставить файл на новом томе или скопировать его обратно в исходный том.

  4. Отформатируйте том NTFS с помощью параметра /L для получения большого frS. Этот выбор может оказать облегчение этой проблеме, потому что она делает ATTRIBUTE_LIST_ENTRY больше. Этот выбор может оказаться не полезным при использовании DBCC CHECKDB , так как последний создает разреженный файл для моментального снимка базы данных.

    Примечание.

    Для систем под управлением Windows Server 2008 R2 и Vista сначала необходимо применить исправление из статьи базы знаний 967351 перед использованием /L параметра с format помощью команды.

  5. Разбиите большую базу данных на небольшие файлы. Например, если у вас есть один файл данных размером 8 ТБ, его можно разделить на восемь файлов данных размером 1 ТБ. Этот параметр может помочь, так как меньше изменений будет происходить в небольших файлах, поэтому, скорее всего, может возникнуть исчерпание атрибутов. Кроме того, при перемещении данных вокруг файлы будут упорядочены компактно и фрагментация будет сокращена. Ниже приведены высокоуровневые шаги, которые описывают процесс.

    1. Добавьте в ту же группу файлов семь новых файлов размером 1 ТБ.
    2. Перестройте кластеризованные индексы существующих таблиц, которые автоматически распределяют данные каждой таблицы между восемью файлами. Если в таблице нет кластеризованного индекса, создайте ее и удалите ее, чтобы выполнить то же самое.
    3. Сжать исходный 8-ТБ-файл, который в настоящее время составляет около 12 % полного.

  6. Параметр автоматического увеличения базы данных: настройте параметр автоматического увеличения базы данных, чтобы получить размеры, которые способствуют производительности рабочей среды и упаковке атрибутов NTFS. Чем реже происходит автоматическое увеличение и размер увеличения размера, тем меньше вероятность фрагментации файлов.

  7. Уменьшите время существования DBCC CHECK команд с помощью улучшений производительности и, следовательно, избежать ошибок 665: улучшения команды DBCC CHECKDB могут привести к более быстрой производительности при использовании параметра PHYSICAL_ONLY. Помните, что выполнение DBCC CHECKDB с PHYSICAL_ONLY коммутатором не обеспечивает гарантии того, что вы будете избегать этой ошибки, но это приведет к снижению вероятности во многих случаях.

  8. Если вы выполняете резервное копирование базы данных во многих файлах (набор полосы), тщательно спланируйте количество файлов MAXTRANSFERSIZE и BLOCKSIZE (см. статью BACKUP). Цель состоит в том, чтобы уменьшить фрагменты файловой системы, которые обычно выполняются путем записи больших блоков байтов вместе в файл. Вы можете рассмотреть возможность чередования файлов по нескольким томам для повышения производительности и уменьшения фрагментации.

  9. Если вы используете BCP для одновременной записи нескольких файлов, настройте размер записи служебной программы, например увеличьте размер пакета BCP. Кроме того, рассмотрите возможность написания нескольких потоков в разные тома, чтобы избежать фрагментации или уменьшить количество параллельных операций записи.

  10. Для выполнения DBCC CHECKDBможно настроить группу доступности или резервный сервер доставки журналов. Или используйте второй сервер, где можно запустить DBCC CHECKDB команды, чтобы выгрузить работу и избежать проблем, вызванных тяжелым фрагментированием разреженных файлов.

  11. При выполнении DBCC CHECKDBкоманды в то время, когда на сервере базы данных мало действий, то разреженные файлы будут легко заполнены. Чем меньше записей в файлы, тем меньше вероятность исчерпания атрибутов в NTFS. Меньше действий — это еще одна причина запуска DBCC CHECKDB на втором сервере только для чтения, когда это возможно.

  12. Если вы используете SQL Server 2014, обновите его до последней версии пакета обновления. Дополнительные сведения см. в разделе FIX: ошибка ОС 665 при выполнении команды DBCC CHECKDB для базы данных, содержащей индекс columnstore в SQL Server 2014.

Дополнительная информация