powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Oracle [игнор отключен] [закрыт для гостей] / (+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
44 сообщений из 44, показаны все 2 страниц
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838449
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Просветите, почему запрос

Код: sql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email from VW_NOLICENSE_VK NL
join address A
on NL.address_id = A.address_id (+)



Выполняется минимум в 2 раза дольше чем

Код: sql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email from VW_NOLICENSE_VK NL
join address A
on NL.address_id = A.address_id 



Результат запроса на моих данных один и тот же.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838450
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Cookin,

explain plan
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838456
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
-2-,

Когда плюс, то индекс ACCESS не используется а идёт
TABLE ACCESS STORAGE FULL TABLE MDHE.ADDRESS Cost: 218 Bytes: 4,972,716 Cardinality: 101,484

Недоумеваю, почему
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838457
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
index of ADDRESS table, not ACCESS
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838461
feagor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Victor Cookin,

Вы решили использовать ANSI синтаксис совместно внутренним оракловым?
Да вы знаете толк в извращениях.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838469
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
feagor,

Предложения есть?
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838470
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LEFT JOIN?
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838472
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email, inspector_id from VW_NOLICENSE_VK NL 
left join address A
on NL.address_id = A.address_id 



Так те же яйца, тот же план с TABLE ACCESS FULL
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838524
Фотография Изя Кацман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Cookin
Код: sql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email, inspector_id from VW_NOLICENSE_VK NL 
left join address A
on NL.address_id = A.address_id 



Так те же яйца, тот же план с TABLE ACCESS FULLИ чё?
Оптимизёр выбрал такой план.
Ты возражаешь?

P.S. Яйца спрячь. Зри в корень! :)
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838938
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изя КацманОптимизёр выбрал такой план.
Он не оптимален
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838943
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Victor CookinИзя КацманОптимизёр выбрал такой план.
Он не оптималенпотому что запрос (и девелопер?) "не оптимален"
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838977
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот план с простым JOIN, быстрый:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Plan
SELECT STATEMENT  ALL_ROWSCost: 534  Bytes: 58,580  Cardinality: 116  									
	14 HASH JOIN  Cost: 534  Bytes: 58,580  Cardinality: 116  								
		12 NESTED LOOPS  Cost: 534  Bytes: 58,580  Cardinality: 116  							
			10 NESTED LOOPS  Cost: 534  Bytes: 58,580  Cardinality: 116  						
				8 STATISTICS COLLECTOR  					
					7 VIEW VIEW SYS.VW_FOJ_0 Cost: 418  Bytes: 52,896  Cardinality: 116  				
						6 FILTER  			
							5 HASH JOIN OUTER  Cost: 418  Bytes: 11,252  Cardinality: 116  		
								2 JOIN FILTER CREATE SYS.:BF0000 Cost: 128  Bytes: 1,007,373  Cardinality: 11,579  	
									1 TABLE ACCESS STORAGE FULL TABLE MDHE.ESTABLISHMENT Cost: 128  Bytes: 1,007,373  Cardinality: 11,579  
								4 JOIN FILTER USE SYS.:BF0000 Cost: 290  Bytes: 1,773,880  Cardinality: 177,388  	
									3 TABLE ACCESS STORAGE FULL TABLE MDHE.ESTABLISHMENT_LICENSE Cost: 290  Bytes: 1,773,880  Cardinality: 177,388  
				9 INDEX UNIQUE SCAN INDEX (UNIQUE) MDHE.PK_ADDRESS Cost: 0  Cardinality: 1  					
			11 TABLE ACCESS BY INDEX ROWID TABLE MDHE.ADDRESS Cost: 1  Bytes: 49  Cardinality: 1  						
		13 TABLE ACCESS STORAGE FULL TABLE MDHE.ADDRESS Cost: 1  Bytes: 49  Cardinality: 1  							



