ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / 10053 помогите понять
8 сообщений из 8, страница 1 из 1
10053 помогите понять
    #39640419
feagor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
feagor
Гость
Есть запрос
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
SQL_ID  8hw3rv28cp9dd, child number 0
-------------------------------------
SELECT JURFL FROM G_CLI WHERE DEP_ID=:B2 AND ID=:B1
 
Plan hash value: 2364832747
 
--------------------------------------------------------------------------------------------
| Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |              |       |       |     1 (100)|          |
|*  1 |  TABLE ACCESS BY INDEX ROWID| G_CLI        |     1 |    12 |     1   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | FK_G_CLI_ORD |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - filter("ID"=:B1)
   2 - access("DEP_ID"=:B2)


абсолютно непонятно по какой причине работающий по FK_G_CLI_ORD вместо PK(dep_id,id)

Снял 10053, но не осилил её.
Может кто подсказать в чем причина, и самое главное как с этим бороться?
...
Рейтинг: 0 / 0
04.05.2018, 21:47
| Ответить | Цитировать | Написать  
10053 помогите понять
    #39640440
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
В отсутствие адекватной статистики CBO в состоянии построить сколь угодно плохой план (с)
Пересоберите статистику, в т.ч. по индексам, и не используйте на 11.2 гистограммы совместно с bind-переменными при включенном bind variables peeking. Один раз распарсил с неудачным значением, затем до инвалидации курсора мучайся...
...
Рейтинг: 0 / 0
04.05.2018, 22:23
| Ответить | Цитировать | Написать  
10053 помогите понять
    #39640465
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
feagor,

удалите гистограммы и extended statistics:
 
