Тормозит поиск по текстам операций
|
Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
egor_spb Участник - экстремал
Вступление в Клуб: 28.09.2007
|
Чт Июл 16, 2015 15:19  Тормозит поиск по текстам операций |
|
Полезность: Нет оценки
|
Странно, в целом база работает нормально, но стало совершенно нереально что-то искать в текстах операций.
Как только делаешь запрос типа:
Код: |
SELECT c.NAME class_name, sr.*
FROM ((SELECT m.class_id class_id, '05METHOD_SRC' TYPE, m.NAME NAME,
m.ID ID, s.TYPE short_name, s.text str_found,
s.line LOCATION
FROM ibs.sources s, ibs.methods m
WHERE m.ID = s.NAME
AND UPPER (s.text) LIKE '%Зедсьточтоищем%' ESCAPE '\')) sr,
ibs.classes c
WHERE sr.class_id = c.ID
ORDER BY class_name, sr.NAME, sr.short_name, LOCATION
|
так ждешь по 5-10 мин.
Статистика собирается регулярно. Индексы здесь вроде особо не причем.
План:
Код: |
Plan
SELECT STATEMENT ALL_ROWSCost: 31,671 Bytes: 62,083,371 Cardinality: 385,611
9 SORT ORDER BY Cost: 31,671 Bytes: 62,083,371 Cardinality: 385,611
8 FILTER
7 HASH JOIN Cost: 17,956 Bytes: 62,083,371 Cardinality: 385,611
1 TABLE ACCESS FULL TABLE IBS.CLASSES Cost: 105 Bytes: 545,844 Cardinality: 10,497
6 MERGE JOIN Cost: 17,849 Bytes: 42,031,381 Cardinality: 385,609
3 TABLE ACCESS BY INDEX ROWID TABLE IBS.SOURCES Cost: 16,530 Bytes: 21,979,713 Cardinality: 385,609
2 INDEX FULL SCAN INDEX IBS.IDX_SOURCES_NAME Cost: 3,371 Cardinality: 7,712,174
5 SORT JOIN Cost: 1,318 Bytes: 2,245,464 Cardinality: 43,182
4 TABLE ACCESS FULL TABLE IBS.METHODS Cost: 760 Bytes: 2,245,464 Cardinality: 43,182
|
Не могу понять, почему раньше меньше минуты все искалось целиком по всему словарю.... |
|
 |
Alkov Профи
Вступление в Клуб: 23.09.2010
|
Пн Июл 20, 2015 03:05   |
|
Полезность: Нет оценки
|
Кэш для словаря уменьшили или новая версия- там объём словаря в 2 раза вырос ... |
|
 |
Damir Участник - экстремал
Вступление в Клуб: 29.03.2013
|
Ср Июл 22, 2015 07:39  Re: Тормозит поиск по текстам операций |
|
Полезность: Нет оценки
|
egor_spb пишет: |
Не могу понять, почему раньше меньше минуты все искалось целиком по всему словарю.... |
так попробуй (хинт влепил)
Код: |
SELECT c.NAME class_name, sr.*
FROM ((SELECT --+cardinality(s 1)
m.class_id class_id, '05METHOD_SRC' TYPE, m.NAME NAME,
m.ID ID, s.TYPE short_name, s.text str_found,
s.line LOCATION
FROM comp.sources s, comp.methods m
WHERE m.ID = s.NAME
AND UPPER (s.text) LIKE '%Зедсьточтоищем%' ESCAPE '\')) sr,
comp.classes c
WHERE sr.class_id = c.ID
ORDER BY class_name, sr.NAME, sr.short_name, LOCATION |
|
|
 |
egor_spb Участник - экстремал
Вступление в Клуб: 28.09.2007
|
Ср Июл 22, 2015 11:16  Re: Тормозит поиск по текстам операций |
|
Полезность: Нет оценки
|
Damir пишет: | egor_spb пишет: |
Не могу понять, почему раньше меньше минуты все искалось целиком по всему словарю.... |
так попробуй (хинт влепил)
Код: |
SELECT c.NAME class_name, sr.*
FROM ((SELECT --+cardinality(s 1)
m.class_id class_id, '05METHOD_SRC' TYPE, m.NAME NAME,
m.ID ID, s.TYPE short_name, s.text str_found,
s.line LOCATION
FROM comp.sources s, comp.methods m
WHERE m.ID = s.NAME
AND UPPER (s.text) LIKE '%Зедсьточтоищем%' ESCAPE '\')) sr,
comp.classes c
WHERE sr.class_id = c.ID
ORDER BY class_name, sr.NAME, sr.short_name, LOCATION |
|
Попробовал с хинтом, план изменился:
Код: |
Plan
SELECT STATEMENT ALL_ROWSCost: 17,851 Bytes: 161 Cardinality: 1
11 SORT ORDER BY Cost: 17,851 Bytes: 161 Cardinality: 1
10 FILTER
9 NESTED LOOPS
7 NESTED LOOPS Cost: 17,850 Bytes: 161 Cardinality: 1
5 MERGE JOIN Cost: 17,849 Bytes: 109 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE IBS.SOURCES Cost: 16,530 Bytes: 57 Cardinality: 1
1 INDEX FULL SCAN INDEX IBS.IDX_SOURCES_NAME Cost: 3,371 Cardinality: 7,712,174
4 SORT JOIN Cost: 1,318 Bytes: 2,245,464 Cardinality: 43,182
3 TABLE ACCESS FULL TABLE IBS.METHODS Cost: 760 Bytes: 2,245,464 Cardinality: 43,182
6 INDEX UNIQUE SCAN INDEX (UNIQUE) IBS.PK_CLASSES_ID Cost: 1 Cardinality: 1
8 TABLE ACCESS BY INDEX ROWID TABLE IBS.CLASSES Cost: 1 Bytes: 52 Cardinality: 1
|
А время выполнения - нет. Все равно около 10 мин. |
|
 |
Damir Участник - экстремал
Вступление в Клуб: 29.03.2013
|
Ср Июл 22, 2015 14:08  Re: Тормозит поиск по текстам операций |
|
Полезность: Нет оценки
|
egor_spb пишет: |
............
Попробовал с хинтом, план изменился:
.......
|
куда-то он нее в ту сторону у вас изменился.
1) сколько работает упрощенный запрос (если те же 10 мин - планы ковырять бесполезно):
Код: | SELECT
s.NAME ID, s.TYPE short_name, s.text str_found,
s.line LOCATION
FROM sources s
WHERE UPPER(s.text) LIKE '%Зедсьточтоищем%' ESCAPE '\'
|
2) если запрос в п.1. отрабатывает быстро - можно еще попробовать подкрутить план - тут добавил 'плюсики' (с хинтом-без хинта - по вкусу)
Код: | SELECT c.NAME class_name, sr.*
FROM ((SELECT --+cardinality(s 1)
m.class_id class_id, '05METHOD_SRC' TYPE, m.NAME NAME,
m.ID ID, s.TYPE short_name, s.text str_found,
s.line LOCATION
FROM sources s, methods m
WHERE m.ID (+)= s.NAME
AND UPPER (s.text) LIKE '%Зедсьточтоищем%' ESCAPE '\')) sr,
classes c
WHERE sr.class_id = c.ID (+)
ORDER BY class_name, sr.NAME, sr.short_name, LOCATION
|
3) если в п.1.1 запрос работает быстро, в п.2. медленно - хинтовать до посинения  |
|
 |
egor_spb Участник - экстремал
Вступление в Клуб: 28.09.2007
|
Ср Июл 22, 2015 17:47  Re: Тормозит поиск по текстам операций |
|
Полезность: Нет оценки
|
Damir пишет: | egor_spb пишет: |
............
Попробовал с хинтом, план изменился:
.......
|
куда-то он нее в ту сторону у вас изменился.
1) сколько работает упрощенный запрос (если те же 10 мин - планы ковырять бесполезно):
Код: | SELECT
s.NAME ID, s.TYPE short_name, s.text str_found,
s.line LOCATION
FROM sources s
WHERE UPPER(s.text) LIKE '%Зедсьточтоищем%' ESCAPE '\'
|
2) если запрос в п.1. отрабатывает быстро - можно еще попробовать подкрутить план - тут добавил 'плюсики' (с хинтом-без хинта - по вкусу)
Код: | SELECT c.NAME class_name, sr.*
FROM ((SELECT --+cardinality(s 1)
m.class_id class_id, '05METHOD_SRC' TYPE, m.NAME NAME,
m.ID ID, s.TYPE short_name, s.text str_found,
s.line LOCATION
FROM sources s, methods m
WHERE m.ID (+)= s.NAME
AND UPPER (s.text) LIKE '%Зедсьточтоищем%' ESCAPE '\')) sr,
classes c
WHERE sr.class_id = c.ID (+)
ORDER BY class_name, sr.NAME, sr.short_name, LOCATION
|
3) если в п.1.1 запрос работает быстро, в п.2. медленно - хинтовать до посинения  |
Запрос из п.1 выполняется 8 секунд, а не 10 мин.
Запрос из п.2 может выполняться несколько быстрее - за 2-3 мин, видимо, влияет попадание в кэш, надо трейс посмотреть. |
|
 |
Damir Участник - экстремал
Вступление в Клуб: 29.03.2013
|
Ср Июл 22, 2015 18:43  Re: Тормозит поиск по текстам операций |
|
Полезность: Нет оценки
|
egor_spb пишет: | ....
Запрос из п.1 выполняется 8 секунд, а не 10 мин.
Запрос из п.2 может выполняться несколько быстрее - за 2-3 мин, . |
Запрос из п.1 - делает основную работу, перелопачивает основной объем данных. И уже к результату джоинятся 'справочники'. Следовательно, время его выполнения - это минимальное время выполнения первоначального запроса при хорошем плане - быстрее не получится.
Еще момент - за 8 секунд все записи отфетчены (получены на клиента) или только первые 20-30 в Тоаде появились?
Сначала оракл делает выборку данных, потом сортирует и только потом выдает клиенту. Замерять надо время выполнения запроса 1 с получением всех записей на клиента.
2-3 минуты вместо 10 - уже лучше.... возможно - предел, надо план крутить. Если надо, конечно.....
PS: индекс IBS.IDX_SOURCES_NAME сами создавали? на нашей схеме его нет, да и не нужен он по-моему. |
|
 |
timochev Эксперт
Вступление в Клуб: 02.07.2007
|
Чт Июл 23, 2015 08:50  Re: Тормозит поиск по текстам операций |
|
Полезность: Нет оценки
|
Damir пишет: | PS: индекс IBS.IDX_SOURCES_NAME сами создавали? на нашей схеме его нет, да и не нужен он по-моему. |
О каких версиях ТЯ идет речь? На 7.4.2.3 индекс должен быть. Подтверждением тому его наличие в файле 7_4_2_3_sysobj.txt
У нас с какого-то момента тоже наблюдается описанная проблема. При отсутствии в кэше необходимых данных поиск идет долго. Это заметно при поиске на тестовой базе после ее перезапуска, либо при поиске по текстам на рабочей базе. Сейчас попробовал при пустом кэше на тесте - 251 сек. Повторный поиск - 27 сек. |
|
 |
egor_spb Участник - экстремал
Вступление в Клуб: 28.09.2007
|
Чт Июл 23, 2015 09:13  Re: Тормозит поиск по текстам операций |
|
Полезность: Нет оценки
|
Damir пишет: | egor_spb пишет: | ....
Запрос из п.1 выполняется 8 секунд, а не 10 мин.
Запрос из п.2 может выполняться несколько быстрее - за 2-3 мин, . |
Запрос из п.1 - делает основную работу, перелопачивает основной объем данных. И уже к результату джоинятся 'справочники'. Следовательно, время его выполнения - это минимальное время выполнения первоначального запроса при хорошем плане - быстрее не получится.
Еще момент - за 8 секунд все записи отфетчены (получены на клиента) или только первые 20-30 в Тоаде появились?
Сначала оракл делает выборку данных, потом сортирует и только потом выдает клиенту. Замерять надо время выполнения запроса 1 с получением всех записей на клиента.
2-3 минуты вместо 10 - уже лучше.... возможно - предел, надо план крутить. Если надо, конечно.....
PS: индекс IBS.IDX_SOURCES_NAME сами создавали? на нашей схеме его нет, да и не нужен он по-моему. |
индекс IBS.IDX_SOURCES_NAME я не создавал, откуда взялся - не могу вспомнить. Попробую дропнуть на тестовой схеме и посмотреть.
Проверил - время запросов из п. 1 и 2 практически сравнялось!
Попробую еще перестартовать тестовую базу, чтобы из кэш очистился. Но скорость поиска реально радует, совсем как раньше!
P.S. Индекс появился в версии ядра выше 7.4.0.1. Тормозить, кажется, примерно в это же время поиск стал, с конца прошлого года, точнее уже не помню.
План запроса теперь такой:
Код: |
Plan
SELECT STATEMENT ALL_ROWSCost: 34,071 Bytes: 62,083,371 Cardinality: 385,611
7 SORT ORDER BY Cost: 34,071 Bytes: 62,083,371 Cardinality: 385,611
6 FILTER
5 HASH JOIN Cost: 20,357 Bytes: 62,083,371 Cardinality: 385,611
1 TABLE ACCESS FULL TABLE IBS.CLASSES Cost: 105 Bytes: 545,844 Cardinality: 10,497
4 HASH JOIN Cost: 20,249 Bytes: 42,031,381 Cardinality: 385,609
2 TABLE ACCESS FULL TABLE IBS.METHODS Cost: 760 Bytes: 2,245,464 Cardinality: 43,182
3 TABLE ACCESS FULL TABLE IBS.SOURCES Cost: 18,095 Bytes: 21,979,713 Cardinality: 385,609
|
|
|
 |
prankster Профи
Вступление в Клуб: 22.08.2014
|
Чт Июл 23, 2015 09:55  Re: Тормозит поиск по текстам операций |
|
Полезность: Нет оценки
|
egor_spb пишет: |
Попробую еще перестартовать тестовую базу, чтобы из кэш очистился. |
Зачем уж перестартовать, чистите кэш
alter system flsuh buffer_cache |
|
 |
egor_spb Участник - экстремал
Вступление в Клуб: 28.09.2007
|
Чт Июл 23, 2015 10:01   |
|
Полезность: Нет оценки
|
Проверил на тестовой базе после перезапуска.
Время выполнения запроса - 4 секунды!
AutoTrace:
bytes received via SQL*Net from client 1956
bytes sent via SQL*Net to client 63519
consistent gets 70413
db block gets 2
physical reads 69669
recursive calls 334
redo size 0
sorts (disk) 0
sorts (memory) 90
SQL*Net roundtrips to/from client 4
Может ядерщикам ЦФТ написать вопрос, чтобы они проверили необходимость этого индекса? |
|
 |
|
|
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
|
|