Вот план с LEFT JOIN, медленный:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
Plan
SELECT STATEMENT  ALL_ROWSCost: 3,890  Bytes: 90,027,865  Cardinality: 178,273  				
	6 HASH JOIN RIGHT OUTER  Cost: 3,890  Bytes: 90,027,865  Cardinality: 178,273  			
		1 TABLE ACCESS STORAGE FULL TABLE MDHE.ADDRESS Cost: 218  Bytes: 4,972,716  Cardinality: 101,484  		
		5 VIEW VIEW SYS.VW_FOJ_0 Cost: 418  Bytes: 81,292,488  Cardinality: 178,273  		
			4 HASH JOIN FULL OUTER  Cost: 418  Bytes: 17,292,481  Cardinality: 178,273  	
				2 TABLE ACCESS STORAGE FULL TABLE MDHE.ESTABLISHMENT Cost: 128  Bytes: 2,440,959  Cardinality: 28,057  
				3 TABLE ACCESS STORAGE FULL TABLE MDHE.ESTABLISHMENT_LICENSE Cost: 290  Bytes: 1,773,880  Cardinality: 177,388  



Удивительно, но VW_NOLICENSE_VK не использует ни тот ни другой запрос, только если FULL. Да, и времени на FULL - столько же что и на LEFT, даром что 100 000 записей, а не 100.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840092
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Up
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840115
feagor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Victor Cookin,

я не вижу в твоём запросе предикатов каких-либо кроме связки таблицы с представлением.
Если нет предикатов, значит читать надо всё, так почему бы тогда не использовать table access full?
покажите код представления
Victor Cookin даром что 100 000 записей, а не 100
что это за ограничение, почему до этого про них ничего не говорили? где они в коде?
предоставьте пожалуйста план в читаемом формате например
выполнив
Код: plsql
1.
2.
explain plan for select бла-бла-бла;
select dbms_xplan.display_plan from dual
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840255
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
feagor,

Медленный запрос /94 rows 500 ms/

Код: plsql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email, inspector_id from VW_NOLICENSE_VK NL 
left join address A
on NL.address_id = A.address_id 


Код: css
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                  | Rows   | Bytes    | Cost | Time     |
------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                       | 178273 | 90027865 | 3890 | 00:00:01 |
| * 1 |   HASH JOIN RIGHT OUTER        |                       | 178273 | 90027865 | 3890 | 00:00:01 |
|   2 |    TABLE ACCESS STORAGE FULL   | ADDRESS               | 101484 |  4972716 |  218 | 00:00:01 |
| * 3 |    VIEW                        | VW_FOJ_0              | 178273 | 81292488 |  418 | 00:00:01 |
| * 4 |     HASH JOIN FULL OUTER       |                       | 178273 | 17292481 |  418 | 00:00:01 |
|   5 |      TABLE ACCESS STORAGE FULL | ESTABLISHMENT         |  28057 |  2440959 |  128 | 00:00:01 |
|   6 |      TABLE ACCESS STORAGE FULL | ESTABLISHMENT_LICENSE | 177388 |  1773880 |  290 | 00:00:01 |
------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
------------------------------------------
* 1 - access("ADDRESS_ID"="A"."ADDRESS_ID"(+))
* 3 - filter("ESTABLISHMENT_LICENSE_ID" IS NULL AND "E"."EST_CLOSED" IS NULL)
* 4 - access("E"."ESTABLISHMENT_ID"="EL"."ESTABLISHMENT_ID")



Быстрый запрос /94 rows 150 ms/

Код: plsql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email, inspector_id from VW_NOLICENSE_VK NL 
join address A
on NL.address_id = A.address_id 



Код: css
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
 Plan Hash Value  : 4025364740 

