Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / NAV, SQL 2000 и оптимизатор запросов / 25 сообщений из 54, страница 1 из 3
  1  все
09.09.2010, 15:57
    #36838289
anatoleech
anatoleech
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
Всем - здравствовать!

Очень непонятная проблема съедает мозг.
Есть NAV (бывш. Navision, вдруг если кто не знает это ERP такая).
База живёт на SQL 2000, огромная - терабайт.

Есть некая таблица (339, для тех кто NAV знает).
В таблице в NAV есть ключ "Примен.-к Операции Но.,Примен.-из Операции Но.".
Галка "maintain SQL index" установлена, ключ в SQL присутствует, ключ не битый.

По этому ключу в NAV делается выборка рекордсета:

Код: plaintext
1.
2.
3.
4.
RESET;
SETCURRENTKEY("Примен.-к Операции Но.","Примен.-из Операции Но.");
SETFILTER("Примен.-к Операции Но.",'<>0');
SETRANGE("Примен.-из Операции Но.", 30195 );
IF FIND('-') THEN..........

В "родной" БД, и вообще на всех SQL-базах, с которыми я в жизни имел дело, такой запрос выполняется моментально, ибо фильтры кладутся по ключу. В этой базе, выполнение выборки занимает МИНУТУ.

Стал искать, в чём дело. Выполнил код под монитором клиента (для не-навиженологов, это такая штука, в которой можно посмотреть на кишки выполняющегося процесса, своего рода дебаггер). Увидел следующее (очень извиняюсь за нечитабельный вид):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Имя функции	Номер параметра	 Параметр	Номер	Данные
FIND/NEXT	 1 	Table	 339 	Товар Книга Применения
FIND/NEXT	 2 	Search Method		-
FIND/NEXT	 3 	Key		Примен.-к Операции Но.,Примен.-из Операции Но.,Операция Но.
FIND/NEXT	 6 	Filter		Примен.-к Операции Но.:<> 0 , Примен.-из Операции Но.: 30195 
FIND/NEXT	 14 	Source Object		Report  57000  Исправление Применений
FIND/NEXT	 15 	Source Trigger/Function		ОбработатьРасход(Товар Книга Операций)
FIND/NEXT	 16 	Source Line No.	 211 	
FIND/NEXT	 17 	Source Text		IF Debugmode THEN
FIND/NEXT	 30 	SQL Statement		SELECT  * FROM "Основная БД для тестирования$Товар Книга Применения" WITH (READUNCOMMITTED)   WHERE (("Примен.-к Операции Но."<> 0 )) AND (("Примен.-из Операции Но."= 30195 )) ORDER BY "Примен.-к Операции Но.","Примен.-из Операции Но.","Операция Но." 
FIND/NEXT	 31 	SQL Plan		Sort[ 2 , 1 ];Filter[ 3 , 2 ];Nested Loops[ 4 , 3 ];Index Seek($ 5 )[ 6 , 4 ];Clustered Index Seek(Основная БД для тестирования$Товар Книга Применения$ 0 )[ 8 , 4 ]
FIND/NEXT	 32 	SQL Index		Примен.-из Операции Но.,Операция Но.
FIND/NEXT	 50 	Search Result		
FIND/NEXT	 100 	Elapsed Time (ms)	 54039

Говоря по-русски, получается следующее: из NAV в SQL передаётся совершенно правильный, нормальный запрос:

Код: plaintext
SELECT  * FROM "Основная БД для тестирования$Товар Книга Применения" WITH (READUNCOMMITTED)   WHERE (("Примен.-к Операции Но."<> 0 )) AND (("Примен.-из Операции Но."= 30195 )) ORDER BY "Примен.-к Операции Но.","Примен.-из Операции Но.","Операция Но."

Но при этом в SQL почему-то выборка выполняется по уродскому ключу Примен.-из Операции Но.,Операция Но., что естественно приводит к фильтрации по неключевому полю с 54-секундным выполнением.

Самое интересное, что если этот же запрос выполнить непосредственно в SQL, результаты возвращаются моментально.

Подозреваем, что косячит оптимизатор запросов, но точно определить не можем, и обойти тоже не знаем как. Мы в полном ступоре. Помогите понять, в чём дело?

Если вдруг будет нужно - можно мне звонить (903)5672441 для оперативности, приму любую помощь.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:10
    #36838306
petsa
petsa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
Самое интересное, что если этот же запрос выполнить непосредственно в SQL, результаты возвращаются моментально.

