|
|
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Помогите... Есть несколько таблиц и два запроса по ним. До настройки запросов и вычисления статистики по этим таблицам, запросы выполнялись в одной процедуре и каждый из них в среднем выполнялся 4,5 часа. После оценки статистики (10 %) для таблиц время выполнения каждого запроса сократилось на 1,5 часа, что +, но они "не хотят" выполняться в одной процедуре. Первый запрос выполняется,а второй "виснет" на неопределенное время и приходится его прерывать. Приходится делать перезагрузку перед выполнением каждого запроса :-(. Почему это происходит? Oracle8i Enterprise Edition Release 8.1.5.0.0 под NT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2003, 11:58 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Имел неприятный опыт работы с 815 на NT4sp6 Подними до 17 версии, иначе результаты экспериментов могут быть не чистыми ;_) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2003, 12:02 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Олег, а причем тут результаты экспериментов, если у меня запросы по отдельности выполняются, а если их последовательно включить в одну процедуру, то нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2003, 12:14 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Потому что чудес не бывает ;_) Проблема в чём? Они раньше выполнялись а после сбора статистики не стали? Что значит запрос "виснет?" Или статистика тут не причём? Если да то с такой ситуацией конкретно я не сталкивался, но я говорю о том что версия 815 на NT4 не надёжна. Я это видел своими глазами. Постоянно лезла end of file во время работы Вот потому и говорю что неплохобыло бы поднять версию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2003, 12:22 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Да нет, первый то запрос выполняется, а второй всю ночь проработал и не выполнился, я просто прервала выполнение, а вот если эти запросы запустить отдельно: первый выполняется, перезагружается комп, запускается второй и все прекрасно выполняется. Проблема в том, что второй запрос, записанный следом за первым в одну процедуру, не понятно как выполняется, т.е. никаких дурных сообщений нет, комп исправно тарахтит, но время, которое я жду до того как самой прервать выполнение процедуры >18 часов и результатов никаких , хотя если по отдельности запускать с перезагрузкой запросы, то каждый выполняется не >3 часов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2003, 13:09 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
запусти трассировку,и посмотри,что сессия творит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2003, 14:03 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Возможно сбор статистики привел к изменению плана второго запроса, и он стал "неудачным". Можно попробовать хинты, или попробовать разобраться в плане выполнения - чего там не хватает - может индексов, может для join начала работать сортировка и т.д. и т.п. Ну и в общем-то собранную статистику и удалить можно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2003, 14:09 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
С другой стороны, если по отдельности работают оба, то дело наверное не в плане... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2003, 14:10 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
А можно процедурку. Сдается мне что именно том что они как-то друг-другу жизнь портят за счет ухудшения I\O. И кстати размер табличек тоже пригодился бы. А так же Execution plan по каждому запросу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 13:39 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Insert into person.find_results (CL_ID, PER_NUM, DOC_NUM, REG_DATE, REG_STAT, REG_PRICH, ST_DATE, RES, PAR, FAMCH_ID, IMCH_ID, OTCH_ID, DRCH_ID, DOCCH_ID, RAJON_ID, UNKNOWN_ID, YAROSL_ID, WORK_ID, SMO) Select distinct R.ID, S.PER_NUM, S.DOC_NUM, S.REG_DATE, S.REG_STAT, S.REG_PRICH, S.ST_DATE, 1, 1, 'N', 'N', 'N', 'N', 'N', S.RAJON_ID, DECODE(MIN(H.ARCHIVE_ID),'0','N','Y'), DECODE(Y.YAR,0,'Y',1,'N','0'),--NVL(R.OBLS,'Y'),--DECODE(NVL(O.YAR,0),0,'Y','N'), DECODE(NVL(R.NO_FOND,'0'),'32-01321','N','03-00288','N','06-00194','N','09-00123','N','12-00508','N','15-00588','N','18-00138','N','21-00265','N','23-00571','N', '26-00375','N','29-00144','N','32-01238','N','34-00224','N','37-00276','N','40-07987','N','43-01476','N','46-01002','N','50-01434','N','68-03991','N','Y'), R.SMO from person.smo_report1 R, person.history H,person.status_new S, person.smo_yarosl_obl Y where R.birthday=H.birthday and R.lastname=H.lastname and R.midname=H.midname and R.firstname=H.firstname and replace(R.paper_sernum,' ')=replace(H.paper_sernum,' ') and H.person_id=S.per_num and NVL(R.obls,'пустая область')=Y.obls group by R.ID,R.NO_FOND,R.SMO,S.PER_NUM,S.DOC_NUM,S.REG_DATE,S.REG_STAT,S.REG_PRICH,S.ST_DATE,S.RAJON_ID,Y.YAR; COMMIT; dbms_output.put_line('After PAR=1 :' || to_char(sysdate(), 'DD-MON-YY HH24:MI:SS')); end; Процедура для запроса №2 (d_update_uvd date) as id_first number; id_last number; id_avg number; minn number; maxx number; /*d_update_uvd date - Дата обновления УВД, имеет формат типа "01-NOV-02"*/ begin dbms_output.put_line('Begin :' || to_char(sysdate(), 'DD-MON-YY HH24:MI:SS')); /*PAR=1 (пустое отчество) and PAR=4 (без отчества)*/ Insert into person.find_results (CL_ID, PER_NUM, DOC_NUM, REG_DATE, REG_STAT, REG_PRICH, ST_DATE, RES, PAR, FAMCH_ID, IMCH_ID, OTCH_ID, DRCH_ID, DOCCH_ID, RAJON_ID, UNKNOWN_ID, YAROSL_ID, WORK_ID, SMO) Select distinct R.ID,---- S.PER_NUM, S.DOC_NUM, S.REG_DATE, S.REG_STAT, S.REG_PRICH, S.ST_DATE, 1, DECODE(min(DECODE(NVL(R.MIDNAME,'1'),'1',0,1)+DECODE(NVL(H.MIDNAME,'1'),'1',0,1)),0,1,4), 'N', 'N', 'N', 'N', 'N', S.RAJON_ID, DECODE(MIN(H.ARCHIVE_ID),'0','N','Y'), DECODE(Y.YAR,0,'Y',1,'N','0'), DECODE(NVL(R.NO_FOND,'0'),'32-01321','N','03-00288','N','06-00194','N','09-00123','N','12-00508','N','15-00588','N','18-00138','N','21-00265','N','23-00571','N', '26-00375','N','29-00144','N','32-01238','N','34-00224','N','37-00276','N','40-07987','N','43-01476','N','46-01002','N','50-01434','N','68-03991','N','Y'), R.SMO from person.smo_report1 R, person.history H,person.status_new S,person.for_find_new_2 FF, person.smo_yarosl_obl Y where R.birthday=H.birthday and R.lastname=H.lastname and --R.midname=H.midname and R.firstname=H.firstname and replace(R.paper_sernum,' ')=replace(H.paper_sernum,' ') and R.id=FF.c and H.person_id=S.per_num and NVL(R.obls,'пустая область')=Y.obls group by R.ID,R.NO_FOND,R.SMO,S.PER_NUM,S.DOC_NUM,S.REG_DATE,S.REG_STAT,S.REG_PRICH,S.ST_DATE,S.RAJON_ID,Y.YAR; COMMIT; dbms_output.put_line('Update PAR=1,4 '|| to_char(sysdate(), 'DD-MON-YY HH24:MI:SS')); Update person.find_results set otch_id=null where par=4; COMMIT; dbms_output.put_line('Update PAR=1,4 '|| to_char(sysdate(), 'DD-MON-YY HH24:MI:SS')); end; Результаты explain plan: Для первого запроса: ID PARENT_ID Query Plan 0 INSERT STATEMENT Cost=853786 1 0 SORT UNIQUE Cost=853786 2 1 SORT GROUP BY Cost=853786 3 2 HASH JOIN Cost=810262 4 3 INDEX FAST FULL SCAN OBLL Cost=1 5 3 NESTED LOOPS Cost=809943 6 5 MERGE JOIN Cost=809939 7 6 SORT JOIN Cost=282222 8 7 TABLE ACCESS FULL SMO_REPORT1 Cost=6561 9 6 SORT JOIN Cost=527717 10 9 TABLE ACCESS FULL HISTORY Cost=28354 11 5 TABLE ACCESS BY INDEX ROWID STATUS_NEW Cost=4 12 11 INDEX RANGE SCAN PER_NUM Cost=3 13 rows selected. Для второго: ID PARENT_ID Query Plan 0 INSERT STATEMENT Cost=984402 1 0 SORT UNIQUE Cost=984402 2 1 SORT GROUP BY Cost=984402 3 2 NESTED LOOPS Cost=892392 4 3 NESTED LOOPS Cost=892364 5 4 NESTED LOOPS Cost=892362 6 5 MERGE JOIN Cost=826016 7 6 SORT JOIN Cost=298299 8 7 TABLE ACCESS FULL SMO_REPORT1 Cost=6561 9 6 SORT JOIN Cost=527717 10 9 TABLE ACCESS FULL HISTORY Cost=28354 11 5 VIEW FOR_FIND_NEW_2 Cost=66347 12 11 MINUS Cost= 13 12 SORT UNIQUE Cost=38968 14 13 TABLE ACCESS FULL SMO_REPORT1 Cost=6561 15 12 SORT UNIQUE Cost=27379 16 15 TABLE ACCESS FULL FIND_RESULTS Cost=2967 17 4 INDEX FAST FULL SCAN OBLL Cost=1 18 3 TABLE ACCESS BY INDEX ROWID STATUS_NEW Cost=4 19 18 INDEX RANGE SCAN PER_NUM Cost=3 20 rows selected. крупные табл: SMO_REPORT1 - 1 300 000 строк HISTORY - 3 000 000 STATUS_NEW - 1 300 000 person.for_find_new_2 - представление smo_report1 minus find_results ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 15:23 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Приблизительный план такой у вас в запросе фулсканов как грязи и в целях оптимизации ORACLE любит такие таблички оставлять в пямяти и соответственно в дальнейшем для сортировок он начинает использоавть диск. Диск это всегда тормоз. Почему он не выгружает ее из памяти при начале выполнения второго запроса не знаю. Главный рецепт. Разбейте это всё на более мелкие запросы. Тут правильно говорят "JOIN больше 3 таблиц, значит ошибка в програмной логике" У меня таблички по нескольку миллионов строк и когда я их объединяю зачастую пройтись курсором оказывается быстрее чем делать такое сверх_объединение. Второстепнный рецепт. Постройте индексы чтобы не было фулсканов. И хинт RULE Третьестепенный рецепт увелите SORT_AREA_SIZE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 15:45 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
2 Eter Panji >и в целях оптимизации ORACLE любит такие таблички оставлять >в пямяти и соответственно в дальнейшем для сортировок он начинает >использоавть диск. Это не совсем так (или точнее сказать - совсем не так :-). Оракл кеширует блоки полученные при FTS только в случае незаполненного кеша (после старта экземляра), или если таблица модифицирована с ключевым словом cache (но должна быть меньше чем размер буфферного кеша) или если конфигурирован keep pool для этой таблицы. Сортировки вообще отдельная песня. >Главный рецепт. Разбейте это всё на более мелкие запросы. Тут правильно >говорят "JOIN больше 3 таблиц, значит ошибка в програмной логике" А это откуда??? Важно не сколько соединять, а как. >Второстепнный рецепт. Постройте индексы чтобы не было фулсканов. И хинт >RULE > Конечно cbo оптимизатор в версии 8.1.5 еще не очень, но возвращаться к rule тоже не следует, т.к. не все методы доступа (например hash join) доступны для rule оптимизатора. >Третьестепенный рецепт увелите SORT_AREA_SIZE он там очевидно и так большой, если оптимизатор выбирает sort join. 2 Kate_new Оптимизируйте запросы прежде всего запросы с точки зрения использования индексов. Из приведенной информации трудно понять насколько селективны условия в where. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 16:41 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
для .dba Запросы настроены оптимально с точки зрения индексов - работа была проведена - full scan таблицы работает быстрее, чем полное сканирование индекса. До этого выполнялось медленне, но все вместе, а теперь быстро, но по отдельности :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 16:49 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
A nel'zya li izbegat' MERGE JOIN ? Tormoza.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 16:58 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
2 .dba >Это не совсем так (или точнее сказать - совсем не так :-). Оракл кеширует >блоки полученные при FTS только в случае незаполненного кеша (после >старта экземляра), или если таблица модифицирована с ключевым словом >cache (но должна быть меньше чем размер буфферного кеша) или если >конфигурирован keep pool для этой таблицы. Но в данном случае мы и имеем ту песню, поскольку запрос выполнятеся "после рестарта базы" С замечанием относительно числа, относительно согласен. Однако 4 таблицы по 30000000 строк объединных по первичным клюячам всё равно плохо. Оптимизатор ORACLE это вообще отдельная песня. Я ему очень сильно не доверяю. За счет хинтов обычно можно выиграть до 10%. ORACLE 8.1.7 Может в 9 и полегчало... RULE хороший хинт, если не хочешь вводить тонкую настройку. А HASH_JOIN это редко эффективно. См. был спор неделю назад. >он там очевидно и так большой, если оптимизатор выбирает sort join. согласен 2.Kate_new В принципе можно попробовать NO_CACHE однако сам такой хинт не использовал, за эффективность не поручусь. А почему в person.smo_report1 нельзя хранить person_id и делать jOIN через него. Будет быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 17:02 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
в этом то и заковырка, что history и smo_report1 поступают из двух разных источников и их сравнивают, так что смысл в том, чтобы каждой записи из smo_report1 сопоставить из history и проставить person_id + еще ...... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 17:11 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
2 Oracle X-pert а причем тут Merge Join?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 17:16 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Я так понимаю что у тебя строчки не отсеиваются на объединении со справочниками. Если нет, принуди сначала объединяться 2 большие таблицы используя индексы. А маленькую PERSON_STATUS_NEW наоборот загони в КЕШ Кстати индексы тоже неплохо бы проанализировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 17:37 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
f ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 17:38 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
так вроде так и делается, сначала объединяются 2 большие таблицы, ранее с индексами было , но так медленнее, так как полное сканирование индекса медленнее, чем полное сканирование таблицы status_new не маленькая 1 300 000 строк индексы анализируются вместе с таблицами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 17:42 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
А какие были индексы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 17:46 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
> но так медленнее, так как полное сканирование индекса медленнее, чем > полное сканирование таблицы Зато память так не расходуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 17:49 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Dorogoi v realizacii i medlennyi v ispolnenii algorithm. Bez osoboi nadobnosti ego ne ispol'zuyt. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 17:54 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Еще могу всётаки предложить создать временную таблиц в которую сначала выгрузить весь person.smo_report1 потом проставить дополнительное поле person_id Затем проставить признак области а уже затем сделать JOIN по двум оставшимся таблицам. Какую таблицу временную или обычную не знаю. Наверное, для экономии кеша постоянную. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 17:59 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32162971&tid=1990469]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
177ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 214ms |
| total: | 504ms |

| 0 / 0 |
