Nice example using the unusual hint that is mentioned in this blog article:
http://richardfoote.wordpress.com/2010/12/20/oracle11g-ignore_row_on_dupkey_index-hint-micro-cuts/

I think that your example is a demonstration of the third bullet point: “The hint is incompatible with another hint”. I enabled a 10053 trace for the INSERT statement that used the IGNORE_ROW_ON_DUPKEY_INDEX hint, and found this at the end of the trace file:

Dumping Hints
=============
  atom_hint=(@=000000044B3920D8 err=0 resol=0 <strong>used=0</strong> token=814 org=1 lvl=1 txt=APPEND ())
  atom_hint=(@=00000000216C9020 err=0 resol=1 <strong>used=1</strong> token=1735 org=1 lvl=3 txt=IGNORE_ROW_ON_DUPKEY_INDEX ())

The above suggests that the APPEND hint was not used, and that was confirmed by the execution plan which was printed in the 10053 trace file:

============
Plan Table
============
--------------------------------------------------+-----------------------------------+
| Id  | Operation                       | Name    | Rows  | Bytes | Cost  | Time      |
--------------------------------------------------+-----------------------------------+
| 0   | INSERT STATEMENT                |         |       |       |     2 |           |
| 1   |  LOAD TABLE CONVENTIONAL        |         |       |       |       |           |
| 2   |   COUNT                         |         |       |       |       |           |
| 3   |    CONNECT BY WITHOUT FILTERING |         |       |       |       |           |
| 4   |     FAST DUAL                   |         |     1 |       |     2 |  00:00:01 |
--------------------------------------------------+-----------------------------------+
Predicate Information:
----------------------
 
Content of other_xml column
===========================
  db_version     : 11.2.0.1
  parse_schema   : TESTUSER
  plan_hash      : 1731520519
  plan_hash_2    : 2585177905
  Outline Data:
  /*+
    BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('11.2.0.1')
      DB_VERSION('11.2.0.1')
      ALL_ROWS
      OUTLINE_LEAF(@"SEL$1")
      OUTLINE_LEAF(@"INS$1")
      FULL(@"INS$1" "T"@"INS$1")
      NO_CONNECT_BY_FILTERING(@"SEL$1")
      CONNECT_BY_COMBINE_SW(@"SEL$1")
    END_OUTLINE_DATA
  */

I experimented a little with your test case.

CREATE TABLE t (ID NUMBER, text VARCHAR2(10));
 
INSERT INTO t
 SELECT     ROWNUM, 'Test DML'
   FROM DUAL
CONNECT BY LEVEL <= 10;  
 
commit;

So I now have a table without a primary key constraint. Let’s try the test SQL statement (the full test script followed by the output below the line /* The output */):

INSERT      /*+ append
		     ignore_row_on_dupkey_index(t)
               */
INTO t
  SELECT ROWNUM, 'unique ig'
    FROM DUAL
  CONNECT BY LEVEL <= 13
  LOG ERRORS INTO err$_t REJECT LIMIT UNLIMITED;

ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';

/* The output */
                  *
ERROR at line 8:
ORA-38912: An index must be specified in the index hint

OK, that did not work since I do not have an index on the ID column, and the optimizer did not just use the APPEND hint and ignore the IGNORE_ROW_ON_DUPKEY_INDEX hint. Let’s try again:

CREATE INDEX IND_T_ID ON T(ID);

ALTER SESSION SET TRACEFILE_IDENTIFIER='IGNORE_HINT2';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';

INSERT      /*+ append
		     ignore_row_on_dupkey_index(t IND_T_ID)
               */
INTO t
  SELECT ROWNUM, 'unique ig'
    FROM DUAL
  CONNECT BY LEVEL <= 13
  LOG ERRORS INTO err$_t REJECT LIMIT UNLIMITED;

ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';

/* The output */
                  *
ERROR at line 8:
ORA-38913: Index specified in the index hint is invalid

That did not work either. Let’s try again, this time with a unique index:

DROP INDEX IND_T_ID;
 
CREATE UNIQUE INDEX IND_T_ID ON T(ID);

ALTER SESSION SET TRACEFILE_IDENTIFIER='IGNORE_HINT3';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';

INSERT      /*+ append
		     ignore_row_on_dupkey_index(t IND_T_ID)
               */
