|
|
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#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 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
2 Oracle X-pert Это смотря какими ресурсами мы обладаем. Вполне возможно еще парочку гигов оперативки и жизнь будет казаться сахаром. А если памяти нет, но есть диск, как жить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 18:04 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Poetomu i predlagay Merge perevesti v Nested! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 18:18 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Da, i pochemu " replace(R.paper_sernum,' ')=replace(H.paper_sernum,' ')" NULL = NULL, chto li? Zachem? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 18:21 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Vo 2 zaproce Merge idet na 3 mln rows FULL SCAN { History } ( v 1-m : SMO_REPORT1 ). Na Vashem NT , scoree vsego, net takix resources ( RAM ~ 4G na Sorting..) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 18:26 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
>Da, i pochemu " replace(R.paper_sernum,' ')=replace(H.paper_sernum,' ')" > NULL = NULL, chto li? Zachem? Я думаю чтобы "апр апап 78 7"="а прап ап7 87"="апрапап787" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 18:32 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
2 Oracle X-pert Ресурсы есть по отдельности то запросы выполнялись. Однако это на грани. Меня удивляет почему ORACLE все ресурсы занятые первым запросом не сбрасывает. Когда начинает выполнение второго. Может быть вы знаете нельзя ли очистить принудительно кеш. Врать не буду, но может это делает check_point ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 18:35 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
привет 2 Eter Panji индекс в smo_report1 по birthday,lastname,midname,firstname до этого было тоже только по history - работало еще медленнее в проставление person_id и заключается основная задача, которая и отнимает большую часть времени все, теперь вообще похожие запросы перестали выполняться так сказать ПОМОГИТЕ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 09:59 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Если быстро то убей статистику раньше же тебя всё устраивало. Код: plaintext или Код: plaintext а затем давай разбираться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 10:10 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Во первых всё таки расскажи что у тебя за машина и Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 10:22 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
пошла убивать :-)) на что ты меня толкаешь, жуть :-)) ох, не смешно :-( а можно через analyze table ... delete statistic? о результатах напишу часа через 3, а то и 4 спасибо за помощь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 10:23 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
я согласен, что она занимает большую часть времени, но если ее разнести от других задач, тогда в каждый момент времени потребности в ресурсах будут меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 10:25 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Microsoft (R) Windows NT (TM) Server Version 4.0 (Build 1381: Service Pack 6) x86 Multiprocessor Free Registered Owner: tfoms, tfoms Product Number: 51222-270-1288493-21679 ---------------------------------------------------------------------- System Report ---------------------------------------------------------------------- System: AT/AT COMPATIBLE Hardware Abstraction Layer: MPS 1.4 - APIC platform BIOS Date: 01/15/99 BIOS Version: Processor list: 0: x86 Family 6 Model 5 Stepping 2 GenuineIntel ~400 Mhz 1: x86 Family 6 Model 5 Stepping 2 GenuineIntel ~400 Mhz ---------------------------------------------------------------------- Video Display Report ---------------------------------------------------------------------- BIOS Date: 05/18/99 BIOS Version: S3 86C362 Trio3D2X Video BIOS. Version 2.0C.10 Adapter: Setting: 800 x 600 x 24 Bits/Pixel 85 Hz Type: s3mini compatible display adapter String: Memory: 4 MB Chip Type: S3 Trio3D/2X DAC Type: S3 SDAC Driver: Vendor: File(s): s3mini.sys, s3t3d2x.dll Version: , 4.0.0 Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production PL/SQL Release 8.1.5.0.0 - Production CORE Version 8.1.5.0.0 - Production TNS for 32-bit Windows: Version 8.1.5.0.0 - Production NLSRTL Version 3.4.0.0.0 - Production DB Name DATA Global Name ORACLE DB Version Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production Host Name TFOMS Instance Name data Instance Start Time 19-MAY-03 Restricted Mode NO Archive Log Mode NOARCHIVELOG Жуть не знаю как вывести инфу по другому NUM NAME TYPE VALUE ISDEFAULT ISSES ISSYS_MOD ISMODIFIED ISADJ DESCRIPTION --------- ---------------------------------------------------------------- --------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------- ----- --------- ---------- ----- ---------------------------------------------------------------- 22 shared_pool_size 2 15728640 FALSE FALSE FALSE FALSE FALSE size in bytes of shared pool 25 shared_pool_reserved_size 2 786432 TRUE FALSE FALSE FALSE FALSE size in bytes of reserved area of shared pool 27 large_pool_size 2 0 TRUE FALSE FALSE FALSE FALSE size in bytes of the large allocation pool 29 java_pool_size 2 20971520 FALSE FALSE FALSE FALSE FALSE size in bytes of the Java pool 31 java_max_sessionspace_size 3 0 TRUE FALSE FALSE FALSE FALSE max allowed size in bytes of a Java sessionspace 119 db_block_buffers 3 40972 FALSE FALSE FALSE FALSE FALSE Number of database blocks cached in memory 120 buffer_pool_keep 2 TRUE FALSE FALSE FALSE FALSE Number of database blocks/latches in keep buffer pool 134 db_block_size 3 2048 FALSE FALSE FALSE FALSE FALSE Size of database block in bytes 304 sort_area_size 3 65536 TRUE TRUE DEFERRED FALSE FALSE size of in-memory sort work area 305 sort_area_retained_size 3 0 TRUE TRUE DEFERRED FALSE FALSE size of in-memory sort work area retained between fetch calls 320 always_anti_join 2 NESTED_LOOPS TRUE FALSE FALSE FALSE FALSE always use this anti-join when possible 401 create_bitmap_area_size 3 8388608 TRUE FALSE FALSE FALSE FALSE size of create bitmap buffer for bitmap index 402 bitmap_merge_area_size 3 1048576 TRUE FALSE FALSE FALSE FALSE maximum memory allow for BITMAP MERGE 412 parallel_execution_message_size 3 2148 TRUE FALSE FALSE FALSE FALSE message buffer size for parallel execution 421 hash_area_size 3 131072 TRUE TRUE FALSE FALSE FALSE size of in-memory hash work area 426 max_dump_file_size 3 10240 FALSE FALSE FALSE FALSE FALSE Maximum size (blocks) of dump file 433 oracle_trace_collection_size 3 5242880 TRUE FALSE FALSE FALSE FALSE Oracle TRACE collection file max. size 436 object_cache_optimal_size 3 102400 TRUE TRUE DEFERRED FALSE FALSE optimal size of the user session's object cache in bytes 18 rows selected. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 10:34 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Я не нашел количество физической памяти, но буфферный кеш у тебя определенно маленький и sort_area_size тоже. Если у тебя хотя бы 512 м оперативки имеет смысл увеличить и то и другое. Похоже у тебя все сортировки проходят на диске. Если сможешь выбить себе 1G оперативки то ты свою машину не узнаешь кстати у тебя двухпроцессорная система скажи пожалуйста Код: plaintext 1. 2. 3. 4. 5. 6. 7. И что еще крутится на серваке ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 11:00 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
NUM NAME TYPE VALUE ISDEFAULT ISSES ISSYS_MOD ISMODIFIED ISADJ DESCRIPTION --------- ---------------------------------------------------------------- --------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------- ----- --------- ---------- ----- ---------------------------------------------------------------- 161 compatible 2 8.1.0 FALSE FALSE FALSE FALSE FALSE Database will be completely compatible with this software versio 146 db_writer_processes 3 1 TRUE FALSE FALSE FALSE FALSE number of background database writer processes to start 396 optimizer_percent_parallel 3 0 TRUE TRUE FALSE FALSE FALSE optimizer percent parallel 341 parallel_adaptive_multi_user 1 FALSE TRUE FALSE IMMEDIATE FALSE FALSE enable adaptive setting of degree for multiple user streams 343 parallel_automatic_tuning 1 FALSE TRUE FALSE FALSE FALSE FALSE enable intelligent defaults for parallel execution parameters 333 parallel_broadcast_enabled 1 FALSE TRUE TRUE FALSE FALSE FALSE enable broadcasting of small inputs to hash and sort merge joins 412 parallel_execution_message_size 3 2148 TRUE FALSE FALSE FALSE FALSE message buffer size for parallel execution 409 parallel_instance_group 2 TRUE TRUE IMMEDIATE FALSE FALSE instance group to use for all parallel operations 405 parallel_max_servers 3 5 FALSE FALSE FALSE FALSE FALSE maximum parallel query servers per instance 398 parallel_min_percent 3 0 TRUE TRUE FALSE FALSE FALSE minimum percent of threads required for parallel query 404 parallel_min_servers 3 0 TRUE FALSE FALSE FALSE FALSE minimum parallel query servers per instance 198 parallel_server 1 FALSE TRUE FALSE FALSE FALSE FALSE if TRUE startup in parallel server mode 199 parallel_server_instances 3 1 TRUE FALSE FALSE FALSE FALSE number of instances to use for sizing OPS SGA structures 342 parallel_threads_per_cpu 3 2 TRUE FALSE IMMEDIATE FALSE FALSE number of parallel execution threads per CPU 230 row_locking 2 always TRUE FALSE FALSE FALSE FALSE row-locking 15 rows selected. Disk Drives Report ---------------------------------------------------------------------- C:\ (Local - FAT) SYSTEM Total: 1 052 064 KB, Free: 162 368 KB Serial Number: 3633 - 13E0 Bytes per cluster: 512 Sectors per cluster: 64 Filename length: 255 D:\ (Local - NTFS) First Total: 3 349 520 KB, Free: 812 500 KB Serial Number: B8E5 - F3DC Bytes per cluster: 512 Sectors per cluster: 8 Filename length: 255 E:\ (Local - NTFS) Second Total: 4 401 776 KB, Free: 651 492 KB Serial Number: DCEA - FE37 Bytes per cluster: 512 Sectors per cluster: 8 Filename length: 255 H:\ (Removable - FAT) ZIP-100 Total: 98 078 KB, Free: 71 860 KB Serial Number: 34D8 - 1C07 Bytes per cluster: 512 Sectors per cluster: 4 Filename length: 255 M:\ (Local - NTFS) Big Total: 20 081 216 KB, Free: 4 497 732 KB Serial Number: 2CCA - 69C1 Bytes per cluster: 512 Sectors per cluster: 8 Filename length: 255 Memory Report ---------------------------------------------------------------------- Handles: 3 445 Threads: 182 Processes: 26 Physical Memory (K) Total: 523 696 Available: 308 020 File Cache: 19 380 Kernel Memory (K) Total: 15 668 Paged: 11 520 Nonpaged: 4 148 Commit Charge (K) Total: 214 432 Limit: 2 905 820 Peak: 251 552 Pagefile Space (K) Total: 2 410 496 Total in use: 1 408 Peak: 1 432 C:\pagefile.sys Total: 313 344 Total in use: 724 Peak: 748 M:\pagefile.sys Total: 2 097 152 Total in use: 684 Peak: 684 Это то? У меня изолированный комп, я не имею права подключать его к сети, поэтому процессы чаще всего не запускаются параллельно Оперативная 512 или как она пишет 511 Мб, а как увеличить sort_area_size(и что это такое :-( ) и б.кэш? Извини за такие вопросы :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 12:30 |
|
||
|
Анализ таблиц и выполнение запросов
|
|||
|---|---|---|---|
|
#18+
У тебя отключена параллельность, это значит что запросы типа твоего приходится обрабатывать одному процессору. Я ни разу не настраивал параллельность, поэтому как настроить чтобы она использовалась спроси кого-нибудь другого или почитай. Относительно памяти это делается через ORACLE DBA STUDIO Открываешь инстанс\Database закладка Memory там найдешь войти надо под sys Возможно захочет перезагрузиться. В буфферном кеше хранятся данные полученные в результате считывания с диска SORT_AREA_SIZE область в памяти выделенная под сортировки. Если ORACLE в нее не укладывается он их делает в temproary tablespace что просто фатально медленно. Увеличь сначала процентов на 25 потом еще на 25 посмотри как скажется на производительности. Потоому как тише едешь дальше будешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 12:43 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1990469]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
201ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
79ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 572ms |

| 0 / 0 |
