День добрый.
Подскажите пжлст, что можно сделать с snapshot -ом, чтобы он периодически не валился с ошибкой 665.
Схема такая. Есть основной сервер1 с oltp нагрузкой (разнообразная и постоянная вставка данных), БД отзеркалирована на другой сервер2, с зеркала по утрам делается снапшот и уже с этим снапом работают пользователи в режиме а-ля olap, т.е. гоняют разнообразные отчеты. ОС на обоих серверах Win2012R2, SQL2016Enterprise также на обоих, на дисках ессно NTFS, диски - через FC на СХД неплохого уровня (EMC VNX5500), размер БД порядка 1.5тб, количество записей в самой большой "проблемной" таблице - более 1млрд.
Ошибка имеет вид:
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 0x0000116fbf4000 in file 'D:\Snapshot\myDB.ss'.
Error: 17053, Severity: 16, State: 1.
и дальше:
SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 5:20340841; actual 0:0). It occurred during a read of page (5:20340841) in database ID 7 at offset 0x000026cc0d2000 in file 'D:\Snapshot\myORC.ss'
Ошибка возникает в разное время, разумеется в тот момент, когда идут массовые изменения/вставки в БД-источник. Раньше возникала ночью, ну когда данные из удаленных площадок сливались в общую БД, но то не страшно, утром снап заново создавался. В последнее время все чаще в течении рабочего дня.
Что важно. Снап лежит на том же диске, что и БД-зеркало. Места на диске достаточно, из 3тб, минимум 1.2 всегда свободны. Максимум размер снапа, до которого вырастал за день - 300-400гб.
С чего начать? Снап переносить на отдельный диск? Уменьшать размер файла, в котором "проблемная" таблица (это вот эта файловая группа myORC, на которую указывает ошибка)? Там в принципе, есть что перенести, другие таблицы, индексы...
Зеркалирование работает без проблем и ошибок, кстати.

invm https://support.microsoft.com/en-us/help/2002606/os-errors-1450-and-665-are-reported-for-database-data-files
Кмк, это не то. Файл снапшота создается каждый день заново, как он может быть сильно фрагментирован? Да и ОС ничего не сообщает, ntfs.sys бы ругался

Ну если реальный размер файла снапа на диске - от 30 до 100гб, то это явно не "всю базу перезаливать". Сложно оценить кол-во изменений в течении дня, но это порядка нескольких миллионов, а не сотни млн.
Сообщение об ошибке генерирует сам скл. ОС как бы и не замечает проблемы, дополнительных ошибок нет

Кстати контиг говорит, что всего 985 фрагментов на террабайтный файл снапа. Но это с утра конечно, пока он пустой. Посмотрим в течении дня...

А можно ли как то периодически проверять "работоспособность" снапшота? Ну джоб с какой то проверкой раз в час запускать, если снап протух - пересоздать.

Andy_OLAP, эта опция, емнип, стоит не таких уж малых денег. В любом случае, у нас ее нет

"По советам товарищей приобрел автомобиль Москвич".
Создал новый лун на той же схд и на нем диск отформатировал в ReFS. Создание snapshot отработало на этом новом диске нормально. Продолжаю наблюдение, обычно ошибки случались в выходные, когда данных больше.

Andy_OLAP, может и неактуально...
Но в течении нескольких лет снапшот работал на ReFS без каких либо ошибок. Более того. На новом сервере забыл про данную проблему и диск под снапы создал в ntfs. Ошибки вернулись ) Переформатировал в ReFS - все ушло