INTO t
  SELECT ROWNUM, 'unique ig'
    FROM DUAL
  CONNECT BY LEVEL <= 13
  LOG ERRORS INTO err$_t REJECT LIMIT UNLIMITED;

ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';

/* The output */
3 rows created.

In short, it appears that the IGNORE_ROW_ON_DUPKEY_INDEX hint is one index that refuses to be ignored.

Thank you for taking the time to put together the test case.

I just found another situation where a hint can be ignored; I don’t know also where to categorize it.

SQL> select * from v$version where rownum=1;

BANNER                                                                          
--------------------------------------------------------------------------------
Personal Oracle Database 11g Release 11.2.0.1.0 - Production                    

SQL> drop table t;

Table dropped.

SQL> drop table err$_t;

Table dropped.

SQL> CREATE TABLE t (ID NUMBER PRIMARY KEY, text VARCHAR2(10));

Table created.

SQL> INSERT INTO t
  2     SELECT     ROWNUM, 'Test DML'
  3           FROM DUAL
  4     CONNECT BY LEVEL <= 10;  

SQL> commit;

Commit complete.

SQL> exec DBMS_ERRLOG.create_error_log (dml_table_name => 't');

PL/SQL procedure successfully completed.

SQL> select count(1) from t;

  COUNT(1)                                                                      
----------                                                                      
        10                                                                      

SQL> select count(1) from err$_t;

  COUNT(1)                                                                      
----------                                                                      
         0                                                                      

SQL> INSERT      /*+ append */ INTO t
  2     SELECT ROWNUM, 'unique ap'
  3       FROM DUAL
  4  CONNECT BY LEVEL <= 13;
 
INSERT      /*+ append */ INTO t
*
ERROR at line 1:
ORA-00001: unique constraint (TESTUSER.SYS_C0028519) violated 
 
SQL> select count(1) from err$_t;

  COUNT(1)                                                                      
----------                                                                      
         0       

The DML Error logging doesn’t work with direct path load.

But let’s now use the new 11gR2 hint named ignore_row_on_dupkey_index as shown below:

SQL> INSERT      /*+ ignore_row_on_dupkey_index(t(id))
  2                           append
  3                    */
  4   INTO t
  5     SELECT ROWNUM, 'unique ig'
  6       FROM DUAL
  7   CONNECT BY LEVEL <= 13 
  8   LOG ERRORS INTO err$_t REJECT LIMIT UNLIMITED;
 
SQL> select count(1) from t;

  COUNT(1)                                                                      
----------                                                                      
        13                                                                      

SQL> rollback;

Rollback complete.

SQL> INSERT      /*+ append
  2  			     ignore_row_on_dupkey_index(t(id))
  3                    */
  4   INTO t
  5     SELECT ROWNUM, 'unique ig'
  6       FROM DUAL
  7   CONNECT BY LEVEL <= 13
  8   LOG ERRORS INTO err$_t REJECT LIMIT UNLIMITED;
 
3 rows created.

SQL> commit;

Commit complete.

The new hint ignore_row_on_dupkey_index makes the insert to silently ignore the hint append and to by passe the duplicate rows and to insert only new rows(3 rows)

Best Regards

Mohamed Houri

Mohamed

(Edited to fix the WordPress HTML problems when it encounters the LEVEL <= syntax)

Thanks for another great example of why it may appear that the optimizer ignored a hint – the optimizer never saw the hint. That is something that I did not consider. It might be interesting to see if that is why the AND_EQUAL hint was apparently “ignored” in this recent OTN thread: http://forums.oracle.com/forums/thread.jspa?threadID=1104424 (this is in a 9.2.0.8 database, while the AND_EQUAL hint is deprecated in 10g).

Your comment helped me find another possible cause for a hint to be “ignored” – initialization parameter settings. If an initialization parameter is set to explicitly disable a feature, a hint likely will not allow the optimizer to consider that feature (unless the hint explicitly sets an initialization parameter value). For example, if we start with the T15 table from above (I restricted it to 1,000,000 rows rather than 10,000,000):

UPDATE
  T15
SET
  C3=0
WHERE
  C3 IS NULL;
 
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T15',CASCADE=>TRUE)
 
ALTER TABLE T15 MODIFY (C3 NUMBER NOT NULL);

