powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / скачок cpu cost в плане
8 сообщений из 8, страница 1 из 1
скачок cpu cost в плане
    #39384065
Фотография 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
скачок cpu cost в плане
    #39384066
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
скачок cpu cost в плане
    #39384079
123йй
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shtock,
Код: plsql
1.
2.
3.
create table bred_index(val varchar2(300))

create index bred_index on bred_index(val)
...
Рейтинг: 0 / 0
скачок cpu cost в плане
    #39384094
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И?
...
Рейтинг: 0 / 0
скачок cpu cost в плане
    #39384406
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
скачок cpu cost в плане
    #39385332
Фотография 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
скачок cpu cost в плане
    #39385516
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо. Может в след версии что подкрутят, но всё равно это пугает.
...
Рейтинг: 0 / 0
скачок cpu cost в плане
    #39385542
ORA__SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShtockСпасибо. Может в след версии что подкрутят, но всё равно это пугает.Поменьше думай о cost'e. А лучше убери столбцы *COST* из PLAN_TABLE_OUTPUT и спи спокойно
...
Рейтинг: 0 / 0
8 сообщений из 8, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / скачок cpu cost в плане
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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