Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Ошибочные хинты в запросе  [new]
Valergrad
Member

Откуда:
Сообщений: 446
https://docs.oracle.com/cloud/latest/db112/SQLRF/sql_elements006.htm#SQLRF51098

Oracle Database ignores hints and does not return an error under the following circumstances:
• The hint contains misspellings or syntax errors. However, the database does consider other correctly specified hints in the same comment.

Эта фраза выглядит как "если в комменте есть два хинта, и один из них некорректный, а второй - корректный, то второй применится."
На практике легко проверить, что первый же ошибочный хинт выключает все хинты, следующие за ним, независимо от их корректности.
Это ошибка в доке или я просто не понимаю?
12 окт 17, 16:28    [20864822]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
Elic
Member

Откуда: 1984. Выбраковка финно-угром началась. КЯЗ
Сообщений: 27290
Valergrad
На практике легко проверить, что
Ну так продемонстрируй.
12 окт 17, 16:33    [20864850]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
xtender
Member

Откуда: Мск
Сообщений: 4509
Valergrad,

Да, про это уже кто-то писал давно в блоге у себя... сходу не вспомню у кого, но это известная штука
12 окт 17, 16:37    [20864867]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
xtender
Member

Откуда: Мск
Сообщений: 4509
Хотя если я правильно помню то игнорирует только до конца строки, поэтому если хинты расположить каждый в своей строке то будут работать те что правильные. Кром того точно знаю что так хинты можно закомментировать
12 окт 17, 16:40    [20864876]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
Lary Denis
Guest
Valergrad,

create table tst_tab as select level id from dual connect by level < 1001;

explain plan for
select * 
from  tst_tab t1 
inner join tst_tab t2 on t1.id = t2.id;



| 0 | SELECT STATEMENT | | 1000 | 26000 | 6 (0)| 00:00:01 |
|* 1 | HASH JOIN | | 1000 | 26000 | 6 (0)| 00:00:01 |
| 2 | TABLE ACCESS FULL| TST_TAB | 1000 | 13000 | 3 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL| TST_TAB | 1000 | 13000 | 3 (0)| 00:00:01 |


explain plan for
select /*+ materialiBe use_nl(t1,t2)*/ * 
from  tst_tab t1 
inner join tst_tab t2 on t1.id = t2.id;


| 0 | SELECT STATEMENT | | 1000 | 26000 | 1510 (1)| 00:00:01 |
| 1 | NESTED LOOPS | | 1000 | 26000 | 1510 (1)| 00:00:01 |
| 2 | TABLE ACCESS FULL| TST_TAB | 1000 | 13000 | 3 (0)| 00:00:01 |
|* 3 | TABLE ACCESS FULL| TST_TAB | 1 | 13 | 2 (0)| 00:00:01 |



11.2
12 окт 17, 16:41    [20864880]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 4811
Valergrad,

Эта фраза не выглядит так.
Но если вопрос - могут ли "левые" слова влиять на применимость кооректных хинтов - ответ да.
16304443
12 окт 17, 16:48    [20864905]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
xtender
Member

Откуда: Мск
Сообщений: 4509
хотя, видимо, все меняется:
SQL> select/*+
  2     opt_param('optimizer_index_caching' 1)
  3     --opt_param('optimizer_index_cost_adj' 3)
  4     OPTIMIZER_FEATURES_ENABLE('11.2.0.2')
  5     q first_rows(10)
  6     opt_param('optimizer_index_cost_adj' 7)
  7  */
  8  * from dual;

D
-
X

1 row selected.