If we ask Oracle Database to count the rows in the table, it should use one of the indexes:

SET AUTOTRACE TRACEONLY EXPLAIN
 
SELECT
  COUNT(*)
FROM
  T15;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 877827156
 
----------------------------------------------------------------------------
| Id  | Operation             | Name       | Rows  | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |            |     1 |   282   (6)| 00:00:02 |
|   1 |  SORT AGGREGATE       |            |     1 |            |          |
|   2 |   INDEX FAST FULL SCAN| IND_T15_C3 |  1000K|   282   (6)| 00:00:02 |
----------------------------------------------------------------------------

We are able to hint a different execution plan without any trouble:

SELECT /*+ FULL(T15) */
  COUNT(*)
FROM
  T15;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 74626064
 
-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |  5485   (2)| 00:00:23 |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T15  |  1000K|  5485   (2)| 00:00:23 |
-------------------------------------------------------------------

Let’s set a hidden initialization parameter to its default value and retry the test SQL statement:

ALTER SESSION SET "_OPTIMIZER_IGNORE_HINTS"=FALSE;
 
SELECT /*+ FULL(T15) */
  COUNT(*)
FROM
  T15;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 74626064
 
-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |  5485   (2)| 00:00:23 |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T15  |  1000K|  5485   (2)| 00:00:23 |
-------------------------------------------------------------------

Now let’s try again with a modified value for the parameter:

ALTER SESSION SET "_OPTIMIZER_IGNORE_HINTS"=TRUE;
 
SELECT /*+ FULL(T15) */
  COUNT(*)
FROM
  T15;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 877827156

----------------------------------------------------------------------------
| Id  | Operation             | Name       | Rows  | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |            |     1 |   282   (6)| 00:00:02 |
|   1 |  SORT AGGREGATE       |            |     1 |            |          |
|   2 |   INDEX FAST FULL SCAN| IND_T15_C3 |  1000K|   282   (6)| 00:00:02 |
----------------------------------------------------------------------------

The optimizer ignored the index hint (because I told it to ignore the hint).

Another possibility of Oracle’s optimizer “ignoring” a hint is accomplished using a hacked stored outline, as in this example:
http://hoopercharles.wordpress.com/2009/12/18/tracking-performance-problems-inserting-a-hint-into-sql-in-a-compiled-program/

One might wonder what would happen if a hint was provided that stated to ignore hints (I believe that the recursive dynamic sampling SQL will include this hint). Will the hint to ignore hints be ignored?

ALTER SESSION SET "_OPTIMIZER_IGNORE_HINTS"=FALSE;
 
SELECT /*+ FULL(T15) */
  COUNT(*)
FROM
  T15;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 74626064
 
-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |  5485   (2)| 00:00:23 |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T15  |  1000K|  5485   (2)| 00:00:23 |
-------------------------------------------------------------------

The hint was followed, as expected. Now trying again:

SELECT /*+ IGNORE_OPTIM_EMBEDDED_HINTS FULL(T15) */
  COUNT(*)
FROM
  T15;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 877827156

----------------------------------------------------------------------------
| Id  | Operation             | Name       | Rows  | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |            |     1 |   282   (6)| 00:00:02 |
|   1 |  SORT AGGREGATE       |            |     1 |            |          |
|   2 |   INDEX FAST FULL SCAN| IND_T15_C3 |  1000K|   282   (6)| 00:00:02 |
----------------------------------------------------------------------------

Oracle “ignored” my hint (this may fall under bullet point 3).

I think what you mention is a good example of bullet point #5 that likely is not an obvious reason why Oracle’s optimizer would not be able to use the hint – when I wrote the article I was only considering the possibility of NULL values in a column that has an index. (Edit July 24, 2010: I just noticed that I wrote the word “need” rather than “not”. I probably should have stated that Mohamed’s comment is a very good example of bullet point #5.)

(a) The /*+ append */ hint is silently ignored when the inserted table contains triggers and/or Foreign key

Best Regards

Mohamed Houri

Thank you for the comments and the link. I forgot that the “Troubleshooting Oracle Performance” book had such a detailed section about using hints (I really need to finish the second read through of the book).

Another good reference to me is Troubleshooting Oracle Performance by Christian Antognini. Hints part of the book is available free to everybody for further reading on google books http://bit.ly/cKM2OE