Comments on: Quiz Night

By: to_char() « Oracle Scratchpad

to_char() « Oracle Scratchpad — Fri, 02 Dec 2011 07:49:17 +0000

[...] Here’s an odd little detail about the to_char() function that happened to show up in a little demonstration code I used to create some data for last Friday’s quiz night. [...]

By: IOT Answer « Oracle Scratchpad

IOT Answer « Oracle Scratchpad — Sun, 27 Nov 2011 22:04:03 +0000

[...] was good to see the answers to the last Quiz Night accumulating. The problem posed was simply this: I have two IOTs and I’ve inserted the same [...]

By: Pavol Babel

Pavol Babel — Sun, 27 Nov 2011 15:50:16 +0000

exactly. The execution plan is very misleading in this situation. It was quite clear CF is the most importan statistic in this case, but the situation is even worst thah I expected.
Great example by Jonathan and great observations by you :)

Regarda
Pavol Babel

By: Jonathan Lewis

Jonathan Lewis — Sun, 27 Nov 2011 10:49:43 +0000

GregG,
No; I wasn’t trying to do anything subtle or devious in this example.

By: Jonathan Lewis

Jonathan Lewis — Sun, 27 Nov 2011 10:48:42 +0000

Plenty of good comments here - and the answers are related to overflow. I'll be writing a follow-up posting this evening, or possibly tomorrow evening.

By: Vladimir Jelinek

Vladimir Jelinek — Sun, 27 Nov 2011 10:33:34 +0000

Hi Palo,
your are right. Optimizer could recognize that for table T3 he always hit v1 in PK. But apparently he doesn’t do such deep analysis and create the execution plan with same cost. In reality both execution plans has very different cost.

I posted my example later but, in fact I was motivated by Jonathan’s post from November 26, 2011 @ 10:01 am UTC. It’s apparent from it, that overflow segment is small just few hundreds block, so the crucial thing is clustering factor and additional logical read which results from it.

IMO the worst thing is how the execution plan is misleading, because when I see INDEX FAST FULL SCAN, I expecting SEQUENTIAL READS from index segment which is true for T3 table but in case of T4 I have the same execution plan but in reality I have few sequential reads from index segment and LOT of RANDOM READS from overflow segment. On the overflow segment bigger than buffer cache with bad clustering factor I will get many random physical reads and execution times will be very different.

By: Pavol Babel

Pavol Babel — Sat, 26 Nov 2011 21:56:49 +0000

Hi Vlado,

You posted your example later, but I have to admit your’s is more accurate, it better describes the CBO’s decision. I though CBO knew it didn’t have to visit OVERFLOW SEGMENT when “INCLUDING v1 OVERFLOW” was used (and the default PCTTHRESHOLD 50). CBO has enough information to consider that non-key column v1 will be always stored in PRIMARY INDEX part of IOT, because id1, id2 and v1 together will never reach 50% of 8192 (or event 4096 o 2048) byte block.
However optimizer obviously predicts the OVERFLOW SEGMENT inspection for every row when any non-key column is specified in SQL statement and it’s quite significant different from the runtime execution.

Regards
Pavol Babel

By: Vladimir Jelinek

Vladimir Jelinek — Sat, 26 Nov 2011 17:53:52 +0000