---------------------------------------------------------------------------------------------------------
| Id   | Operation                         | Name                  | Rows   | Bytes   | Cost | Time     |
---------------------------------------------------------------------------------------------------------
|    0 | SELECT STATEMENT                  |                       |    116 |   58580 |  534 | 00:00:01 |
|    1 |   NESTED LOOPS                    |                       |    116 |   58580 |  534 | 00:00:01 |
|    2 |    NESTED LOOPS                   |                       |    116 |   58580 |  534 | 00:00:01 |
|    3 |     VIEW                          | VW_FOJ_0              |    116 |   52896 |  418 | 00:00:01 |
|  * 4 |      FILTER                       |                       |        |         |      |          |
|  * 5 |       HASH JOIN OUTER             |                       |    116 |   11252 |  418 | 00:00:01 |
|    6 |        JOIN FILTER CREATE         | :BF0000               |  11579 | 1007373 |  128 | 00:00:01 |
|  * 7 |         TABLE ACCESS STORAGE FULL | ESTABLISHMENT         |  11579 | 1007373 |  128 | 00:00:01 |
|    8 |        JOIN FILTER USE            | :BF0000               | 177388 | 1773880 |  290 | 00:00:01 |
|  * 9 |         TABLE ACCESS STORAGE FULL | ESTABLISHMENT_LICENSE | 177388 | 1773880 |  290 | 00:00:01 |
| * 10 |     INDEX UNIQUE SCAN             | PK_ADDRESS            |      1 |         |    0 | 00:00:01 |
|   11 |    TABLE ACCESS BY INDEX ROWID    | ADDRESS               |      1 |      49 |    1 | 00:00:01 |
---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
------------------------------------------
* 4 - filter("EL"."ESTABLISHMENT_LICENSE_ID" IS NULL)
* 5 - access("E"."ESTABLISHMENT_ID"="EL"."ESTABLISHMENT_ID"(+))
* 7 - storage("E"."EST_CLOSED" IS NULL)
* 7 - filter("E"."EST_CLOSED" IS NULL)
* 9 - storage(SYS_OP_BLOOM_FILTER(:BF0000,"EL"."ESTABLISHMENT_ID"(+)))
* 9 - filter(SYS_OP_BLOOM_FILTER(:BF0000,"EL"."ESTABLISHMENT_ID"(+)))
* 10 - access("ADDRESS_ID"="A"."ADDRESS_ID")


Notes
-----
- This is an adaptive plan
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840272
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Внутри вьюхи VW_NOLICENSE_VK у тебя full outer join, и из-за условия
Код: plsql
1.
2.
join address A
on NL.address_id = A.address_id 


в "быстром" варианте oracle понимает, что NL.address_id не должен быть null, а это поле, судя по всему, берется из таблицы ESTABLISHMENT, поэтому oracle трансформирует FULL OUTER JOIN просто в "ESTABLISHMENT left join ESTABLISHMENT_LICENSE", что видно из плана:
Victor Cookin
Код: css
1.
2.
3.
4.
5.
6.
7.
|  * 5 |       HASH JOIN OUTER             |                       |    116 |   11252 |  418 | 00:00:01 |
|    6 |        JOIN FILTER CREATE         | :BF0000               |  11579 | 1007373 |  128 | 00:00:01 |
|  * 7 |         TABLE ACCESS STORAGE FULL | ESTABLISHMENT         |  11579 | 1007373 |  128 | 00:00:01 |
|    8 |        JOIN FILTER USE            | :BF0000               | 177388 | 1773880 |  290 | 00:00:01 |
|  * 9 |         TABLE ACCESS STORAGE FULL | ESTABLISHMENT_LICENSE | 177388 | 1773880 |  290 | 00:00:01 |

* 5 - access("E"."ESTABLISHMENT_ID"="EL"."ESTABLISHMENT_ID"(+))


Это приводит к тому, что оракл снижает кардинальность этой вью до 116 строк со 178273 (при полном FOJ), а в данном случае CBO справедливо считает, что лучше использовать NL и индексный доступ по 116 строкам.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840273
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
В медленном же варианте у тебя полноценный FULL OUTER JOIN, да еще и FTS (Full Table Scan) по ADDRESS.

ps. в следующий раз сразу показывай реальные планы выполнения со статистиками, а не explain plan.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840274
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Cookinfeagor,

Предложения есть?
попробуй дописать "where nl.address_id is not null"
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840275
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
feagorвыполнив
Код: plsql
1.
2.
explain plan for select бла-бла-бла;
select dbms_xplan.display_plan from dual


нет, лучше реальные планы со статистиками, т.е
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select/*+ GATHER_PLAN_STATISTICS MONITOR */ бла-бла-бла;
select * from table(dbms_xplan.display_cursor('','','advanced'));
select/*+ no_monitor */
  dbms_sqltune.report_sql_monitor(sql_id => rtsm_sql_id,report_level => 'ALL',type => 'TEXT') sqlmon 