SQL> select * from table(dbms_xplan.display_cursor('','','last +outline'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------
SQL_ID  6cu5s2v6mv18k, child number 0
-------------------------------------

Plan hash value: 272002086

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |     2 (100)|          |
|   1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------

Outline Data
-------------

  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('11.2.0.2')
      DB_VERSION('12.2.0.1')
      OPT_PARAM('optimizer_index_cost_adj' 7)
      OPT_PARAM('optimizer_index_caching' 1)
      FIRST_ROWS(10)
      OUTLINE_LEAF(@"SEL$1")
      FULL(@"SEL$1" "DUAL"@"SEL$1")
      END_OUTLINE_DATA
  */
12 окт 17, 16:54    [20864920]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 4811
Простая демонстрация без планов.

SQL> create table t as select 1 id from dual;

Table created.

SQL> select --+ rewrite_or_error
  2  * from t;
* from t
       *
ERROR at line 2:
ORA-30393: a query block in the statement did not rewrite


SQL> select --+ ooops rewrite_or_error
  2  * from t;
* from t
       *
ERROR at line 2:
ORA-30393: a query block in the statement did not rewrite


SQL> select --+ ooops i did it again rewrite_or_error
  2  * from t;
* from t
       *
ERROR at line 2:
ORA-30393: a query block in the statement did not rewrite


SQL> select --+ ignore that shit rewrite_or_error
  2  * from t;

        ID
----------
         1


Надеюсь не надо уточнять, что не стоит делать из этого далеко идущие выводы.
12 окт 17, 16:56    [20864930]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
Valergrad
Member

Откуда:
Сообщений: 446
А попробуйте это:

select /*+ full(t3,t4) use_nl(t1,t2)*/ *
from tst_tab t1
inner join tst_tab t2 on t1.id = t2.id;


Plan hash value: 3128579258

-------------------------------------------------------------------------------
| Id | Operation | Name | E-Rows |E-Bytes| Cost (%CPU)| E-Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 26000 | 6 (0)| 00:00:01 |
|* 1 | HASH JOIN | | 1000 | 26000 | 6 (0)| 00:00:01 |
| 2 | TABLE ACCESS FULL| TST_TAB | 1000 | 13000 | 3 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL| TST_TAB | 1000 | 13000 | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------
12 окт 17, 17:04    [20864971]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
xtender
Member

Откуда: Мск
Сообщений: 4509
блин, вспомнил что в той статье в чьем-то блоге показывался пример на буквах, и не все буквы приводили к игнорированию остальных хинтов, а вот вспомнить в чьем блоге и нагуглить не удается...
Если правильно помню, Тимур Ахмадеев там тоже участвовал в дискуссии
12 окт 17, 17:04    [20864976]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
Valergrad
Member

Откуда:
Сообщений: 446
dbms_photoshop

Надеюсь не надо уточнять, что не стоит делать из этого далеко идущие выводы.


Вывод: "не стоит в принципе рассчитывать на то, что в случае некорректности одного хинта будут работать остальные" - далеко идущий?
12 окт 17, 17:06    [20864989]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
Valergrad
Member

Откуда:
Сообщений: 446
xtender
блин, вспомнил что в той статье в чьем-то блоге показывался пример на буквах, и не все буквы приводили к игнорированию остальных хинтов


А у меня нет цензурных букв на такое поведение оракла :)
12 окт 17, 17:08    [20864995]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 4811
Valergrad
dbms_photoshop
Надеюсь не надо уточнять, что не стоит делать из этого далеко идущие выводы.


Вывод: "не стоит в принципе рассчитывать на то, что в случае некорректности одного хинта будут работать остальные" - далеко идущий?
Корректный вывод.

Я про бесполезность построения теорий в каких именно случаях левые буквы влияют на корректные хинты.
12 окт 17, 17:10    [20865006]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
xtender
Member

Откуда: Мск
Сообщений: 4509
имхо просто не надо кривые хинты писать
12 окт 17, 17:15    [20865033]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
xtender
Member

Откуда: Мск
Сообщений: 4509
или хотя бы закомментируйте их
12 окт 17, 17:16    [20865041]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
Lary Denis
Guest
Valergrad
А попробуйте это:

select /*+ full(t3,t4) use_nl(t1,t2)*/ *
from tst_tab t1
inner join tst_tab t2 on t1.id = t2.id;



Со всем этим уже не работает.

select /*+ ~,.!& use_nl(t1,t2) */ * 
from tst_tab t1 
inner join tst_tab t2 on t1.id = t2.id;
12 окт 17, 17:29    [20865111]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
j2k
Member

Откуда: Новосибирск
Сообщений: 472
Да ладно хинты :D

with t as (select level a, trunc(level/3) b from dual connect by level<=10) 
select b, min(a) keep (dense_rank last ЙА_БЭТМЕН by a) from t  group by b
12 окт 17, 17:29    [20865115]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
Добрый Э - Эх
Guest
j2k
Да ладно хинты :D

with t as (select level a, trunc(level/3) b from dual connect by level<=10) 
select b, min(a) keep (dense_rank last ЙА_БЭТМЕН by a) from t  group by b
выделять же нужно... а то не сразу в глаза бросается... $)
12 окт 17, 18:11    [20865319]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 16094
dbms_photoshop
бесполезность построения теорий в каких именно случаях левые буквы влияют на корректные хинты.

