Comments on: Quiz Night

By: Jonathan Lewis

Jonathan Lewis — Sun, 04 Oct 2009 10:05:44 +0000

Wolfgang,

The prize is the warm glow of satisfaction in a job well done that I have just conferred on you.

;)

By: Wolfgang

Wolfgang — Sat, 03 Oct 2009 17:55:57 +0000

Thanks a lot Jonathan. By the way – what did you say was the price? A signed book of the upcoming Cost Based II? Very generous ;)

Regards
Wolfgang

By: Jonathan Lewis

Jonathan Lewis — Sat, 03 Oct 2009 15:23:40 +0000

And the prize goes to …. (roll of drums, long pause that gets people irritated and does nothing to raise the atmosphere) Wolfgang.

This was just a simple example to demonstrate how easy it can be to think that “something’s gone wrong” because what you’re looking at isn’t 100% vanilla flavoured.

I am, however, impressed with the ingenuity used to come up with alternative reasons. I particularly liked the idea of the offline tablespace. (I tested it, it didn’t work because Oracle tried to obey the hint – but the optimizer can find a path that gets the right answer even when the “real” data happens to be offline.)

By: Charles Hooper

Charles Hooper — Sat, 03 Oct 2009 13:27:11 +0000

The index creation, view creation, and statistics gathering statements were lost in my previous post [Now fixed: JPL]. The view contained an INDEX() hint. Changing that hint to an INDEX_FFS() will result in an INDEX FAST FULL SCAN operation appearing in the plan. Another possibility uses two schemas, with a view potentially created to implement security that also contains hints, and a public synonym. In schema 1:


CREATE TABLE T1 AS
SELECT
  ROWNUM C1,
  ROWNUM*2 C2,
  LPAD(' ',500,' ') C3
FROM
  DUAL
CONNECT BY
  LEVEL <= 48000;

CREATE UNIQUE INDEX T1_PK ON T1(C1);
CREATE UNIQUE INDEX T1_N2 ON T1(C1,C2);

ALTER TABLE T1 MODIFY (
  C1 NOT NULL,
  C2 NOT NULL);

EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T1')

CREATE OR REPLACE VIEW T1_VIEW AS
SELECT /*+ INDEX_FFS(T1_V) */
  C1,
  C2
FROM
  (SELECT
    *
  FROM
    T1) T1_V;

CREATE OR REPLACE PUBLIC SYNONYM T1 FOR T1_VIEW;

GRANT SELECT ON T1_VIEW TO PUBLIC;
GRANT SELECT ON T1 TO PUBLIC;

In schema 2:


select /*+ full(t) */ count(*) from t1 t;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL)); 

Plan hash value: 1018460547

-----------------------------------------------------------------------
| Id  | Operation             | Name  | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------------
|   0 | SELECT STATEMENT      |       |       |    29 (100)|          |
|   1 |  SORT AGGREGATE       |       |     1 |            |          |
|   2 |   INDEX FAST FULL SCAN| T1_PK | 48000 |    29   (0)| 00:00:01 |
-----------------------------------------------------------------------

In schema 1:


DROP INDEX T1_PK;

In schema 2:


select /*+ full(t) no_index(t) */ count(*) from t1 t;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL)); 

Plan hash value: 177081169

-----------------------------------------------------------------------
| Id  | Operation             | Name  | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------------
|   0 | SELECT STATEMENT      |       |       |    38 (100)|          |
|   1 |  SORT AGGREGATE       |       |     1 |            |          |
|   2 |   INDEX FAST FULL SCAN| T1_N2 | 48000 |    38   (0)| 00:00:01 |
-----------------------------------------------------------------------

In schema 1:


DROP INDEX T1_N2;

In schema 2:


select /*+ full(t) */ count(*) from t1 t;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL)); 

Plan hash value: 3724264953

-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |  1015 (100)|          |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T1   | 48000 |  1015   (1)| 00:00:13 |
-------------------------------------------------------------------

By: Gary

