Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Павел677 Member Откуда: Сообщений: 24 |
Добрый вечер. Подскажите, как обойти проблему
Задача: SQL 2016 SP1 Есть стороннее приложение (axapta). Выдает примерно 10 тысяч запросов вида : (запрашивает перечень полей полнотекстового индекса для заданной таблички) exec sp_cursoropen @p1 output, N'select name, change_tracking_state_desc from sys.columns AS Cols inner join sys.fulltext_index_columns AS FTSCols inner join sys.fulltext_indexes as FTS on FTSCols.object_id = FTS.object_id on Cols.object_id = FTSCols.object_id where Cols.column_id = FTSCols.column_id and Cols.object_id = object_id(''MYTABLE_X0001'')' ,@p3 output,@p4 output,@p5 output каждый запрос select name, change_tracking_state_desc from sys.columns AS Cols inner join sys.fulltext_index_columns AS FTSCols inner join sys.fulltext_indexes as FTS on FTSCols.object_id = FTS.object_id on Cols.object_id = FTSCols.object_id where Cols.column_id = FTSCols.column_id and Cols.object_id = object_id('MYTABLE_X0001') длится порядка 60-80 миллисекунд. Т.е. в сумме все дает больше 10 минут. Нужно в 10-100 сократить время. При этом, если убрать фильтр по табличке Cols.object_id = object_id(''MYTABLE_X0001'') то выборка вернет всего навсего 25 строк !!! Т.е. полнотекстовые индексы почти не используются. Обидно тратить 10 минут на постоянную выборку из 25 записей :( Как быть ? Я пытался создать индексированную вьюху по инструкции http://www.sqlservertutorial.net/sql-server-views/sql-server-indexed-view/ тогда в ней будет порядка 25 записей и по-любому запрос к ней должен работать быстрее чем 50 миллисекунд. Тогда можно сильно сократить время ожидания. Но получил ошибку вынесенную в заголовок. Как еще можно решить описанную проблему ? Поменять запрос я к сожалению не могу. Он зашит в exe-ник Аксапты. Если бы запрос шел через хранимую процедуру, то можно было бы ее подправить и дело в шляпе. А тут даже не знаю как быть. Может можно скорректировать план исполнения запроса чтобы он работал быстрее ? План смотрел - сплошные Nested loop и Clustered index seek. |
||
28 июн 19, 20:10 [21917323] Ответить | Цитировать Сообщить модератору |
Павел677 Member Откуда: Сообщений: 24 |
План запроса приложил![]() К сообщению приложен файл. Размер - 43Kb |
28 июн 19, 20:24 [21917332] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37143 |
Я думаю, вам на форум по Аксапте, чтобы выяснить, как лечить ее закидоны выполнять по 10к запросов. |
28 июн 19, 21:06 [21917349] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1692 |
Павел677, индексированное представление на системный объект не сделаешь. сделайте пользовательскую таблицу и обновляйте ее время от времени (можно с помощью ddl тригерров), а обращения вашей программы направьте на таблицу |
29 июн 19, 14:28 [21917480] Ответить | Цитировать Сообщить модератору |
Павел677 Member Откуда: Сообщений: 24 |
В Аксапте это зашито в Exe-нике. Поэтому ищу обходные пути, как в самом SQL ускорить запрос. Как вариант (и как посоветовали) заполнять свою табличку нужными записями и патчить exe-ник перенаправляя его на свою табличку, но это совсем тонкая хирургия - не хотелось бы так. |
||
1 июл 19, 09:23 [21917917] Ответить | Цитировать Сообщить модератору |
Павел677 Member Откуда: Сообщений: 24 |
Спасибо за отзыв. Это непросто сделать. Не хочется патчить Exe-ник (штатно мне это недоступно). Может можно вправить мозг CBO, чтобы он выбрал более быстрый план для запроса по системным вьюхам ? |
||
1 июл 19, 09:25 [21917919] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31778 |
Тут проблема в том, что делается 10 тыщ запросов, а не в том, что план кривой. Конечно, из индексированной вьюхи запрос делался бы раз в 10 быстрее, это да, но если бы прога просто считала при запуске эти 25 строк в память, было бы намного лучше... |
||
1 июл 19, 10:17 [21917943] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8316 |
Павел677, лучше не получите по причине использования object_id('MYTABLE_X0001'). |
1 июл 19, 11:39 [21917996] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31778 |
|
||
1 июл 19, 14:23 [21918171] Ответить | Цитировать Сообщить модератору |
Павел677 Member Откуда: Сообщений: 24 |
Со всем согласен, но поменять запрос почти невозможно (править exe-ник стремно, там запрос в нем из кусков собирается. В виде одной строки его в скомпилированном коде нет). Поэтому я и подумал что может можно как-то еще улучшить план или обмануть сиквел и создать материализованную вьюху. Там если убрать фильтр по табличке, то возвращается всего 25 (!) записей. Т.е. с материализованной вьюхой оно было летало меньше 1 миллисекунды. Ну а если ее совсем никак нельзя сделать, то может выкрутить план чтобы еще быстрее фильтровало. Изврат, но что же делать... |
||
1 июл 19, 15:48 [21918284] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31778 |
|
||
1 июл 19, 19:30 [21918477] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31778 |
Самое правильное - обратиться к разработчикам. |
||
1 июл 19, 20:37 [21918513] Ответить | Цитировать Сообщить модератору |
Павел677 Member Откуда: Сообщений: 24 |
Проблема решается так https://www.axforum.info/forums/showthread.php?p=418755#post418755 Все же удалось подкрутить оптимизатор, не смотря на литералы в запросе. Оказывается можно сказать оптимизатору чтобы он работал как-будто там параметры и тогда все быстро. План запроса не перестраивается на каждом вызове и все работает мгновенно. |
23 авг 19, 09:45 [21956209] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |