Добрый вечер.

Подскажите, как обойти проблему
авторCannot schema bind view 'dbo.XXX' because it references system object 'sys.columns'.

Задача:

SQL 2016 SP1

Есть стороннее приложение (axapta).
Выдает примерно 10 тысяч запросов вида :
(запрашивает перечень полей полнотекстового индекса для заданной таблички)




каждый запрос


длится порядка 60-80 миллисекунд.

Т.е. в сумме все дает больше 10 минут.
Нужно в 10-100 сократить время.

При этом, если убрать фильтр по табличке



то выборка вернет всего навсего 25 строк !!!
Т.е. полнотекстовые индексы почти не используются. Обидно тратить 10 минут на постоянную выборку из 25 записей :(

Как быть ?
Я пытался создать индексированную вьюху по инструкции
http://www.sqlservertutorial.net/sql-server-views/sql-server-indexed-view/

тогда в ней будет порядка 25 записей и по-любому запрос к ней должен работать быстрее чем 50 миллисекунд.
Тогда можно сильно сократить время ожидания.

Но получил ошибку вынесенную в заголовок.

Как еще можно решить описанную проблему ?

Поменять запрос я к сожалению не могу. Он зашит в exe-ник Аксапты.
Если бы запрос шел через хранимую процедуру, то можно было бы ее подправить и дело в шляпе. А тут даже не знаю как быть.

Может можно скорректировать план исполнения запроса чтобы он работал быстрее ?

План смотрел - сплошные Nested loop и Clustered index seek.

План запроса приложил

Гавриленко Сергей АлексеевичЯ думаю, вам на форум по Аксапте, чтобы выяснить, как лечить ее закидоны выполнять по 10к запросов.

В Аксапте это зашито в Exe-нике.
Поэтому ищу обходные пути, как в самом SQL ускорить запрос.
Как вариант (и как посоветовали) заполнять свою табличку нужными записями и патчить exe-ник перенаправляя его на свою табличку, но это совсем тонкая хирургия - не хотелось бы так.

felix_ffПавел677,
...
а обращения вашей программы направьте на таблицу

Спасибо за отзыв.
Это непросто сделать. Не хочется патчить Exe-ник (штатно мне это недоступно).

Может можно вправить мозг CBO, чтобы он выбрал более быстрый план для запроса по системным вьюхам ?

alexeyvgТут проблема в том, что делается 10 тыщ запросов, а не в том, что план кривой.
Конечно, из индексированной вьюхи запрос делался бы раз в 10 быстрее, это да, но если бы прога просто считала при запуске эти 25 строк в память, было бы намного лучше...

Со всем согласен, но поменять запрос почти невозможно (править exe-ник стремно, там запрос в нем из кусков собирается. В виде одной строки его в скомпилированном коде нет).
Поэтому я и подумал что может можно как-то еще улучшить план или обмануть сиквел и создать материализованную вьюху. Там если убрать фильтр по табличке, то возвращается всего 25 (!) записей. Т.е. с материализованной вьюхой оно было летало меньше 1 миллисекунды. Ну а если ее совсем никак нельзя сделать, то может выкрутить план чтобы еще быстрее фильтровало. Изврат, но что же делать...

Проблема решается так
https://www.axforum.info/forums/showthread.php?p=418755#post418755

Все же удалось подкрутить оптимизатор, не смотря на литералы в запросе.
Оказывается можно сказать оптимизатору чтобы он работал как-будто там параметры и тогда все быстро. План запроса не перестраивается на каждом вызове и все работает мгновенно.