from (
   select max(m.sql_id) keep(dense_rank first order by sql_exec_start desc) rtsm_sql_id 
   from v$sql_monitor m 
   where (m.sid,m.SESSION_SERIAL#) in (select s.sid,s.serial# from v$session s where s.sid=userenv('sid'))
   and m.LAST_REFRESH_TIME>sysdate-interval'1'minute
)
where rtsm_sql_id is not null;
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840279
Фотография SY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtender,

Все-тaки не FTS a TABLE ACCESS STORAGE FULL, т.е. EXADATA и посему я бы убедился что smart scan действительно offloading.

SY.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840282
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
SY,

Я обратил на это внимание, но посмотри примеры и вопрос внимательно:
1. В медленном варианте оффлоудить нечего, тк там FOJ и left join к address;
2. Второй вариант и так быстрый. С ним у тс вопроса не стоит, да и оффлоудинг по блум фильтру в непаралелльном запросе по небольшим несекционированным таблицам ничего обычно не даёт;
3. Заморачиваться на оффлоудинг при очевидных проблемах с планом бессмысленно и слишком рано. Кроме того, эксплейн ничего интересного про оффлоудинг не даёт и смотреть надо, как я выше показал, отчёт rtsm
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840283
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
кит северных морейVictor Cookinfeagor,

Предложения есть?
попробуй дописать "where nl.address_id is not null"а смысл? Тогда получится обычный джойн как во втором варианте (если, конечно, address id реально привязан к address.address_id
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840284
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
4. теоретически, конечно, возможно прибить в первом варианте хинт no_swap_join_input, чтобы попытаться форсировать оффлоудинг по address, но, очевидно, что это бессмысленно при таком малом кол-ве возвращаемых записей из нее и потенциально огромном кол-ве записей из вью, иначе индексный доступ был бы выгоднее, что определяется на этапе построения плана, а как будет и будет ли работать смарт скан - уже во время выполнения запроса
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840287
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtenderкит северных морейпропущено...

попробуй дописать "where nl.address_id is not null"а смысл? Тогда получится обычный джойн как во втором варианте (если, конечно, address id реально привязан к address.address_id

ну да. на это и расчет. обрати внимание на фильтр в строке 4 "быстрого" плана и на название вьюхи - я подозреваю, внутри неё что-то типа

select * from (
select * from establishment full join establishment_license
) where el. establishment_license_Id is null

а фулл джоин просто обернут в ещё одну вьюху, которую мы не видим из-за view merging.

то есть на самом деле ему нужны все establishment БЕЗ establishment_license, и с адресами - у кого есть. для этого не нужен FOJ между е и el.

плюс я сильно подозреваю что во вьюхе на самом деле надо было написать where el. establishment_id is null, и тогда оптимизатор разобрался бы в этом сам.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840660
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кит северных морей,

кит северных морейплюс я сильно подозреваю что во вьюхе на самом деле надо было написать where el. establishment_id is null, и тогда оптимизатор разобрался бы в этом сам.


Вы наверно имели в виду :
Код: plsql
1.
where establishment_LICENSE_id is null;



establishment_id не может быть равен null

Собственно, вот вьюха:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
CREATE OR REPLACE FORCE VIEW MDHE.VW_NOLICENSE_VK
(ESTABLISHMENT_ID, OPENING_DATE, NAME, PHONE, NOTES, 
 EST_BUSINESS_NAME, IS_SEASONAL, SEASON_OPEN_DATE, SEASON_CLOSE_DATE, ADDRESS_ID, 
 INSPECTOR_ID)
BEQUEATH DEFINER
AS 
select Establishment_id, opening_date, name, phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
address_id, inspector_id from (
select e.Establishment_id, opening_date, name, phone, e.notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
address_id, inspector_id, establishment_LICENSE_id   from 
establishment e
full join 
establishment_license el
on e.establishment_id  = el.establishment_id 
where e.est_closed is NULL 
)
where establishment_LICENSE_id is null;
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840662
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Victor Cookin,

Какова логика establishment и establishment_license? Не надо ли создать внешний ключ по establishment_id между ними?

Victor Cookinestablishment_id не может быть равен nullПриведи полный DDL всех трех таблиц с их констрейнтами.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840663
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
кит северных морейто есть на самом деле ему нужны все establishment БЕЗ establishment_license, и с адресами - у кого есть. для этого не нужен FOJ между е и el.

плюс я сильно подозреваю что во вьюхе на самом деле надо было написать where el. establishment_id is null, и тогда оптимизатор разобрался бы в этом сам.это все гадания... и проще спросить напрямую
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840664
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Cookin,

Victor Cookinestablishment_id не может быть равен null

Тьфу ты, конечно же может. То что в базе такого нет, не значит что не может быть висячих лицензий без бизнеса.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840669
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtender,

Моя ошибка в том, что я создал вьюху, которая показывает не только
А) бизнесы без лицензий, но и
Б) лицензии без бизнесов.
Собственно, каждодневная забота, это чтобы не было А).
Б) - это нужно когда чистят базу.
А поскольку в establishment_license стоит FK на establishment.establishment_ID, то и в принципе FULL JOIN во вьюхе не нужен, так как случай Б возможен только при отключении FK, что исключено.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840670
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Victor Cookin,