Gary — Sat, 03 Oct 2009 00:53:31 +0000

Unless you are tricking us with the names, I’ll assume t1 is a table that had a separate t1_pk primary key index, which would discount an IOT. It would be interesting if the tablespace for t1 was offline and Oracle decided to override the hint and use an index on an available tablespace rather than fail the query.

By: Charles Hooper

Charles Hooper — Fri, 02 Oct 2009 20:09:34 +0000

What if T1 is not a table, but is actually a view with embedded hints?


CREATE TABLE T2 AS
SELECT
  ROWNUM C1,
  ROWNUM*2 C2,
  LPAD(' ',500,' ') C3
FROM
  DUAL
CONNECT BY
  LEVEL <= 48000;

CREATE UNIQUE INDEX T1_PK ON T2(C1);
CREATE UNIQUE INDEX T1_N2 ON T2(C1,C2);

ALTER TABLE T2 MODIFY (
  C1 NOT NULL,
  C2 NOT NULL);

CREATE OR REPLACE VIEW T1 AS
SELECT /*+ INDEX(T2) */
  C1,
  C2
FROM
  (SELECT
    *
  FROM
    T2) T2;

EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T2')

select /*+ full(t) */ count(*) from t1 t;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL)); 

Plan hash value: 1213398864

------------------------------------------------------------------
| Id  | Operation        | Name  | Rows  | Cost (%CPU)| Time     |
------------------------------------------------------------------
|   0 | SELECT STATEMENT |       |       |   101 (100)|          |
|   1 |  SORT AGGREGATE  |       |     1 |            |          |
|   2 |   INDEX FULL SCAN| T1_PK | 48000 |   101   (1)| 00:00:02 |
------------------------------------------------------------------

DROP INDEX T1_PK;

select /*+ full(t) */ count(*) from t1 t;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL)); 

Plan hash value: 824454759

------------------------------------------------------------------
| Id  | Operation        | Name  | Rows  | Cost (%CPU)| Time     |
------------------------------------------------------------------
|   0 | SELECT STATEMENT |       |       |   134 (100)|          |
|   1 |  SORT AGGREGATE  |       |     1 |            |          |
|   2 |   INDEX FULL SCAN| T1_N2 | 48000 |   134   (1)| 00:00:02 |
------------------------------------------------------------------

DROP INDEX T1_N2;

select /*+ full(t) */ count(*) from t1 t;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL)); 

Plan hash value: 3321871023

-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |  1015 (100)|          |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T2   | 48000 |  1015   (1)| 00:00:13 |
-------------------------------------------------------------------

By: mwidlake

mwidlake — Fri, 02 Oct 2009 19:27:22 +0000

Is it due to a “trick” that the CBO recognises that a count(*) is an attempt to simply know how many rows are in the table, and so the statement is re-written into a scan of the smallest index that contains a value for all rows (usually a unique index on mandatory columns, such as the PK index, or a bitmap index if one exists). Count(*), count(1) etc are so commonly used that it is worth the CBO having a specific check for it and conversion to the fastest wat to satisfy the query.

But I like Coskan’s answer too :-)

Martin

By: coskan

coskan — Fri, 02 Oct 2009 19:19:02 +0000

Can it be this parameter ? [sourcecode] SQL> alter session set "_optimizer_ignore_hints"=TRUE; Session altered. SQL> select /*+ full(t1)*/ count(object_id) from t1; COUNT(OBJECT_ID) ---------------- 65665 Execution Plan ---------------------------------------------------------- Plan hash value: 4103104450 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 5 | 41 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 5 | | | | 2 | INDEX FAST FULL SCAN| T1_IX | 65668 | 320K| 41 (0)| 00:00:01 | ------------------------------------------------------------------------------- [/sourcecode]

By: Wolfgang

Wolfgang — Fri, 02 Oct 2009 18:38:15 +0000

Well perhaps t is an IOT? And as a Fast Full Scan is a kind of FTS on an index, the hint is not really ignored.