Хм.. А тут почему оптимизатор не косячит?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:13
    #36838313
petsa
petsa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
А вообще запросы к SQL-серверу надо профайлером смотреть. Это будет запрос, который получает сервер.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:14
    #36838314
anatoleech
anatoleech
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
petsaСамое интересное, что если этот же запрос выполнить непосредственно в SQL, результаты возвращаются моментально.

Хм.. А тут почему оптимизатор не косячит?
Понятия не имею. Честно говоря, я SQL практически не знаю. Потому и прошу совета, у меня идей нет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:15
    #36838318
_djХомяГ
_djХомяГ
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
Вы уверены , что из Navision данный select передаётся в том же виде, что и из MS SQL (кстати это можно посмотреть профайлером) Подозреваю , что в случае с Navision на сервер передаётся что то типа sp_executesql или нечто похожее.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:16
    #36838320
Glory
Glory
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
anatoleech

Но при этом в SQL почему-то выборка выполняется по уродскому ключу Примен.-из Операции Но.,Операция Но., что естественно приводит к фильтрации по неключевому полю с 54-секундным выполнением.

Это вы про план выпроления что ли ?


anatoleech
Самое интересное, что если этот же запрос выполнить непосредственно в SQL, результаты возвращаются моментально.

Подозреваем, что косячит оптимизатор запросов, но точно определить не можем, и обойти тоже не знаем как. Мы в полном ступоре. Помогите понять, в чём дело?

Если вдруг будет нужно - можно мне звонить (903)5672441 для оперативности, приму любую помощь.
На план выполнения могут оказать влияние настройки SET коннекта
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:19
    #36838326
anatoleech
anatoleech
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
_djХомяГВы уверены , что из Navision данный select передаётся в том же виде, что и из MS SQL (кстати это можно посмотреть профайлером) Подозреваю , что в случае с Navision на сервер передаётся что то типа sp_executesql или нечто похожее.
Спасибо, попробуем.
Но тем не менее, факт что SQL использует левый ключ вместо конкретно указанного.
Почему, как бороться, в чём причины могут быть?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:20
    #36838330
daw
daw
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
> Но при этом в SQL почему-то выборка выполняется по уродскому ключу
> Примен.-из Операции Но.,Операция Но., что естественно приводит к
> фильтрации по неключевому полю с 54-секундным выполнением.

гм. не объясните, почему вы считаете, что для вашего запроса должен использоваться
ключ (Примен.-к Операции Но.,Примен.-из Операции Но.), а не (Примен.-из Операции Но.,Операция Но.)

лично на мой взгляд выбор сервера вполне логичен.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:22
    #36838340
anatoleech
anatoleech
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
Gloryanatoleech

Но при этом в SQL почему-то выборка выполняется по уродскому ключу Примен.-из Операции Но.,Операция Но., что естественно приводит к фильтрации по неключевому полю с 54-секундным выполнением.

Это вы про план выпроления что ли ?

Это то, что я вижу в мониторе клиента в навижене. В SQL ушёл вполне определённый запрос, а выполняется он по другому ключу.

Glory
anatoleech
Самое интересное, что если этот же запрос выполнить непосредственно в SQL, результаты возвращаются моментально.

Подозреваем, что косячит оптимизатор запросов, но точно определить не можем, и обойти тоже не знаем как. Мы в полном ступоре. Помогите понять, в чём дело?

На план выполнения могут оказать влияние настройки SET коннекта
Не-не-не, тут никакого коннекта не SET, это не вызов процедур, это выборка, которая производится навиженом из своей же базы данных.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:23
    #36838344
Glory
Glory
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
anatoleechGloryanatoleech

Но при этом в SQL почему-то выборка выполняется по уродскому ключу Примен.-из Операции Но.,Операция Но., что естественно приводит к фильтрации по неключевому полю с 54-секундным выполнением.

Это вы про план выпроления что ли ?

Это то, что я вижу в мониторе клиента в навижене. В SQL ушёл вполне определённый запрос, а выполняется он по другому ключу.

Что такое "выполняется по ключу" в терминах MSSQL?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:24
    #36838349
Glory
Glory
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
anatoleech
Не-не-не, тут никакого коннекта не SET, это не вызов процедур, это выборка, которая производится навиженом из своей же базы данных.
Это как - запрос выполняется, а коннекта к серверу нет ? А как тогда без коннекта запрос вообще попадает на сервер ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:24
    #36838351
