ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Странное поведение оптимизатора
5 сообщений из 5, страница 1 из 1
Странное поведение оптимизатора
    #39740336
nick28
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nick28
Гость
Добрый день!
Наткнулся на проблему, если добавить SYSDATE в запрос, работающий через DBLink, оптимизатор начинает творить какую-то дичь и тянуть данные с ремоута:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
  SELECT 1,SYSDATE
  FROM SVETLANA_PESTOVA.CELLSINASS@WH_NEW T
  JOIN BRD_SPT_COORDS_TBL@WH_NEW TD ON ( TRIM(T.SITEID) = TD.SITE_ID )
  WHERE NOT EXISTS ( SELECT 1
                     FROM TBL_CELL_DEF@WH_NEW D
                     WHERE UPPER(TRIM(T.CELL_NAME)) = D.CELL_NAME
                   )

---------------------------------------------------------------------------------------
| Id  | Operation        | Name               | Rows  | Bytes   | Cost     | Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                    | 41330 | 1777190 | 34208778 | 00:22:17 |
| * 1 |   FILTER         |                    |       |         |          |          |
| * 2 |    HASH JOIN     |                    | 41331 | 1777233 |      411 | 00:00:01 |
|   3 |     REMOTE       | BRD_SPT_COORDS_TBL | 11486 |  149318 |       15 | 00:00:01 |
|   4 |     REMOTE       | CELLSINASS         | 41331 | 1239930 |      395 | 00:00:01 |
|   5 |    REMOTE        | TBL_CELL_DEF       |     1 |     152 |      908 | 00:00:01 |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
------------------------------------------
* 1 - filter( NOT EXISTS (SELECT 0 FROM "A1" WHERE "D"."CELL_NAME"=UPPER(TRIM(:B1))))
* 2 - access("TD"."SITE_ID"=TO_NUMBER(TRIM(TO_CHAR("T"."SITEID"))))


Если убрать SYSDATE, всё выполняется на удалённой базе:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
-------------------------------------------------------------
| Id | Operation        | Name | Rows | Bytes | Cost | Time |
-------------------------------------------------------------
|  0 | SELECT STATEMENT |      |      |       |    0 |      |
|  1 |   REMOTE         |      |      |       |      |      |
-------------------------------------------------------------
на самой базе:
--------------------------------------------------------------------------------------------
| Id  | Operation             | Name                  | Rows   | Bytes   | Cost | Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |                       |  41331 | 1570578 | 2020 | 00:00:25 |
| * 1 |   HASH JOIN ANTI      |                       |  41331 | 1570578 | 2020 | 00:00:25 |
|   2 |    NESTED LOOPS       |                       |  41331 |  991944 |  617 | 00:00:08 |
|   3 |     TABLE ACCESS FULL | CELLSINASS            |  41331 |  785289 |  615 | 00:00:08 |
| * 4 |     INDEX UNIQUE SCAN | BRD_SPT_COORDS_TBL_PK |      1 |       5 |    0 | 00:00:01 |
|   5 |    TABLE ACCESS FULL  | TBL_CELL_DEF          | 132581 | 1856134 | 1401 | 00:00:17 |
--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
------------------------------------------
* 1 - access("D"."CELL_NAME"=UPPER(TRIM("T"."CELL_NAME")))
* 4 - access("TD"."SITE_ID"=TO_NUMBER(TRIM(TO_CHAR("T"."SITEID"))))


Может, кто лучше знаком с Ораклом, подскажет из-за чего такой странный план получается?
Хинтами стабилизировать запрос не удаётся, но если обернуть системную дату в COALESCE(SYSDATE,to_date('11.11.11','DD.MM.YY')),
всё становится на свои места, в то же время если обернуть в NVL(SYSDATE,to_date('11.11.11','DD.MM.YY')) , план остаётся ущербным.
Без JOIN BRD_SPT_COORDS_TBL@WH_NEW запрос всегда выполняется на ремоуте, но он тут нужен.
...
Рейтинг: 0 / 0
29.11.2018, 13:19
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора
    #39740340
nick28
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nick28
Гость
Забыл
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
db1	Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
db1	PL/SQL Release 12.1.0.2.0 - Production
db1	"CORE	12.1.0.2.0	Production"
db1	TNS for Linux: Version 12.1.0.2.0 - Production
db1	NLSRTL Version 12.1.0.2.0 - Production
remote	Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
remote	PL/SQL Release 11.2.0.1.0 - Production
remote	"CORE	11.2.0.1.0	Production"
remote	TNS for Linux: Version 11.2.0.1.0 - Production
remote	NLSRTL Version 11.2.0.1.0 - Production
...
Рейтинг: 0 / 0
29.11.2018, 13:22
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора
    #39740351
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Elic
Участник
Sysdate всегда локальный. Добавь его в предикаты, чтобы увидеть, как это выглядит.
...
Рейтинг: 0 / 0
29.11.2018, 13:33
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора
    #39740355
nick28
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nick28
Гость
Elic, не совсем тебя понял, куда надо смотреть?
Пробовал добавить вот такого монстра в запрос
AND CAST(CURRENT_TIMESTAMP AS DATE) BETWEEN SYSDATE-1 AND SYSDATE+1
но на план это никак не повлияло. Oracle вычисления выполняет на ремоуте и не тащит таблицы на локальную базу.

И, что странно, COALESCE(SYSDATE, NULL) или MAX(SYSDATE) не заставляют тащить данные на локальную db, а NVL(SYSDATE, NULL) - заставляет.
...
Рейтинг: 0 / 0
29.11.2018, 13:51
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
Странное поведение оптимизатора
    #39897610
nick28
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nick28
Гость
На других базах столкнулся, но теперь монстр стал ещё страшнее (:
Код: plsql
1.
COALESCE(TRUNC(SYSDATE),TRUNC(SYSDATE)) DD


Причём объединить на удалёнке и передать базе результирующий датасет, мешает только SYSDATE и TRUNC(SYSDATE).
Определение, например, квартала не ломает план, хотя если брать отдельно транки или add_month всё летит:
Код: plsql
1.
2.
3.
4.
5.
CASE WHEN TRUNC(SYSDATE,'Q') BETWEEN ADD_MONTHS(TRUNC(SYSDATE,'Y'),0*1) AND ADD_MONTHS(TRUNC(SYSDATE,'Y'),3*1)-1/24  THEN 1
     WHEN TRUNC(SYSDATE,'Q') BETWEEN ADD_MONTHS(TRUNC(SYSDATE,'Y'),3*1) AND ADD_MONTHS(TRUNC(SYSDATE,'Y'),3*2)-1/24  THEN 2
     WHEN TRUNC(SYSDATE,'Q') BETWEEN ADD_MONTHS(TRUNC(SYSDATE,'Y'),3*2) AND ADD_MONTHS(TRUNC(SYSDATE,'Y'),3*3)-1/24  THEN 3
     WHEN TRUNC(SYSDATE,'Q') BETWEEN ADD_MONTHS(TRUNC(SYSDATE,'Y'),3*3) AND ADD_MONTHS(TRUNC(SYSDATE,'Y'),3*4)-1/24  THEN 4
END QUARTAL
...
Рейтинг: 0 / 0
03.12.2019, 15:31
| Ответить | Цитировать | Написать  
5 сообщений из 5, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Странное поведение оптимизатора
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?desktop=1&fid=52&tid=1881791]:
 0ms
get settings:
 10ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 53ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 46ms
get tp. blocked users:
 2ms
others: 271ms
total:  421ms
созд. / загр.: 421ms
x
x
Закрыть


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