Это вопрос к парсеру - именно он решает, в каком месте заканчивается некорректная последовательность волшебных символов и начинает искать следующую.
12 окт 17, 19:36    [20865479]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
SY
Member

Откуда: Middlebury, CT USA
Сообщений: 8624
xtender
блин, вспомнил что в той статье в чьем-то блоге показывался пример на буквах, и не все буквы приводили к игнорированию остальных хинтов


А ты посмотри на последний SQL в примере от dbms_photoshop'а. Похоже еть недокументиpовaнные хинты для отмены хинтов:

SQL> explain plan for
  2  select  *
  3    from  emp e,dept d
  4    where empno = 1
  5      and d.deptno = e.deptno
  6  /

Explained.

SQL> select * from table(dbms_xplan.display)
  2  /

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------
Plan hash value: 2385808155

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |     1 |    58 |     2   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |         |     1 |    58 |     2   (0)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| EMP     |     1 |    38 |     1   (0)| 00:00:01 |
|*  3 |    INDEX UNIQUE SCAN         | PK_EMP  |     1 |       |     0   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    20 |     1   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   3 - access("EMPNO"=1)
   5 - access("D"."DEPTNO"="E"."DEPTNO")

18 rows selected.

SQL> explain plan for
  2  select  --+ use_hash(d,e)
  3          *
  4    from  emp e,dept d
  5    where empno = 1
  6      and d.deptno = e.deptno
  7  /

Explained.

SQL> select * from table(dbms_xplan.display)
  2  /

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------
Plan hash value: 373232351

---------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     1 |    58 |     4   (0)| 00:00:01 |
|*  1 |  HASH JOIN                   |        |     1 |    58 |     4   (0)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    38 |     1   (0)| 00:00:01 |
|*  3 |    INDEX UNIQUE SCAN         | PK_EMP |     1 |       |     0   (0)| 00:00:01 |
|   4 |   TABLE ACCESS FULL          | DEPT   |     4 |    80 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

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

   1 - access("D"."DEPTNO"="E"."DEPTNO")
   3 - access("EMPNO"=1)

17 rows selected.

SQL> explain plan for
  2  select  --+ ignore use_hash(d,e)
  3          *
  4    from  emp e,dept d
  5    where empno = 1
  6      and d.deptno = e.deptno
  7  /

Explained.

SQL> select * from table(dbms_xplan.display)
  2  /

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------
Plan hash value: 2385808155

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |     1 |    58 |     2   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |         |     1 |    58 |     2   (0)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| EMP     |     1 |    38 |     1   (0)| 00:00:01 |
|*  3 |    INDEX UNIQUE SCAN         | PK_EMP  |     1 |       |     0   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    20 |     1   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   3 - access("EMPNO"=1)
   5 - access("D"."DEPTNO"="E"."DEPTNO")

18 rows selected.

SQL> explain plan for
  2  select  --+ skip use_hash(d,e)
  3          *
  4    from  emp e,dept d
  5    where empno = 1
  6      and d.deptno = e.deptno
  7  /

Explained.

SQL> select * from table(dbms_xplan.display)
  2  /

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------
Plan hash value: 2385808155

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |     1 |    58 |     2   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |         |     1 |    58 |     2   (0)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| EMP     |     1 |    38 |     1   (0)| 00:00:01 |
|*  3 |    INDEX UNIQUE SCAN         | PK_EMP  |     1 |       |     0   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    20 |     1   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   3 - access("EMPNO"=1)
   5 - access("D"."DEPTNO"="E"."DEPTNO")

