Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Переменные и запросы
|
|||
|---|---|---|---|
|
#18+
Не могу понять в чем дело уже битый час сижу... Есть бальшой такой запрос: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Объясните мне в чем же все таки здесь хрущ, я плакаль... Версия Sybase ASE 12.0.0.6/P/EBF Заранее благодарю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2005, 15:18 |
|
||
|
Переменные и запросы
|
|||
|---|---|---|---|
|
#18+
Проблема в том, что в данном случае оптимизатор на этапе построения плана запроса (перед выполнением) не знает значения переменных, и строит план запроса исходя из своих преположений о них. Об этом много говорится в Performance&Tuning в разделе описывающем оптимизацию хранимых процедур. В качестве quick fix - либо используйте значения а не переменные, либо оформите медленный запрос с виде хранимой процедуры с этими параметрами. Ну и Performance&Tuning на сон грядущий. С уважением, Андрей Колчанов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.08.2005, 18:31 |
|
||
|
Переменные и запросы
|
|||
|---|---|---|---|
|
#18+
kolchanovПроблема в том, что в данном случае оптимизатор на этапе построения плана запроса (перед выполнением) не знает значения переменных, и строит план запроса исходя из своих преположений о них. Об этом много говорится в Performance&Tuning в разделе описывающем оптимизацию хранимых процедур. В качестве quick fix - либо используйте значения а не переменные, либо оформите медленный запрос с виде хранимой процедуры с этими параметрами. Ну и Performance&Tuning на сон грядущий. С уважением, Андрей Колчанов Спасибо, Андрей... И еще одна загадка оттуда же... Если в запросе указывать критерий сравнения для дат типа ">=" либо "<=", то он тоже повисает (опять же при использовании переменных) но стоит нам строго указать "=" все проходит на ура... Это связано тоже с тем же, с планом? Тогда есть ли смысл воспользоваться директивой "#M_FORCEPLAN_OFF"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 07:36 |
|
||
|
Переменные и запросы
|
|||
|---|---|---|---|
|
#18+
ох, чую, чую Диасофт... Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 09:31 |
|
||
|
Переменные и запросы
|
|||
|---|---|---|---|
|
#18+
c0smic_ , а в начале секции стоит #M_FORCEPLAN? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 16:59 |
|
||
|
Переменные и запросы
|
|||
|---|---|---|---|
|
#18+
В ASE 12.5 много и плодотворно приходилось использовать хинты, в связи с природной "тупостью" АSE-шного оптимизатора. Особенно на запросах по интервалу дат. Еще конечно очень желательно обновить статистику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 17:27 |
|
||
|
Переменные и запросы
|
|||
|---|---|---|---|
|
#18+
c0smic_Если в запросе указывать критерий сравнения для дат типа ">=" либо "<=", то он тоже повисает (опять же при использовании переменных) но стоит нам строго указать "=" все проходит на ура... Это связано тоже с тем же, с планом? Это связано видимо с тем, что ">=" и "=" - мягко говоря, немного разные операции, и они так легонечко вам семантику запроса-то меняют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 02:20 |
|
||
|
Переменные и запросы
|
|||
|---|---|---|---|
|
#18+
Недавно наступал на подобные грабли, при несовпадении типов переменных запрос выполнялся около 30 мин, но стоило изменить тип переменных время сократилось до ~10 c. Обычно такое происходит из-за несоответствия типов данных .... Несоответствия типов данных приводят к проблемам с оптимизацией, так как они не позволяют оптимизатору выбирать индекс. Наиболее часто встречающиеся проблемы возникают по следующим причинам: • из-за сравнений между целочисленными типами, int, smallint и tinyint; • из-за сравнений между типами money и smallmoney; • из-за сравнений между типами datetime и smalldatetime; • из-за сравнений между типами numeric и decimal разной точности и масштаба; • из-за сравнений между типами numeric или decimal и столбцами integer или money. какие таблицы используются в запросе ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2005, 10:13 |
|
||
|
Переменные и запросы
|
|||
|---|---|---|---|
|
#18+
c0smic_Спасибо, Андрей... И еще одна загадка оттуда же... Если в запросе указывать критерий сравнения для дат типа ">=" либо "<=", то он тоже повисает (опять же при использовании переменных) но стоит нам строго указать "=" все проходит на ура... Это связано тоже с тем же, с планом? Тогда есть ли смысл воспользоваться директивой "#M_FORCEPLAN_OFF"? Ну это же коню понятно откуда ноги растут. У вас селективность по дате высокая, поэтому индекс по конкретной дате используется всегда! А когда запрос по диапозону дат, то вполне возможно, что период будет большим и дешевле использовать сканирование, поэтому оптимизатор его и выбирают. Внимательно перечитайте ответ kolchanov и особенно обратите внимание выделить "тяжелый" запрос в отдельную процедуру с конкретными параметрыми и все у вас будет хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2005, 11:45 |
|
||
|
Переменные и запросы
|
|||
|---|---|---|---|
|
#18+
karitosНедавно наступал на подобные грабли, при несовпадении типов переменных запрос выполнялся около 30 мин, но стоило изменить тип переменных время сократилось до ~10 c. Обычно такое происходит из-за несоответствия типов данных .... А какая версия сервера у вас была ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2005, 12:47 |
|
||
|
Переменные и запросы
|
|||
|---|---|---|---|
|
#18+
MasterZiv А какая версия сервера у вас была ? ASE 12.0.0.6 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2005, 15:57 |
|
||
|
|

start [/forum/topic.php?fid=55&fpage=98&tid=2013443]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
35ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 271ms |
| total: | 396ms |

| 0 / 0 |
