ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / скачок cpu cost в плане
8 сообщений из 8, страница 1 из 1
скачок cpu cost в плане
    #39384065
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Есть таблица с 2 индексами по одному полю.

Код: 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.
create table bred_index(val varchar2(300))

create index bred_index on bred_index(val)


CREATE INDEX bred_index_ctx ON bred_index(val) 
   INDEXTYPE IS "CTXSYS"."CONTEXT" ;


insert into BRED_INDEX (VAL)
values ('mail');

insert into BRED_INDEX (VAL)
values ('mailbox');

insert into BRED_INDEX (VAL)
values ('rust');

insert into BRED_INDEX (VAL)
values ('tested');

insert into BRED_INDEX (VAL)
values ('test');

Commit;



Делаем из неё 3 запроса


Почему-то скачок cost cpu с 1 и 4, до 39708854. Есть причины, почему так радикально? Я ожидал, что битмап три потребляет ресурс, но не на столько...
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
select t.val, t.rowid
  from BRED_INDEX t
  where val = 'rust';


select t.val, t.rowid
  from BRED_INDEX t
  where contains(val, 'mail') > 0;


select t.val, t.rowid
  from BRED_INDEX t
  where val = 'rust' or contains(val, 'mail') > 0




Oracle 12.
...
Рейтинг: 0 / 0
13.01.2017, 13:01
| Ответить | Цитировать | Написать  
скачок cpu cost в плане
    #39384066
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
...
Рейтинг: 0 / 0
13.01.2017, 13:02
| Ответить | Цитировать | Написать  
скачок cpu cost в плане
    #39384079
123йй
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
123йй
Участник
Shtock,
Код: plsql
1.
2.
3.
create table bred_index(val varchar2(300))

create index bred_index on bred_index(val)
...
Рейтинг: 0 / 0
13.01.2017, 13:14
| Ответить | Цитировать | Написать  
скачок cpu cost в плане
    #39384094
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
И?
...
Рейтинг: 0 / 0
13.01.2017, 13:20
| Ответить | Цитировать | Написать  
скачок cpu cost в плане
    #39384406
kirillss
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kirillss
Участник
у Lewis Cost-Based Oracle Fundamentals есть формула как общий cost считается из IO_COST и CPU_COST. так вот множитель у CPU_COST обратно пропорционален тактовой частоте и некоторой коннтсанте(общее значение типа 10^(-7)). Так что cpu_cost в десятки миллионов само по себе ничего страшного.

Скачок как следует из опубликованного плана происходит на шаге bitmap conversion ...
можно попробовать отключить alter session set "_b_tree_bitmap_plans" = FALSE; (работало в 11)
...
Рейтинг: 0 / 0
13.01.2017, 17:27
| Ответить | Цитировать | Написать  
скачок cpu cost в плане
    #39385332
Фотография SeaGate
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeaGate
Участник
Shtock,

ShtockПочему-то скачок cost cpu с 1 и 4, до 39708854. Есть причины, почему так радикально? Я ожидал, что битмап три потребляет ресурс, но не на столько...
По 10053 я вижу, что это на сортировку:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
  Access Path: index (DomainIndex)
    Index: BRED_INDEX_CTX
    user_cpu: 1  user_io: 4.000000 
    Cost: 4.000000  Resp: 4.000000  Degree: 0
    SORT ressource         Sort statistics
      Sort width:         598 Area size:      643072 Max Area size:   104857600
      Degree:               1
      Blocks to Sort: 1 Row size:     21 Total Rows:              1
      Initial runs:   1 Merge passes:  0 IO Cost / pass:          0
      Total IO sort cost: 0.000000      Total CPU sort cost: 13150582
      Total Temp space used: 0


С итоговым cpu cost-ом у меня: 13151795. Соответственно, надо искать расчет cpu cost для сортировки.
На порядок cpu cost для этого примера и моего окружения поднимает fix control 16799181:
Код: plsql
1.
2.
3.
4.
5.
6.
SQL> @fix 16799181

     BUGNO      VALUE SQL_FEATURE                        DESCRIPTION                                                      OPTIMIZE      EVENT IS_DEFAULT
---------- ---------- ---------------------------------- ---------------------------------------------------------------- -------- ---------- ----------
  14648222          1 QKSFM_CBO_16799181                 do not adjust partition pruning cardinality if already adjusted  12.1.0.2          0          1
  16799181          1 QKSFM_OR_EXPAND_16516883           raise startup cpu cost for sort                                  11.2.0.4          0          1


ниже демонстрация для последнего запроса.
 
