powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / ASE 12.5 Тормозит сортировка
16 сообщений из 16, страница 1 из 1
ASE 12.5 Тормозит сортировка
    #33006851
L_Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день.
Таблицы в скрипте:

--Следующий запрос выполняется 20сек если еспользуется order by

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select distinct TBD_ID
from TAKING_BLOOD_DOSE, ILLNESS_HISTORY, TAKING_BLOOD
where IH_DNRT_ID<> 3 
  AND TBD_ID not in ( select DM_TBD_ID from DOSE_MOVEMENT )
  AND TBD_IS_PROCESSED= 0 
  AND TBD_IS_GIVEN= 0 
  AND TB_IH_ID=IH_ID
  AND TBD_BD_ID is null
  AND TBD_TB_ID=TB_ID
order by TB_NUMBER, TB_DATE

План запроса и статистика :

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
 The sort for Worktable1 is done in Serial

 QUERY PLAN FOR STATEMENT  1  (at line  1 ).


 STEP  1 
 The type of query is INSERT.
 The update mode is direct.
 Worktable1 created, in allpages locking mode, for ORDER BY.

 FROM TABLE
 TAKING_BLOOD_DOSE
 Nested iteration.
 Table Scan.
 Forward scan.
 Positioning at start of table.

 Run subquery  1  (at nesting level  1 ).
 Using I/O Size  2  Kbytes for data pages.
 With LRU Buffer Replacement Strategy for data pages.

 FROM TABLE
 TAKING_BLOOD
 Nested iteration.
 Using Clustered Index.
 Index : PK_TAKING_BLOOD
 Forward scan.
 Positioning by key.
 Keys are:
 TB_ID ASC
 Using I/O Size  2  Kbytes for data pages.
 With LRU Buffer Replacement Strategy for data pages.

 FROM TABLE
 ILLNESS_HISTORY
 EXISTS TABLE : nested iteration.
 Using Clustered Index.
 Index : PK_ILLNESS_HISTORY
 Forward scan.
 Positioning by key.
 Keys are:
 IH_ID ASC
 Using I/O Size  2  Kbytes for data pages.
 With LRU Buffer Replacement Strategy for data pages.
 TO TABLE
 Worktable1.

 STEP  2 
 The type of query is SELECT.
 This step involves sorting.

 FROM TABLE
 Worktable1.
 Using GETSORTED
 Table Scan.
 Forward scan.
 Positioning at start of table.
 Using I/O Size  2  Kbytes for data pages.
 With MRU Buffer Replacement Strategy for data pages.
 STEP  1 

 NESTING LEVEL  1  SUBQUERIES FOR STATEMENT  1 .

 QUERY PLAN FOR SUBQUERY  1  (at nesting level  1  and at line  1 ).

 Correlated Subquery.
 Subquery under an IN predicate.


 STEP  1 
 The type of query is SELECT.
 Evaluate Ungrouped ANY AGGREGATE.

 FROM TABLE
 DOSE_MOVEMENT
 EXISTS TABLE : nested iteration.
 Index : FK_DM_TBD
 Forward scan.
 Positioning at index start.
 Index contains all needed columns. Base table will not be read.
 Using I/O Size  2  Kbytes for index leaf pages.
 With LRU Buffer Replacement Strategy for index leaf pages.

 END OF QUERY PLAN FOR SUBQUERY  1 .


 Parse and Compile Time  0 .
 SQL Server cpu time:  0  ms.
 Table: TAKING_BLOOD_DOSE scan count  1 , logical reads: (regular= 3851  apf= 0  total= 3851 ), physical reads: (regular= 722  apf= 3129  total= 3851 ), apf IOs used= 3129 
 Table: ILLNESS_HISTORY scan count  50000 , logical reads: (regular= 150000  apf= 0  total= 150000 ), physical reads: (regular= 13251  apf= 0  total= 13251 ), apf IOs used= 0 
 Table: TAKING_BLOOD scan count  50000 , logical reads: (regular= 152991  apf= 0  total= 152991 ), physical reads: (regular= 26597  apf= 1646  total= 28243 ), apf IOs used= 653 
 Table: DOSE_MOVEMENT scan count  50000 , logical reads: (regular= 50000  apf= 0  total= 50000 ), physical reads: (regular= 0  apf= 0  total= 0 ), apf IOs used= 0 
 Table: Worktable1 scan count  0 , logical reads: (regular= 53389  apf= 0  total= 53389 ), physical reads: (regular= 1116  apf= 0  total= 1116 ), apf IOs used= 0 
 Total writes for this command:  1729 
 Statement:  1  Subquery:  1  cache size:  0  hits:  0  misses:  0 

 Execution Time  141 .
 SQL Server cpu time:  14100  ms. SQL Server elapsed time:  19203  ms.