если бы establishment_ID был NOT NULL и был FK, оракл бы сам догадался FOJ заменить на left join
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840671
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Переписал VW_NOLICENSE_VK с FULL JOIN на LEFT JOIN
Теперь всё работает одинаково быстро.
Странно, Оптимизатор плюёт на FK, получается.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840672
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Victor CookinСтранно, Оптимизатор плюёт на FK, получается.он не "плюёт", а делает логично, учитывая, что поле establishment_ID nullable в establishment_license
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840673
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtender,

Только что проверил establishment_id - и NOT NULL и FK в establishment_license
Вот establishment_license_id - только NOT NULL
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840676
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
DROP TABLE MDHE.ESTABLISHMENT_LICENSE CASCADE CONSTRAINTS;

CREATE TABLE MDHE.ESTABLISHMENT_LICENSE
(
  ESTABLISHMENT_ID          NUMBER              NOT NULL,
  APPROVED_BY               NUMBER,
  NOTES                     VARCHAR2(500 BYTE),
  LICENSE_TYPE_CODE         VARCHAR2(30 BYTE),
  ESTABLISHMENT_LICENSE_ID  NUMBER              NOT NULL,
  BEGIN_DATE                DATE,
  EXPIRATION_DATE           DATE,
  STATUS_CODE               VARCHAR2(30 BYTE)   DEFAULT 'VALID'               NOT NULL,
  IS_CONDITIONAL            CHAR(1 BYTE)        DEFAULT 'N'                   NOT NULL,
  LICENSE_FEE               NUMBER              DEFAULT 0                     NOT NULL,
  CONDITIONAL_REASON_ID     NUMBER(4),
  CONDITIONAL_DAYS_ID       NUMBER(4)
)
TABLESPACE DATA
PCTUSED    0
PCTFREE    10
INITRANS   1
MAXTRANS   255
STORAGE    (
            INITIAL          80K
            NEXT             1M
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
           )
LOGGING 
NOCOMPRESS 
NOCACHE
MONITORING;

COMMENT ON TABLE MDHE.ESTABLISHMENT_LICENSE IS 'This table contains all the liceses that an establishment has had.
It will generate a history OF licenses AS they EXPIRE AND get renew.';

COMMENT ON COLUMN MDHE.ESTABLISHMENT_LICENSE.STATUS_CODE IS 'To determine the licese status (VALID, CANCEL, ON_HOLD, Etc)
NOTE: No ACTIVE status IS necesary, the Expiration DATE will determine IF license IS active OR NOT.';

COMMENT ON COLUMN MDHE.ESTABLISHMENT_LICENSE.IS_CONDITIONAL IS 'IF "N" then the license is a full license, other wise is a conditional (not to be renewed) license';


CREATE INDEX MDHE.ESTABLISHMENT_LICENSE_ID2 ON MDHE.ESTABLISHMENT_LICENSE
(LICENSE_TYPE_CODE)
LOGGING
TABLESPACE DATA
PCTFREE    10
INITRANS   2
MAXTRANS   255
STORAGE    (
            INITIAL          64K
            NEXT             1M
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
           );

CREATE INDEX MDHE.ESTABLISHMENT_LICENSE_IX1 ON MDHE.ESTABLISHMENT_LICENSE
(ESTABLISHMENT_ID)
LOGGING
TABLESPACE INDX
PCTFREE    10
INITRANS   2
MAXTRANS   255
STORAGE    (
            INITIAL          64K
            NEXT             1M
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
           );

CREATE UNIQUE INDEX MDHE.PK_ESTABLISHMENT_LICENSE ON MDHE.ESTABLISHMENT_LICENSE
(ESTABLISHMENT_LICENSE_ID)
LOGGING
TABLESPACE INDX
PCTFREE    10
INITRANS   2
MAXTRANS   255
STORAGE    (
            INITIAL          64K
            NEXT             1M
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
           );