Код: 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.
SQL> explain plan set statement_id='or' for
  2  select t.val, t.rowid
  3    from BRED_INDEX t
  4    where val = 'rust' or contains(val, 'mail') > 0;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------
Plan hash value: 2832543165

------------------------------------------------------------------------------------------------------
| Id  | Operation			    | Name	     | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT		    |		     |	   1 |	 164 |	   6  (17)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| BRED_INDEX     |	   1 |	 164 |	   6  (17)| 00:00:01 |
|   2 |   BITMAP CONVERSION TO ROWIDS	    |		     |	     |	     |		  |	     |
|   3 |    BITMAP OR			    |		     |	     |	     |		  |	     |
|   4 |     BITMAP CONVERSION FROM ROWIDS   |		     |	     |	     |		  |	     |
|*  5 |      INDEX RANGE SCAN		    | BRED_INDEX     |	     |	     |	   1   (0)| 00:00:01 |
|   6 |     BITMAP CONVERSION FROM ROWIDS   |		     |	     |	     |		  |	     |
|   7 |      SORT ORDER BY		    |		     |	     |	     |		  |	     |
|*  8 |       DOMAIN INDEX		    | BRED_INDEX_CTX |	     |	     |	   4   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("VAL"='rust')
   8 - access("CTXSYS"."CONTAINS"("VAL",'mail')>0)

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)
   - automatic DOP: Computed Degree of Parallelism is 1 because of parallel threshold

26 rows selected.

SQL> 
SQL> explain plan set statement_id='or_16799181' for
  2  select /*+ opt_param('_fix_control' '16799181:0')*/
  3  	    t.val, t.rowid
  4    from BRED_INDEX t
  5    where val = 'rust' or contains(val, 'mail') > 0;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------
Plan hash value: 2832543165

------------------------------------------------------------------------------------------------------
| Id  | Operation			    | Name	     | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT		    |		     |	   1 |	 164 |	   5   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| BRED_INDEX     |	   1 |	 164 |	   5   (0)| 00:00:01 |
|   2 |   BITMAP CONVERSION TO ROWIDS	    |		     |	     |	     |		  |	     |
|   3 |    BITMAP OR			    |		     |	     |	     |		  |	     |
|   4 |     BITMAP CONVERSION FROM ROWIDS   |		     |	     |	     |		  |	     |
|*  5 |      INDEX RANGE SCAN		    | BRED_INDEX     |	     |	     |	   1   (0)| 00:00:01 |
|   6 |     BITMAP CONVERSION FROM ROWIDS   |		     |	     |	     |		  |	     |
|   7 |      SORT ORDER BY		    |		     |	     |	     |		  |	     |
|*  8 |       DOMAIN INDEX		    | BRED_INDEX_CTX |	     |	     |	   4   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("VAL"='rust')
   8 - access("CTXSYS"."CONTAINS"("VAL",'mail')>0)

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)
   - automatic DOP: Computed Degree of Parallelism is 1 because of parallel threshold

26 rows selected.

SQL> 
SQL> col statement_id for a12
SQL> select statement_id, cost, cpu_cost
  2    from plan_table
  3   where statement_id is not null
  4  	and id = 0
  5   order by cpu_cost;

STATEMENT_ID	   COST   CPU_COST
------------ ---------- ----------
ctx		      4        192
btree		      1       7321
or_16799181	      5    1201213
or		      6   13151795

...
Рейтинг: 0 / 0
16.01.2017, 12:33
| Ответить | Цитировать | Написать  
скачок cpu cost в плане
    #39385516
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Спасибо. Может в след версии что подкрутят, но всё равно это пугает.
...
Рейтинг: 0 / 0
16.01.2017, 15:37
| Ответить | Цитировать | Написать  
скачок cpu cost в плане
    #39385542
ORA__SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ORA__SQL
Участник
ShtockСпасибо. Может в след версии что подкрутят, но всё равно это пугает.Поменьше думай о cost'e. А лучше убери столбцы *COST* из PLAN_TABLE_OUTPUT и спи спокойно
...
Рейтинг: 0 / 0
16.01.2017, 16:00
| Ответить | Цитировать | Написать  
8 сообщений из 8, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / скачок cpu cost в плане
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&fpage=180&tid=1886642]:
 0ms
get settings:
 9ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 66ms
get topic data:
 8ms
get forum data:
 3ms
get page messages:
 26ms
get tp. blocked users:
 1ms
others: 240ms
total:  376ms
созд. / загр.: 376ms
x
x
Закрыть


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