18 rows selected.

SQL> explain plan for
  2  select  --+ ignoreD use_hash(d,e)
  3          *
  4    from  emp e,dept d
  5    where empno = 1
  6      and d.deptno = e.deptno
  7  /

Explained.

SQL> select * from table(dbms_xplan.display)
  2  /

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------
Plan hash value: 373232351

---------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     1 |    58 |     4   (0)| 00:00:01 |
|*  1 |  HASH JOIN                   |        |     1 |    58 |     4   (0)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    38 |     1   (0)| 00:00:01 |
|*  3 |    INDEX UNIQUE SCAN         | PK_EMP |     1 |       |     0   (0)| 00:00:01 |
|   4 |   TABLE ACCESS FULL          | DEPT   |     4 |    80 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

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

   1 - access("D"."DEPTNO"="E"."DEPTNO")
   3 - access("EMPNO"=1)

17 rows selected.

SQL> explain plan for
  2  select  --+ skipPED use_hash(d,e)
  3          *
  4    from  emp e,dept d
  5    where empno = 1
  6      and d.deptno = e.deptno
  7  /

Explained.

SQL> select * from table(dbms_xplan.display)
  2  /

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------
Plan hash value: 373232351

---------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     1 |    58 |     4   (0)| 00:00:01 |
|*  1 |  HASH JOIN                   |        |     1 |    58 |     4   (0)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    38 |     1   (0)| 00:00:01 |
|*  3 |    INDEX UNIQUE SCAN         | PK_EMP |     1 |       |     0   (0)| 00:00:01 |
|   4 |   TABLE ACCESS FULL          | DEPT   |     4 |    80 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

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

   1 - access("D"."DEPTNO"="E"."DEPTNO")
   3 - access("EMPNO"=1)

17 rows selected.

SQL>  


SY.
12 окт 17, 21:41    [20865716]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
xtender
Member

Откуда: Мск
Сообщений: 4509
Почти нашел!
Вот https://jonathanlewis.wordpress.com/2011/01/16/ignoring-hints-4/
и оттуда по линкам дальше :)
12 окт 17, 23:15    [20865883]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
xtender
Member

Откуда: Мск
Сообщений: 4509
Так что все v$reserved_words будут всё ломать :)
а там-то полно всего...
+ и это только длиной в 1 символ
SQL> select keyword from v$reserved_words where length(keyword)<=1 order by length(keyword),keyword;

KEYWORD
----------
!
$
&
(
)
*
+
,
-
.
/
:
;
<
=
>
?
@
A
D
E
G
H
K
M
P
T
U
[
]
^
{
|
}

34 rows selected.
12 окт 17, 23:18    [20865893]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 4811
Я помогу творческим личностям которым некуда девать энергию. Продолжайте.

SQL> select --+ dbms_random.value rewrite_or_error
  2  * from t;

        ID
----------
         1

SQL> select --+ dbms_photoshop.value rewrite_or_error
  2  * from t;

        ID
----------
         1

SQL> select --+ dbms_random rewrite_or_error
  2  * from t;
* from t
       *
ERROR at line 2:
ORA-30393: a query block in the statement did not rewrite


SQL> select --+ dbms_photoshop rewrite_or_error
  2  * from t;
* from t
       *
ERROR at line 2:
ORA-30393: a query block in the statement did not rewrite


SQL> select --+ sys_guid() rewrite_or_error
  2  * from t;

        ID
----------
         1

SQL> select --+ sys_guid rewrite_or_error
  2  * from t;

        ID
----------
         1
13 окт 17, 00:27    [20865957]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
Valergrad
Member

Откуда:
Сообщений: 446
xtender
или хотя бы закомментируйте их


))))) Не, я когда вижу закомментированный код - сразу удаляю, у нас же гит есть для истории!
13 окт 17, 10:09    [20866333]     Ответить | Цитировать Сообщить модератору
 Re: Ошибочные хинты в запросе  [new]
Mercurial
Guest
Valergrad
у нас же гит есть для истории!

Херня твой гит.
13 окт 17, 10:23    [20866427]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить