Comments on: Index size bug

By: Jonathan Lewis

Jonathan Lewis — Thu, 26 Jan 2012 21:09:03 +0000

Thanks for all the updates;

It looks like the estimated size is captured as a 32 bit number

There’s a very good reason for that – the test I ran was on a 32-bit version of Oracle. Although it ought to be possible to write code that copes with working out and reporting larger numbers on a 32-bit system, the code doesn’t cope.

By: raova

raova — Wed, 25 Jan 2012 14:34:05 +0000

[sourcecode] 14:01:54 ananda@SSUS> 14:01:54 nwcsprd_service@SSUS> 14:01:54 nwcsprd_service@SSUS> Plan hash value: 748043235 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | CREATE INDEX STATEMENT | | 10G| 102G| 4435K (4)| 17:14:52 | | 1 | INDEX BUILD NON UNIQUE| T1_V1 | | | | | | 2 | SORT CREATE INDEX | | 10G| 102G| | | | 3 | TABLE ACCESS FULL | T1 | 10G| 102G| 148K (99)| 00:34:41 | -------------------------------------------------------------------------------- Note ----- - estimated index size: 236G bytes 14 rows selected. Elapsed: 00:00:00.02 14:01:54 ananda@SSUS> select * from v$version; Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi PL/SQL Release 10.2.0.3.0 - Production CORE 10.2.0.3.0 Production TNS for Solaris: Version 10.2.0.3.0 - Production NLSRTL Version 10.2.0.3.0 - Production Elapsed: 00:00:00.23 14:05:50 ananda@SSUS> [/sourcecode]

By: raova

raova — Wed, 25 Jan 2012 14:28:12 +0000

looks like it has been fixed in 10.2.0.3 [sourcecode] 14:01:54 nwcsprd_service@SSUS> 14:01:54 nwcsprd_service@SSUS> Plan hash value: 748043235 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | CREATE INDEX STATEMENT | | 10G| 102G| 4435K (4)| 17:14:52 | | 1 | INDEX BUILD NON UNIQUE| T1_V1 | | | | | | 2 | SORT CREATE INDEX | | 10G| 102G| | | | 3 | TABLE ACCESS FULL | T1 | 10G| 102G| 148K (99)| 00:34:41 | -------------------------------------------------------------------------------- Note ----- - estimated index size: 236G bytes 14 rows selected. Elapsed: 00:00:00.02 14:01:54 ananda@SSUS> select * from v$version; Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi PL/SQL Release 10.2.0.3.0 - Production CORE 10.2.0.3.0 Production TNS for Solaris: Version 10.2.0.3.0 - Production NLSRTL Version 10.2.0.3.0 - Production Elapsed: 00:00:00.23 14:05:50 ananda@SSUS> ]]> [/sourcecode]

By: Radoslav Golian

Radoslav Golian — Sat, 07 Jan 2012 08:12:12 +0000

I tried it on 11.2.0.3.0 64bit Linux.. it seems to be fixed. [code] SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production PL/SQL Release 11.2.0.3.0 - Production CORE 11.2.0.3.0 Production TNS for Linux: Version 11.2.0.3.0 - Production NLSRTL Version 11.2.0.3.0 - Production exec dbms_stats.set_table_stats(ownname => user,tabname => 'T1', numrows => 10000e6); SQL> explain plan for 2 create index t1_v1 on t1(v1); Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 2170349088 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | CREATE INDEX STATEMENT | | 10G| 102G| 5212K (3)| 17:22:27 | | 1 | INDEX BUILD NON UNIQUE| T1_V1 | | | | | | 2 | SORT CREATE INDEX | | 10G| 102G| | | | 3 | TABLE ACCESS FULL | T1 | 10G| 102G| 150K(100)| 00:30:08 | -------------------------------------------------------------------------------- Note ----- - estimated index size: 239G bytes [/code]

By: oracleman consulting

oracleman consulting — Wed, 04 Jan 2012 18:37:26 +0000

wow
great catch

larry and the team owe you $ for doing QA on their RDBMS product

especially in the age or “big data” and operational DW DBs, this really could be a problem, not just trivia for internals-DBAs