добавление составного индекса по TB_NUMBER,TB_DATE ситуацию не меняет, без сортировки выполняется быстро. Этот запрос формируется динамически поэтому менять его нельзя. Настройки сервера стандартные, изменяли только число открытых объектов и индексов по 5000. Что можно поменять в настройках сервера, какие параметры крутить? Глава по производительность и тюнинг БД уже прочитана несколько раз.
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33007335
Litus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Очень много всего написано, потому скажу эмпирически (может и не в тему)...
Создание таблиц и индексов и заполнение их данными должно производиться в разных запросах (процедурах), иначе оптимизатор "не заметит" индекса.
Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33007556
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В следующий раз будь любезен класть такие длинные листинги в виде вложения. Это я тебе как мадыратыр прошу.
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33007706
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот скрипт по созданию таблиц и индексов :
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33007757
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сделай пожалуйста следующее :
Код: plaintext
1.
2.
3.
4.
select count(*) from TAKING_BLOOD_DOSE
select count(*) from ILLNESS_HISTORY
select count(*) from TAKING_BLOOD
select count(*) from DOSE_MOVEMENT
Проставь также алиасы для таблиц и колонок - иначе вообще не понятно, что запрос делает.

Но уже и сейчас видно, что ORDER BY тут совершенно ни при чем.
Потому что тормозит вычитание, т.е. часть
Код: plaintext
1.
2.
3.
...
from TAKING_BLOOD_DOSE ...
where ... TBD_ID not in ( select DM_TBD_ID from DOSE_MOVEMENT )

видно из следующего :

FROM TABLE
TAKING_BLOOD_DOSE
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
...
NESTING LEVEL 1 SUBQUERIES FOR STATEMENT 1.

QUERY PLAN FOR SUBQUERY 1 (at nesting level 1 and at line 1).

Correlated Subquery.
Subquery under an IN predicate.


STEP 1
The type of query is SELECT.
Evaluate Ungrouped ANY AGGREGATE.

FROM TABLE
DOSE_MOVEMENT
EXISTS TABLE : nested iteration.
Index : FK_DM_TBD
Forward scan.
Positioning at index start.

Index contains all needed columns. Base table will not be read.
Using I/O Size 2 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.

END OF QUERY PLAN FOR SUBQUERY 1.

Т.е. причины плохой работы след:
-- при выборке из основной таблицы не используются критерии поиска
-- при выполнении вычитания (подзапрос) не используется позиционирование по индексу.
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33007810
L_Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZivСделай пожалуйста следующее :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select count(*) from TAKING_BLOOD_DOSE

 100000 

select count(*) from ILLNESS_HISTORY

 50000 
select count(*) from TAKING_BLOOD
 100000 
select count(*) from DOSE_MOVEMENT
 5 
Код: plaintext
1.



Нельзя запрос изменить - он генериться динамически и в след. раз могут быть добавлены другие условия. Я думаю что у меня не настроен сервер, кеши и т.д.
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33007939
L_Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZiv

Но уже и сейчас видно, что ORDER BY тут совершенно ни при чем.
Потому что тормозит вычитание, т.е. часть
Код: plaintext
1.
2.
3.
...
from TAKING_BLOOD_DOSE ...
where ... TBD_ID not in ( select DM_TBD_ID from DOSE_MOVEMENT )



Если я выкидывал вычитание то запрос быстрее на 2 сек, если выбрасываю order то запрос мгновенно выполняется.
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33007988
Litus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
a set forceplan on в начале
и
at isolation read uncomitted в конце запроса
не пробовали ставить?

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33008136
L_Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Litusa set forceplan on в начале
и
at isolation read uncomitted в конце запроса
не пробовали ставить?

Posted via ActualForum NNTP Server 1.1

А - все повисло совсем, пришлось сервер рестартовать.
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33008306
Litus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
я написал по-дурацки. "а" - это предлог был. Прошу прощения.

set forceplan on
select ...
at isolation read uncommitted

вот так вот. Без "а"
Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33008353
L_Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Litusя написал по-дурацки. "а" - это предлог был. Прошу прощения.

set forceplan on
select ...
at isolation read uncommitted