Crimean
Crimean
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
в профайлере конекшен сеттинги сравните. а после в квере поставьте себе сеттинги нава и повторите запрос. скорее всего и поведение запроса изменится.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:26
    #36838362
anatoleech
anatoleech
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
daw
> Но при этом в SQL почему-то выборка выполняется по уродскому ключу
> Примен.-из Операции Но.,Операция Но., что естественно приводит к
> фильтрации по неключевому полю с 54-секундным выполнением.

гм. не объясните, почему вы считаете, что для вашего запроса должен использоваться
ключ (Примен.-к Операции Но.,Примен.-из Операции Но.), а не (Примен.-из Операции Но.,Операция Но.)

лично на мой взгляд выбор сервера вполне логичен.


Не логичен.

Вот код, который выполняется в NAV:

Код: plaintext
1.
2.
3.
4.
5.
RESET;
SETCURRENTKEY("Примен.-к Операции Но.","Примен.-из Операции Но.");
SETFILTER("Примен.-к Операции Но.",'<>0');
SETRANGE("Примен.-из Операции Но.", 30195 );
IF FIND('-') THEN..........
Обратите внимание на ключ и на фильтры.

Вот запрос, который уходит в SQL:
Код: plaintext
SELECT  * FROM "Основная БД для тестирования$Товар Книга Применения" WITH (READUNCOMMITTED)   WHERE (("Примен.-к Операции Но."<> 0 )) AND (("Примен.-из Операции Но."= 30195 )) ORDER BY "Примен.-к Операции Но.","Примен.-из Операции Но.","Операция Но."
Обратите внимание на ключ и на фильтры.

Фильтрация по двум полям, оба поля входят в составной ключ из двух полей (не считая первичного ключа), а используется ключ из одного поля (не считая первичного ключа).

Логично было бы взять конкретно указанный ключ с обоими фильтруемыми полями, а SQL предпочитает почему-то брать ключ с одним полем, что неправильно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:27
    #36838369
anatoleech
anatoleech
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
GloryanatoleechGloryanatoleech

Но при этом в SQL почему-то выборка выполняется по уродскому ключу Примен.-из Операции Но.,Операция Но., что естественно приводит к фильтрации по неключевому полю с 54-секундным выполнением.

Это вы про план выпроления что ли ?

Это то, что я вижу в мониторе клиента в навижене. В SQL ушёл вполне определённый запрос, а выполняется он по другому ключу.

Что такое "выполняется по ключу" в терминах MSSQL?

