powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Анализ таблиц и выполнение запросов
25 сообщений из 40, страница 1 из 2
Анализ таблиц и выполнение запросов
    #32161582
Kate_new
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Помогите...
Есть несколько таблиц и два запроса по ним. До настройки запросов и
вычисления статистики по этим таблицам, запросы выполнялись в одной
процедуре и каждый из них в среднем выполнялся 4,5 часа. После
оценки статистики (10 %) для таблиц время выполнения каждого запроса сократилось на 1,5 часа, что +, но они "не хотят" выполняться в одной процедуре. Первый запрос выполняется,а второй "виснет" на неопределенное время и приходится его прерывать. Приходится делать перезагрузку перед выполнением каждого запроса :-(. Почему это происходит?
Oracle8i Enterprise Edition
Release 8.1.5.0.0 под NT
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32161590
Фотография Oleg Afanasiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Имел неприятный опыт работы с 815 на NT4sp6
Подними до 17 версии, иначе результаты
экспериментов могут быть не чистыми ;_)
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32161610
Kate_new
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Олег, а причем тут результаты экспериментов, если у меня запросы по отдельности выполняются, а если их последовательно включить в одну процедуру, то нет.
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32161630
Фотография Oleg Afanasiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Потому что чудес не бывает ;_)
Проблема в чём?
Они раньше выполнялись а после сбора статистики не стали?
Что значит запрос "виснет?"
Или статистика тут не причём?
Если да то с такой ситуацией конкретно я не сталкивался,
но я говорю о том что версия 815 на NT4 не надёжна.
Я это видел своими глазами. Постоянно лезла
end of file во время работы
Вот потому и говорю что неплохобыло бы поднять версию.
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32161707
Kate_new
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Да нет, первый то запрос выполняется, а второй всю ночь проработал и не выполнился, я просто прервала выполнение, а вот если эти запросы запустить отдельно: первый выполняется, перезагружается комп, запускается второй и все прекрасно выполняется.
Проблема в том, что второй запрос, записанный следом за первым в одну процедуру, не понятно как выполняется, т.е. никаких дурных сообщений нет, комп исправно тарахтит, но время, которое я жду до того как самой прервать выполнение процедуры >18 часов и результатов никаких , хотя если по отдельности запускать с перезагрузкой запросы, то каждый выполняется не >3 часов
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32161782
юный ораклист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
запусти трассировку,и посмотри,что сессия творит
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32161792
Roman_M
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Возможно сбор статистики привел к изменению плана второго запроса, и он стал "неудачным". Можно попробовать хинты, или попробовать разобраться в плане выполнения - чего там не хватает - может индексов, может для join начала работать сортировка и т.д. и т.п. Ну и в общем-то собранную статистику и удалить можно...
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32161793
Roman_M
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
С другой стороны, если по отдельности работают оба, то дело наверное не в плане...
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32162971
Фотография Eter Panji
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А можно процедурку.
Сдается мне что именно том что они как-то друг-другу жизнь портят за счет ухудшения I\O.
И кстати размер табличек тоже пригодился бы.
А так же Execution plan по каждому запросу.
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163132
Kate_new
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163170
Фотография Eter Panji
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Приблизительный план такой
у вас в запросе фулсканов как грязи
и в целях оптимизации ORACLE любит такие таблички оставлять
в пямяти и соответственно в дальнейшем для сортировок он начинает использоавть диск. Диск это всегда тормоз.

Почему он не выгружает ее из памяти при начале выполнения второго запроса не знаю.

Главный рецепт. Разбейте это всё на более мелкие запросы. Тут правильно говорят "JOIN больше 3 таблиц, значит ошибка в програмной логике"
У меня таблички по нескольку миллионов строк и когда я их объединяю зачастую пройтись курсором оказывается быстрее чем делать такое сверх_объединение.

Второстепнный рецепт. Постройте индексы чтобы не было фулсканов. И хинт RULE

Третьестепенный рецепт увелите SORT_AREA_SIZE
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163256
.dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163272
Kate_new
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
для .dba
Запросы настроены оптимально с точки зрения индексов - работа была проведена - full scan таблицы работает быстрее, чем полное сканирование индекса. До этого выполнялось медленне, но все вместе, а теперь быстро, но по отдельности :-(
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163283
Фотография Oracle X-pert
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
A nel'zya li izbegat' MERGE JOIN ? Tormoza..
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163290
Фотография Eter Panji
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 через него. Будет быстрее.
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163303
Kate_new
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
в этом то и заковырка, что history и smo_report1 поступают из двух разных источников и их сравнивают, так что смысл в том, чтобы каждой записи из smo_report1 сопоставить из history и проставить person_id + еще ......
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163311
Kate_new
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Oracle X-pert
а причем тут Merge Join??
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163332
Фотография Eter Panji
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я так понимаю что у тебя строчки не отсеиваются на объединении со справочниками. Если нет,
принуди сначала объединяться 2 большие таблицы используя индексы.
А маленькую PERSON_STATUS_NEW наоборот загони в КЕШ

Кстати индексы тоже неплохо бы проанализировать.
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163336
Kate_new
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
f
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163340
Kate_new
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
так вроде так и делается, сначала объединяются 2 большие таблицы, ранее с индексами было , но так медленнее, так как полное сканирование индекса медленнее, чем полное сканирование таблицы
status_new не маленькая 1 300 000 строк
индексы анализируются вместе с таблицами
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163347
Фотография Eter Panji
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А какие были индексы
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163351
Фотография Eter Panji
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> но так медленнее, так как полное сканирование индекса медленнее, чем
> полное сканирование таблицы

Зато память так не расходуется.
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163360
Фотография Oracle X-pert
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dorogoi v realizacii i medlennyi v ispolnenii algorithm. Bez osoboi nadobnosti ego ne ispol'zuyt.
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163371
Фотография Eter Panji
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Еще могу всётаки предложить создать временную таблиц в которую
сначала выгрузить весь person.smo_report1
потом проставить дополнительное поле
person_id
Затем проставить признак области
а уже затем сделать JOIN по двум оставшимся таблицам.

Какую таблицу временную или обычную не знаю. Наверное, для экономии кеша постоянную.
...
Рейтинг: 0 / 0
Анализ таблиц и выполнение запросов
    #32163377
Фотография Eter Panji
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Oracle X-pert
Это смотря какими ресурсами мы обладаем.
Вполне возможно еще парочку гигов оперативки и жизнь будет казаться сахаром.
А если памяти нет, но есть диск, как жить?
...
Рейтинг: 0 / 0
25 сообщений из 40, страница 1 из 2
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Анализ таблиц и выполнение запросов
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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