CREATE OR REPLACE TRIGGER MDHE.SET_LICENSE_STATUS
BEFORE UPDATE OR INSERT ON MDHE.ESTABLISHMENT_LICENSE
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN


  /* first check to see if the exp date has changed, if it has and if the status is valid then check to see if its a valid end date */
  IF ((:NEW.STATUS_CODE = 'VALID') AND (TRUNC(:NEW.Expiration_date) < TRUNC(SYSDATE))) THEN
    -- IF  LicenseEndMonthDayOK(:new.expiration_date, :new.license_type_code) = 0 THEN
   -- IF LicenseEndMonthDayOK(to_date('07/28/2009','mm/dd/yyyy'), 32) = 0 THEN

             RAISE_APPLICATION_ERROR (-20999,'Invalid Expiration Date');
   --  END IF;
  END IF;
  IF :OLD.license_type_code IN  ('08','17','32','39','51','59','81')
     AND :OLD.Expiration_date < TRUNC(SYSDATE)
     AND :OLD.STATUS_CODE = 'VALID'
     AND :OLD.STATUS_CODE = :NEW.STATUS_CODE THEN
         :NEW.STATUS_CODE := 'CANCEL';
  END IF;
  IF :OLD.license_type_code NOT IN  ('08','17','32','39','51','59','81')
     AND :OLD.Expiration_date < TRUNC(SYSDATE)
     AND :OLD.STATUS_CODE = 'VALID'
     AND :OLD.STATUS_CODE = :NEW.STATUS_CODE THEN
       :NEW.STATUS_CODE := 'EXPIRED';
  END IF;

END;
/


ALTER TABLE MDHE.ESTABLISHMENT_LICENSE ADD (
  CONSTRAINT PK_ESTABLISHMENT_LICENSE
  PRIMARY KEY
  (ESTABLISHMENT_LICENSE_ID)
  USING INDEX MDHE.PK_ESTABLISHMENT_LICENSE
  ENABLE VALIDATE);

ALTER TABLE MDHE.ESTABLISHMENT_LICENSE ADD (
  CONSTRAINT FK_LICENCE_ESTABLISHMENT 
  FOREIGN KEY (ESTABLISHMENT_ID) 
  REFERENCES MDHE.ESTABLISHMENT (ESTABLISHMENT_ID)
  ENABLE VALIDATE
,  CONSTRAINT FK_LICENSE_TYPE 
  FOREIGN KEY (LICENSE_TYPE_CODE) 
  REFERENCES MDHE.LICENSE_TYPE (LICENSE_TYPE_CODE)
  DISABLE NOVALIDATE);
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840678
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Victor CookinТолько что проверил establishment_id - и NOT NULL и FK в establishment_licenseне верю©. Покажи трассу 10053 для
Код: plsql
1.
2.
3.
4.
select e.establishment_id, el.establishment_id 
from establishment e 
     full join establishment_license el
     on e.establishment_id  = el.establishment_id 
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840691
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtender,

У меня нет доступа к файлам трасс. Если подскажете как сделать в без записи в файлы, сделаю.
Я - разработчик, не DBA

вот план:

Plan Hash Value : 975423473

-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost | Time |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 178273 | 4635098 | 87 | 00:00:01 |
| 1 | VIEW | VW_FOJ_0 | 178273 | 4635098 | 87 | 00:00:01 |
| * 2 | HASH JOIN FULL OUTER | | 178273 | 1782730 | 87 | 00:00:01 |
| 3 | INDEX STORAGE FAST FULL SCAN | PK_ESTABLISHMENT | 28057 | 140285 | 13 | 00:00:01 |
| 4 | INDEX STORAGE FAST FULL SCAN | ESTABLISHMENT_LICENSE_IX1 | 177388 | 886940 | 74 | 00:00:01 |
-----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
------------------------------------------
* 2 - access("E"."ESTABLISHMENT_ID"="EL"."ESTABLISHMENT_ID")
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840694
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtender,

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
SQL Monitoring Report

SQL Text
------------------------------
select/*+ GATHER_PLAN_STATISTICS MONITOR */ e.establishment_id, el.establishment_id from establishment e full join establishment_license el on e.establishment_id = el.establishment_id

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)                                    
 Instance ID         :  3                                                  
 Session             :  MDHE (113:20617)                                   
 SQL ID              :  5mh955qrd56hb                                      
 SQL Execution ID    :  50331651                                           
 Execution Started   :  07/23/2019 11:52:04                                
 First Refresh Time  :  07/23/2019 11:52:04                                
 Last Refresh Time   :  07/23/2019 11:52:05                                
 Duration            :  1s                                                 
 Module/Action       :  TOAD Freeware 13.1.0.78/34909424,64289200,52344192 
 Service             :  mdhetst_dg                                         
 Program             :  Toad.exe                                           
 Fetch Calls         :  224                                                

