Добрый день, коллеги!

Чтобы «добить» тему, решил описать несколько моментов, которые неожиданно возникли при эксплуатации FILETABLE. Может кому-то пригодится и/или коллеги добавят свои замечания.

1. Отсутствие кластерного индекса. Ну об этом собственно вся тема.

2. Когда созрели требования и файлов в таблице накопилось достаточное количество, решили секционировать таблицу — разделить архивные и актуальные данные. Т.к. версия Standard, единственный вариант распределённые секционированные представления, которые планировали построить по дате создания файла (2015, 2014 и т.д.). Однако схема таблицы изменению не подлежит, т.е. переопределить PK нет возможности. Об этом сказано в документации, просто нужно помнить всегда.

3. Тогда перешли к секционированию ручным способом — создали таблицы по годам, логику написали руками. Для переноса данных по таблицам использовали простой запрос…

insert into dbo.Filetable2015
select * 
from dbo.Filetable
join …

В случае если оптимизатор строит параллельный план, возникает жуткая ошибка. Проблема известная, зафиксирована у Microsoft и находится в статусе Закрыто. m_updNestedXactCnt: Trying to use the transaction while there are 1 parallel nested xacts outstanding

Рекомендация единственная – использовать в запросе option (maxdop 1)

4. Т.к. данных в таблицу вставляется много из п.3, а при вставке для каждой записи выполняются проверки (каталог-файл, родитель-потомок и т.п. около 4-5 штук), то процесс переноса данных идет совсем не быстро. Чтобы увеличить производительность можно отключить все системные ограничения пространства имен на уровне таблицы. После переноса данных проверки на таблице необходимо включить обратно, выполнив команду alter table dbo.Filetable enable filetable_namespace. И вот здесь, в отсутствии сторонних активностей у процесса с самим собой возникает deadlock. Зная о проблемах параллелизма из п.3. перед включением пространства имен временно поставил на уровне сервера Max Degree of Parallelism = 1