Сообщения об ошибках ОС 665 и 1450 для SQL Server файлов

  • Статья

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

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

Симптомы

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

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

Примечание.

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

  • Резервное копирование или восстановление баз данных.
  • Вы выполняете массовое копирование через BCP в несколько файлов, используя параллельное выполнение BCP и запись в один том.

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

Причина

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

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

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

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

Разрешение

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

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

    Примечание.

    SQL Server 2012 и более ранних версиях использовали именованные потоки файлов вместо разреженных файлов для создания CHECKDB моментальных снимков. ReFS не поддерживает потоки файлов. Запуск DBCC CHECKDB в файлах SQL Server 2012 в ReFS может привести к ошибкам. Дополнительные сведения см. в заметке о том, как DBCC CHECKDB создает внутреннюю базу данных snapshot начиная с 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 так как последний создает разреженный файл для базы данных snapshot.

    Примечание.

    Для систем под управлением 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, обновите пакет обновления до последней версии. Дополнительные сведения см. в разделе ИСПРАВЛЕНИЕ: ошибка ОС 665 при выполнении команды DBCC CHECKDB для базы данных, содержащей индекс columnstore в SQL Server 2014.

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