CftClub.ru
Клуб специалистов ЦФТ-Банк

Тормозит поиск по текстам операций

 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA
Предыдущая тема :: Следующая тема  
Автор Сообщение
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. медленно - хинтовать до посинения Smile
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. медленно - хинтовать до посинения Smile


Запрос из п.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 практически сравнялось!
Попробую еще перестартовать тестовую базу, чтобы из кэш очистился. Но скорость поиска реально радует, совсем как раньше! Exclamation
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

Может ядерщикам ЦФТ написать вопрос, чтобы они проверили необходимость этого индекса?
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Рейтинг@Mail.ru