powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Подскажите где искать причину странного поведения оптимизатора
5 сообщений из 5, страница 1 из 1
Подскажите где искать причину странного поведения оптимизатора
    #39478427
me7
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый день, с некоторых пор запросы к одной из таблиц стали переодически переключатся на фулскан таблицы, даже там где это очевидно не оптимально, отлавливаем такие запросы по одному и прибиваем правильные планы, но хотелось бы разобраться что руководит CBO и на основании чего такие странные косты в плане. Пример отловленного сегодня запроса:

Код: 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.
TAB2 10_980_763_079 записей

SELECT DAVA_PK 
  FROM TAB1 
  JOIN TAB2 
    ON TAB2_PK = TAB1_PK 
       AND TAB2_F1 = :B1 
 WHERE TAB1_F2 = :B2 
   AND ROWNUM = 1
 

--------------------------------------------------------------------------------------------------
| Id  | Operation           | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |                            |       |       |    15 (100)|          |
|*  1 |  COUNT STOPKEY      |                            |       |       |            |          |
|   2 |   NESTED LOOPS      |                            |  4867 |   190K|    15   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS FULL| TAB2                       |     4 |    56 |     3   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN | IDX_TAB1_F2                |  1188 | 30888 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------
 
   1 - filter(ROWNUM=1)
   3 - filter("TAB2_F1"=:B1)
   4 - access("TAB1_F2"=:B2 AND "TAB1_PK"="TAB2_PK")


ожидаемый план должен выглядеть вот так
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
--------------------------------------------------------------------------------
| Id  | Operation                     | Name                         | Rows  | B
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                              |     1 |
|*  1 |  COUNT STOPKEY                |                              |       |
|   2 |   NESTED LOOPS                |                              |       |
|   3 |    NESTED LOOPS               |                              |     2 |
|*  4 |     INDEX RANGE SCAN          | IDX_TAB1_F2                  |    28 |
|*  5 |     INDEX UNIQUE SCAN         | IDX_TAB2_PK                  |     1 |
|*  6 |    TABLE ACCESS BY INDEX ROWID| TAB2                         |     1 |
--------------------------------------------------------------------------------

   1 - filter(ROWNUM=1)
   4 - access("TAB1_F2"=TO_NUMBER(:B2))
   5 - access("TAB1_PK"="TAB2_PK")
   6 - filter("TAB2_F1"=:B1)



непонятно почему CBO считает, что фулскан 10 миллиардов записей это быстрая операция, статистика по таблицам есть, собирается автоматически
...
Рейтинг: 0 / 0
Подскажите где искать причину странного поведения оптимизатора
    #39478443
MaximaXXL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
me7,

может эти 2 поля TAB2_PK = TAB1_PK есть в TAB2
...
Рейтинг: 0 / 0
Подскажите где искать причину странного поведения оптимизатора
    #39478447
trc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trc
Гость
Трейсы сделай , распределение данных посмотри , гисторгамами поиграй .
...
Рейтинг: 0 / 0
Подскажите где искать причину странного поведения оптимизатора
    #39478451
me7
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
trc,

денсити для столбцов похож на реальное распределение, гистаграмы удалил, у индексов был плохой кластеринг фактор, подменял его через сет - план всё равно остаётся плохой, через dbms_sqltune выдаётся и прибивается хороший план, но не понятно с чем это связано
...
Рейтинг: 0 / 0
Подскажите где искать причину странного поведения оптимизатора
    #39482212
oldtoad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
me7,

В первом случае оптимизатор планирует прочитать не более 4-х строк, т.к. стоит ограничение по rownum. Речь про миллионы записей там не идет.
...
Рейтинг: 0 / 0
5 сообщений из 5, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Подскажите где искать причину странного поведения оптимизатора
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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