Global Stats
=================================================
| Elapsed |   Cpu   |  Other   | Fetch | Buffer |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  |
=================================================
|    0.21 |    0.07 |     0.14 |   224 |    453 |
=================================================

SQL Plan Monitoring Details (Plan Hash Value=975423473)
===================================================================================================================================================================
| Id |            Operation             |           Name            |  Rows   | Cost |   Time    | Start  | Execs |   Rows   |  Mem  | Activity | Activity Detail |
|    |                                  |                           | (Estim) |      | Active(s) | Active |       | (Actual) | (Max) |   (%)    |   (# samples)   |
===================================================================================================================================================================
|  0 | SELECT STATEMENT                 |                           |         |      |         2 |     +0 |     1 |     178K |     . |          |                 |
|  1 |   VIEW                           | VW_FOJ_0                  |    178K |   87 |         2 |     +0 |     1 |     178K |     . |          |                 |
|  2 |    HASH JOIN FULL OUTER          |                           |    178K |   87 |         2 |     +0 |     1 |     178K |   7MB |          |                 |
|  3 |     INDEX STORAGE FAST FULL SCAN | PK_ESTABLISHMENT          |   28057 |   13 |         1 |     +0 |     1 |    28057 |     . |          |                 |
|  4 |     INDEX STORAGE FAST FULL SCAN | ESTABLISHMENT_LICENSE_IX1 |    177K |   74 |         2 |     +0 |     1 |     177K |     . |          |                 |
===================================================================================================================================================================
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840705
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Cookin
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
ALTER TABLE MDHE.ESTABLISHMENT_LICENSE ADD (
  CONSTRAINT FK_LICENCE_ESTABLISHMENT 
  FOREIGN KEY (ESTABLISHMENT_ID) 
  REFERENCES MDHE.ESTABLISHMENT (ESTABLISHMENT_ID)
  ENABLE VALIDATE
,  CONSTRAINT FK_LICENSE_TYPE 
  FOREIGN KEY (LICENSE_TYPE_CODE) 
  REFERENCES MDHE.LICENSE_TYPE (LICENSE_TYPE_CODE)
DISABLE NOVALIDATE);
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840715
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кит северных морей,

Ну меня не интересует LICENSE_TYPE_CODE. И я его нигде не запрашиваю. И таблицу LICENSE_TYPE не трогаю. Какое это всё может иметь влияние на план?
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840716
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Cookinкит северных морей,

Ну меня не интересует LICENSE_TYPE_CODE. И я его нигде не запрашиваю. И таблицу LICENSE_TYPE не трогаю. Какое это всё может иметь влияние на план?

никакого. я невнимательно прочитал ddl.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840724
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кит северных морей,
странное всё таки поведение, может из-за того что EXADATA?

Код: sql
1.
2.
3.
4.
5.
6.
BANNER,CON_ID
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production,0
PL/SQL Release 12.2.0.1.0 - Production,0
CORE	12.2.0.1.0	Production,0
TNS for Linux: Version 12.2.0.1.0 - Production,0
NLSRTL Version 12.2.0.1.0 - Production,0
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840725
Фотография SY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Cookin,

Приведи VW_NOLICENSE_VK для полноты картины.

SY.
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840728
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Victor Cookinстранное всё таки поведениепроверил только что на нескольких базах 12.1-19.3: действительно, несмотря на то, что у оракла есть трансформация FULL_OUTER_JOIN_TO_OUTER, но она не учитывает внешние ключи. Видимо, не подумали, что разработчик может воткнуть FOJ на таблицах, связанных через FK + not null...
...
Рейтинг: 0 / 0
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840729
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SY,

21932966

сейчас я исправил FULL на LEFT и всё заработало, но вроде должно было бы работать и с FULL
...
Рейтинг: 0 / 0
44 сообщений из 44, показаны все 2 страниц
Форумы / Oracle [игнор отключен] [закрыт для гостей] / (+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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