мм.... не имею ни малейшего понятия, что это в индексах MSSQL :(
Подозреваю, что это может называться как-то вроде "использования индекса" или "использования ключа".
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:29
    #36838378
Glory
Glory
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
anatoleech
Логично было бы взять конкретно указанный ключ с обоими фильтруемыми полями, а SQL предпочитает почему-то брать ключ с одним полем, что неправильно.
И где вы видите, что сервер делает по-другому ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:34
    #36838396
Glory
Glory
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
anatoleech не имею ни малейшего понятия, что это в индексах MSSQL :(
Подозреваю, что это может называться как-то вроде "использования индекса" или "использования ключа".
И еще раз - где вы видите, _как_ MSSQL выполняет ваш запрос в обеих случаях ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:34
    #36838397
daw
daw
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
> Обратите внимание на ключ и на фильтры.
>
> Фильтрация по двум полям, оба поля входят в составной ключ из двух полей
> (не считая первичного ключа), а используется ключ из одного поля (не
> считая первичного ключа).
>
> Логично было бы взять конкретно указанный ключ с обоими фильтруемыми
> полями, а SQL предпочитает почему-то брать ключ с одним полем, что
> неправильно.

а вы вообще представляете себе, как индексы устроены и как поиск по индексу происходит?
я сильно подозреваю, что строк, для которых "Примен.-к Операции Но."<>0
гооораздо больше, чем тех, для которых "Примен.-из Операции Но."=30195
поправьте, если это не так. а если так, то эффективнее будет индекс, где
"Примен.-из Операции Но." стоит первым в списке ключевых столбцов.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:35
    #36838403
_djХомяГ
_djХомяГ
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
автор
Но при этом в SQL почему-то выборка выполняется по уродскому ключу Примен.-из Операции Н

ААА вообще то сервак делает правильно ("Примен.-из Операции Но."=30195)является sarga'ble , а вот римен.-к Операции Но.",'<>0' - нет
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:36
    #36838408
anatoleech
anatoleech
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
Gloryanatoleech
Не-не-не, тут никакого коннекта не SET, это не вызов процедур, это выборка, которая производится навиженом из своей же базы данных.
Это как - запрос выполняется, а коннекта к серверу нет ? А как тогда без коннекта запрос вообще попадает на сервер ?
Потому что это и есть сервер навижена. Навижен шурует в своей же базе, своими же средствами, он к ней уже подключен. Вряд ли смогу внятно более объяснить - это чёрный ящик.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:36
    #36838413
alexeyvg
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
anatoleechФильтрация по двум полям, оба поля входят в составной ключ из двух полей (не считая первичного ключа), а используется ключ из одного поля (не считая первичного ключа).

Логично было бы взять конкретно указанный ключ с обоими фильтруемыми полями, а SQL предпочитает почему-то брать ключ с одним полем, что неправильно.Странно, вы же написали, что как раз сервер использует индекс с двумя полями, как и должно быть:anatoleechНо при этом в SQL почему-то выборка выполняется по уродскому ключу Примен.-из Операции Но.,Операция Но., что естественно приводит к фильтрации по неключевому полю с 54-секундным выполнением.
Вам нужно освоить терминологию, профпайлер и вообще SQL Server, или привлечь соответствующего специалиста.
Без этого не получится, или будет очень долго.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:36
    #36838414
daw
daw
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
сколько у вас (в процентах от общего количества) строк, где "Примен.-к Операции Но."<>0
и сколько таких, где "Примен.-из Операции Но."=30195 ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:37
    #36838416
anatoleech
anatoleech
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
Gloryanatoleech не имею ни малейшего понятия, что это в индексах MSSQL :(
Подозреваю, что это может называться как-то вроде "использования индекса" или "использования ключа".
И еще раз - где вы видите, _как_ MSSQL выполняет ваш запрос в обеих случаях ?
В мониторе клиента. Это собственное средство NAV.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:37
    #36838419
Glory
Glory
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
anatoleechGloryanatoleech
Не-не-не, тут никакого коннекта не SET, это не вызов процедур, это выборка, которая производится навиженом из своей же базы данных.
Это как - запрос выполняется, а коннекта к серверу нет ? А как тогда без коннекта запрос вообще попадает на сервер ?
Потому что это и есть сервер навижена. Навижен шурует в своей же базе, своими же средствами, он к ней уже подключен. Вряд ли смогу внятно более объяснить - это чёрный ящик.
Какой нафиг ящик
Нельзя выполнить никакой команды на MSSQL без создания коннекта к нему
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:44
    #36838444
anatoleech
anatoleech
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
alexeyvganatoleechФильтрация по двум полям, оба поля входят в составной ключ из двух полей (не считая первичного ключа), а используется ключ из одного поля (не считая первичного ключа).

Логично было бы взять конкретно указанный ключ с обоими фильтруемыми полями, а SQL предпочитает почему-то брать ключ с одним полем, что неправильно.Странно, вы же написали, что как раз сервер использует индекс с двумя полями, как и должно быть:anatoleechНо при этом в SQL почему-то выборка выполняется по уродскому ключу Примен.-из Операции Но.,Операция Но., что естественно приводит к фильтрации по неключевому полю с 54-секундным выполнением.
Вам нужно освоить терминологию, профпайлер и вообще SQL Server, или привлечь соответствующего специалиста.
Без этого не получится, или будет очень долго.

Должно быть "Применено-к, применено-из". Используется "Применено-из".
Терминологию осваивать нет резона, да и некогда. При работе с sqlной базой NAV, с SQL обычно приходится иметь дело просто на уровне администрирования.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.09.2010, 16:46
    #36838449
Glory
Glory
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NAV, SQL 2000 и оптимизатор запросов
anatoleechПри работе с sqlной базой NAV, с SQL обычно приходится иметь дело просто на уровне администрирования.
Т.е. вы сидите в какой-то утилите Navison и считаете, что она вам показывает то, что действительно происходит на MSSQL сервере ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / NAV, SQL 2000 и оптимизатор запросов / 25 сообщений из 54, страница 1 из 3
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 536ms
Закрыть
start [/forum/topic.php?fid=29&tablet=1&tid=1526391]:
 0ms
get settings:
 12ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 179ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 65ms
get tp. blocked users:
 2ms
others: 242ms
total:  536ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]