вот так вот. Без "а"
Posted via ActualForum NNTP Server 1.1
Я все правильно понял :) , но запрос вешает базу ((
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33008624
Litus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
:-) Только сейчас заметил: хорошее название TAKING_BLOOD_DOSE
Очень странно звучит, что запрос вешает сервер до такой степени, что его приходится перегружать. :-(
ИМХО время выполнения отчета - весьма капризная вещь. У нас тоже запросы в разное время суток могут выполняться по-разному. И определить, почему так происходит - весьма сложная задача (для меня по крайней мере). причиной тому - огромное количество факторов, влиящих на это самое время. Состояние кэша, текущая загрузка сервера, текущие размеры таблиц, участвующих в запросе - все это влияет на время выполнения. Особенно сложно становится, когда на сервере выполняются одновременно и OLTP (оперативные), и OLAP (аналитические) задачи.
Найти точную причину долгого выполнения запроса гораздо сложнее, чем устранить ее.
В подобных случах я пытаюсь модифицировать запрос, меняя порядок следования условий (смеяться не надо - помогает), указав явно индексы для таблицы и анализируя, чем в данный момент занят сервер, есть-ли блокировки и т.д.
А может order by действительно занимает 20 секунд? В результирующем запросе сколько записей получается?

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33008708
L_Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Litus:-) Только сейчас заметил: хорошее название TAKING_BLOOD_DOSE
А может order by действительно занимает 20 секунд? В результирующем запросе сколько записей получается?

Posted via ActualForum NNTP Server 1.1

на сервере сейчас никто не работает кроме меня ((
в результате получаем 50000 записей.
TAKING_BLOOD - кроводача
TAKING_BLOOD_DOSE - доза крови :) которую берут у донора
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33008880
DrNull
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...в результате получаем 50000 записей.


Поясните плз., что вы хотите сделать с 50000 записей?!?
На клиента потащите?
Естественно серверу приходится писать эти 50000 в некую область, где потом сортировать. Это занимает некоторое время.
Я бы посмотрел на целесообразность такой большой выборки...
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33008947
L_Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
DrNullПоясните плз., что вы хотите сделать с 50000 записей?!?
На клиента потащите?
Естественно серверу приходится писать эти 50000 в некую область, где потом сортировать. Это занимает некоторое время.
Я бы посмотрел на целесообразность такой большой выборки...

компонент сервера приложений sybase jaguar запоминает эти индексы, и потом следующий запрос берет предположим 50 идентификаторов, по ним находит доп. характеристики и возвращает клиенту. Таким образом работает подсистема генерации списков. Далее клиент нажимает кнопку "след. блок" и смотрит следующую порцию данных. Я с вами соглашусь клиенту не нужны 50000 записей одновременно.

DrNullЕстественно серверу приходится писать эти 50000 в некую область, где потом сортировать. Это занимает некоторое время.
Я бы посмотрел на целесообразность такой большой выборки...

А нельзя ли узнать где эта область и увеличить ее размер? Это не tempdb?
...
Рейтинг: 0 / 0
ASE 12.5 Тормозит сортировка
    #33010292
DrNull
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
L_Leonid
компонент сервера приложений sybase jaguar запоминает эти индексы, и потом следующий запрос берет предположим 50 идентификаторов, по ним находит доп. характеристики и возвращает клиенту. Таким образом работает подсистема генерации списков. Далее клиент нажимает кнопку "след. блок" и смотрит следующую порцию данных. Я с вами соглашусь клиенту не нужны 50000 записей одновременно.

Зачем здесь сортировка? Чтобы набрать 50 первых TBD_ID? Или последних? :)
Если все равно берется 50 TBD_ID... не поискать ли возможность и запрашивать 50? К примеру зажавшись по TB_DATE...
Кроме того select distinct намекает, что TBD_ID могут быть не уникальными? Если это не так - они уникальны... я бы убрал distinct...

L_Leonid
А нельзя ли узнать где эта область и увеличить ее размер? Это не tempdb?
Вероятнее всего tempdb. Увеличение размера вряд ли поможет - математика сортировки никуда от этого не денется, быстрее перелопачивать (выкидывать дубликаты+сортировать) 50К записей не будет.
Необходимо на мой взгляд пересмотреть задачу и/или структуру БД (схему реляций), чтобы уменьшить размер выборки и/или уйти от сортировки с distinct...
...
Рейтинг: 0 / 0
16 сообщений из 16, страница 1 из 1
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / ASE 12.5 Тормозит сортировка
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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