previous post wan't complete. Reposting: [sourcecode language="text"] DROP TABLE t1; CREATE TABLE t1 ( id1 NUMBER, id2 NUMBER, v1 VARCHAR2(40), v2 VARCHAR2(40), padding VARCHAR2(500) ) TABLESPACE dtest; INSERT INTO t1 SELECT mod(rownum,100), rownum, mod(rownum,100), rownum/100, lpad('A', 500, 'A') FROM dba_objects WHERE rownum <= 2000; DROP TABLE t3; CREATE TABLE t3 ( id1 NUMBER, id2 NUMBER, v1 VARCHAR2(40), v2 VARCHAR2(40), padding VARCHAR2(500), CONSTRAINT t3_pk PRIMARY KEY(id1,id2) ) ORGANIZATION INDEX INCLUDING v1 OVERFLOW TABLESPACE dtest; DROP TABLE t4; CREATE TABLE t4 ( id1 NUMBER, id2 NUMBER, v1 VARCHAR2(40), v2 VARCHAR2(40), padding VARCHAR2(500), CONSTRAINT t4_pk PRIMARY KEY(id1,id2) ) ORGANIZATION INDEX INCLUDING id2 OVERFLOW TABLESPACE dtest; INSERT INTO t3 select * from t1; COMMIT; INSERT INTO t4 select * from t1; COMMIT; -- gather stats TABLE_NAME IOT_NAME BLOCKS LAST_ANALY ------------------------------ ------------------------------ ---------- ---------- SYS_IOT_OVER_75386 T3 143 26.11.2011 SYS_IOT_OVER_75389 T4 143 26.11.2011 T1 158 26.11.2011 T3 26.11.2011 T4 26.11.2011 INDEX_NAME BLEVEL LEAF_BLOCKS AVG_LPK AVG_DPK CLUF ------------------------------ ---------- ----------- ---------- ---------- ---------- T3_PK 1 13 1 1 2000 T4_PK 1 8 1 1 2000 SQL> select max(v1) from t3; Execution Plan ---------------------------------------------------------- Plan hash value: 3180047932 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 3 | 2005 (0)| 00:00:25 | | 1 | SORT AGGREGATE | | 1 | 3 | | | | 2 | INDEX FAST FULL SCAN| T3_PK | 2000 | 6000 | 2005 (0)| 00:00:25 | ------------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 1 recursive calls 0 db block gets 62 consistent gets 0 physical reads 0 redo size 217 bytes sent via SQL*Net to client 239 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL> select max(v1) from t4; Execution Plan ---------------------------------------------------------- Plan hash value: 2975522427 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 3 | 2004 (0)| 00:00:25 | | 1 | SORT AGGREGATE | | 1 | 3 | | | | 2 | INDEX FAST FULL SCAN| T4_PK | 2000 | 6000 | 2004 (0)| 00:00:25 | ------------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 2041 consistent gets 0 physical reads 0 redo size 224 bytes sent via SQL*Net to client 239 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed [/sourcecode]

By: Vladimir Jelinek

Vladimir Jelinek — Sat, 26 Nov 2011 17:22:01 +0000

Finaly I have option to test on DB. I stick to my original idea of different including clause. It's pretty close to original numbers. The crucial point is clustering factor. So the testing has to be generated so that Oracle can't use blocks from overflow area physical order, but has to jump between them for each row from primary key. It leads to 2000 gets. My testcase: [sourcecode] TABLESPACE 8k, UNIFORM , MANUAL DROP TABLE t1; CREATE TABLE t1 ( id1 NUMBER, id2 NUMBER, v1 VARCHAR2(40), v2 VARCHAR2(40), padding VARCHAR2(500) ) TABLESPACE dtest; INSERT INTO t1 SELECT mod(rownum,100), rownum, mod(rownum,100), rownum/100, lpad('A', 500, 'A') FROM dba_objects WHERE rownum select max(v1) from t3; Execution Plan ---------------------------------------------------------- Plan hash value: 3180047932 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 3 | 2005 (0)| 00:00:25 | | 1 | SORT AGGREGATE | | 1 | 3 | | | | 2 | INDEX FAST FULL SCAN| T3_PK | 2000 | 6000 | 2005 (0)| 00:00:25 | ------------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 1 recursive calls 0 db block gets 62 consistent gets 0 physical reads 0 redo size 217 bytes sent via SQL*Net to client 239 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL> select max(v1) from t4; Execution Plan ---------------------------------------------------------- Plan hash value: 2975522427 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 3 | 2004 (0)| 00:00:25 | | 1 | SORT AGGREGATE | | 1 | 3 | | | | 2 | INDEX FAST FULL SCAN| T4_PK | 2000 | 6000 | 2004 (0)| 00:00:25 | ------------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 2041 consistent gets 0 physical reads 0 redo size 224 bytes sent via SQL*Net to client 239 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed [/sourcecode]

By: Pavol Babel

Pavol Babel — Sat, 26 Nov 2011 16:53:06 +0000

Well, 4. is not correct. It is was just easier fo me to simulate CF 2000 for T3_PK and T4_PK with overflow semgents at size of 2000 blocks.

One more remark. It is not important whether jonathan’s T1 is heap table, IOT, hash cluster, or whatever. So I dind’t use SELECT insetad of t1 im my examples

Regards
Pavol Babel