CorStregth: -1.00
Код: 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.
SINGLE TABLE ACCESS PATH
  Single Table Cardinality Estimation for G_CLI[G_CLI]
  Column (#1):
    NewDensity:0.000026, OldDensity:0.000001 BktCnt:255, PopBktCnt:253, PopValCnt:1, NDV:301
  Column (#1): DEP_ID(
    AvgLen: 4 NDV: 301 Nulls: 0 Density: 0.000026 Min: 968 Max: 1561
    Histogram: HtBal  #Bkts: 255  UncompBkts: 255  EndPtVals: 3
  Column (#2): ID(
    AvgLen: 6 NDV: 1695104 Nulls: 0 Density: 0.000001 Min: 1 Max: 1791625
  ColGroup (#1, Index) PK_G_CLI
    Col#: 1 2    CorStregth: 291.42
  ColGroup (#2, Index) FK_G_CLI_ORD
    Col#: 1 11    CorStregth: -1.00
  ColGroup Usage:: PredCnt: 2  Matches Full:  Partial:
  Table: G_CLI  Alias: G_CLI
    Card: Original: 1700412.000000  Rounded: 1  Computed: 0.00  Non Adjusted: 0.00
  Access Path: TableScan
    Cost:  3065.51  Resp: 3065.51  Degree: 0
      Cost_io: 2954.00  Cost_cpu: 463043254
      Resp_io: 2954.00  Resp_cpu: 463043254
  Access Path: index (UniqueScan)
    Index: PK_G_CLI
    resc_io: 3.00  resc_cpu: 30569
    ix_sel: 0.000001  ix_sel_with_filters: 0.000001
    Cost: 3.01  Resp: 3.01  Degree: 1
  Access Path: index (RangeScan)
    Index: FK_G_CLI_ORD
    resc_io: 2.00  resc_cpu: 19686
    ix_sel: 0.000000  ix_sel_with_filters: 0.000000
    Cost: 2.00  Resp: 2.00  Degree: 1
  ColGroup Usage:: PredCnt: 2  Matches Full:  Partial:
  ColGroup Usage:: PredCnt: 2  Matches Full:  Partial:
  Access Path: index (AllEqUnique)
    Index: PK_G_CLI
    resc_io: 3.00  resc_cpu: 30569
    ix_sel: 0.000000  ix_sel_with_filters: 0.000000
    Cost: 3.01  Resp: 3.01  Degree: 1


+ https://blog.pythian.com/multi-column-correlation-and-extended-stats-in-oracle-11g/
...
Рейтинг: 0 / 0
04.05.2018, 23:14
| Ответить | Цитировать | Написать  
10053 помогите понять
    #39640634
feagor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
feagor
Гость
andrey_anonymous,

Статистика собирается постоянно
andrey_anonymousОдин раз распарсил с неудачным значением, затем до инвалидации курсора мучайся...
Похоже на то, когда смотрел Bindы запроса было вот так
Код: plsql
1.
SELECT * FROM table(dbms_xplan.display_cursor('345m3fv92hrbn',format => 'basic +PEEKED_BINDS'));


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
EXPLAINED SQL STATEMENT:
------------------------
SELECT JURFL FROM G_CLI WHERE DEP_ID=:B2 AND ID=:B1
 
Plan hash value: 2364832747
 
----------------------------------------------------
| Id  | Operation                   | Name         |
----------------------------------------------------
|   0 | SELECT STATEMENT            |              |
|   1 |  TABLE ACCESS BY INDEX ROWID| G_CLI        |
|   2 |   INDEX RANGE SCAN          | FK_G_CLI_ORD |
----------------------------------------------------
 
Peeked Binds (identified by position):
--------------------------------------
 
   1 - :B2 (VARCHAR2(30), CSID=873): (null)
   2 - :B1 (VARCHAR2(30), CSID=873): (null)

Соответственно похоже есть понимание, что такой план рисуется, когда передаются id=null,dep_id=null
Но искать почему передаются nullы и пытаться это исправить мне видится довольно бесполезной затеей, с которой вероятнее всего ничего не получится сделать. При этом ситуация возникает не в первый раз именно на этой таблице и одной другой схожей таблице. Понятно что можно захинтовать, прибить baselineом, перевестись в rule -и все будет прекрасно работать, но хотелось бы понять.
xtenderудалите гистограммы и extended statistics:
Вроде extended statistics не использовалась никогда, по крайней мере
Код: plsql
1.
select * from user_stat_extensions t where t.TABLE_NAME = 'G_CLI'


ничего не выдаёт

Гистограмы убрал, почистил shared pool, запустил запрос снова(в bindы так же как в выявленной ситуации передаю null)
План все тот же

Код: plaintext
2 - access("DEP_ID"=:B2)
...
Рейтинг: 0 / 0
05.05.2018, 14:32
| Ответить | Цитировать | Написать  
10053 помогите понять
    #39640638
feagor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
feagor
Гость
xtender,

а что за CorStregth: -1.00? Это значит, что оптимизатор считает, что между колонками нет асболютно никакой кореляции?
Мне, по правде, вообще не понятно как корреляция между колонками тут может на что-то влиять.
Я вижу из выделенного вами, что cost по FK_G_CLI_ORD = 2, вместо 3 по PK_G_CLI, и я так понимаю именно по cost и выбирается использование FK_G_CLI_ORD
...
Рейтинг: 0 / 0
05.05.2018, 14:49
| Ответить | Цитировать | Написать  
10053 помогите понять
    #39640648
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
feagor,

Сначала пересоберите статистику по индексу fk... Что-то с ним не так - Corstrength не должен быть отрицательным.

Зы. Для null вообще без разницы из какого индекса ничего не возвращать...
...
Рейтинг: 0 / 0
05.05.2018, 15:26
| Ответить | Цитировать | Написать  
10053 помогите понять
    #39640651
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
Corstrength - это коэффициент подгонки кардинальности, а она отрицательной быть не может
...
Рейтинг: 0 / 0
05.05.2018, 15:28
| Ответить | Цитировать | Написать  
10053 помогите понять
    #39640775
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
feagorЯ вижу из выделенного
По памяти (лень еще раз читать трассу) :
Для обоих индексов - как по DEP_ID, так и по PK - оптимизатор ожидает считать единственный leaf-block в расчете на ключ и найти там единственную запись, отвечающую предикату.
При этом одноколоночный индекс по DEP_ID физически меньше и CPU на проверку одного атрибута надо меньше чем на два - сплошной профит, короче (оценка IO 2 блока для DEP_ID и 3 блока по PK).
Но эта оценка не вполне естественна с учетом статистики по DEP_ID, где говорится, что NDV=301, и размера индекса (~4000 блоков, на помню уже точно), т.е. в пересчете на ключ должно вытанцовываться порядка 10-20 блоков.
Либо статистика по индексу не собрана, либо "играет" дуэт из гистограммы и bind peeking при неудачном значении bind-переменной на момент парсинга.

Еще раз: соберите статистику по таблице без гистограмм, не забудьте cascade=>true дабы зацепить индексы.
...
Рейтинг: 0 / 0
05.05.2018, 20:55
| Ответить | Цитировать | Написать  
8 сообщений из 8, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / 10053 помогите понять
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&fpage=115&tid=1884037]:
 0ms
get settings:
 6ms
get forum list:
 19ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 55ms
get topic data:
 12ms
get forum data:
 4ms
get page messages:
 57ms
get tp. blocked users:
 2ms
others: 203ms
total:  364ms
созд. / загр.: 364ms
x
x
Закрыть


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