Comments on: Analyze this

By: Blogroll Report 26/03 /2010 – 02/04/2010 « Coskan’s Approach to Oracle

Sun, 23 May 2010 22:21:34 +0000

[...] to use DBMS_STATS instead of analyze ? Jonathan Lewis-Analyze this Jonathan Lewis-Analyze this [...]

By: jametong

jametong — Sat, 03 Apr 2010 13:18:22 +0000

I do this test on my test db. os: Red Hat Enterprise Linux Server release 5.2 (Tikanga) Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production


--After analyze
-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes |TempSpc| Cost  |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      | 10000 |  3964K|       |   292 |
|*  1 |  HASH JOIN         |      | 10000 |  3964K|  3506K|   292 |
|   2 |   TABLE ACCESS FULL| T1   | 10000 |  1982K|       |    47 |
|   3 |   TABLE ACCESS FULL| T2   | 10000 |  1982K|       |    45 |
-------------------------------------------------------------------

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

   1 - access("T1"."ID"="T2"."ID")

Note
-----
   - cpu costing is off (consider enabling it)

--After using dbms_stats
-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes |TempSpc| Cost  |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      | 10000 |  4189K|       |   308 |
|*  1 |  HASH JOIN         |      | 10000 |  4189K|  3662K|   308 |
|   2 |   TABLE ACCESS FULL| T2   | 10000 |  2001K|       |    45 |
|   3 |   TABLE ACCESS FULL| T1   | 10000 |  2187K|       |    47 |
-------------------------------------------------------------------

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

   1 - access("T1"."ID"="T2"."ID")

Note
-----
   - cpu costing is off (consider enabling it)

By: Analyze This – 2 « Oracle Scratchpad

Analyze This – 2 « Oracle Scratchpad — Thu, 01 Apr 2010 20:00:14 +0000

[...] Statistics — Jonathan Lewis @ 7:58 pm UTC Apr 1,2010 If you’ve run the scripts from Analyze This, I hope you found that the query gave you two different execution plans. This is my output from the [...]

By: Flado

Flado — Thu, 01 Apr 2010 08:50:27 +0000

ANALYZE is not counting the length bytes?
The point being, bad statistics can have real, detrimental impact (in this case, slightly wrong hash join order) on execution plan quality even if we don’t use CPU costing?
By the way, extent sizing policy (auto vs. 1M) and free space management (ASSM vs. freelist) didn’t make any difference in my test (10.2.0.3 under RedHat).

Cheers,
Flado

By: dhhb

dhhb — Thu, 01 Apr 2010 06:08:07 +0000

I tested on my machine: 10.1.0.2.0 on Windows 32bit: [sourcecode] Analyze ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=349 Card=10000 Bytes=4060000) 1 0 HASH JOIN (Cost=349 Card=10000 Bytes=4060000) 2 1 TABLE ACCESS (FULL) OF 'T1' (TABLE) (Cost=76 Card=10000 Bytes=2030000) 3 1 TABLE ACCESS (FULL) OF 'T2' (TABLE) (Cost=73 Card=10000 Bytes=2030000) DBMS_STATS ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=365 Card=10000 Bytes=4290000) 1 0 HASH JOIN (Cost=365 Card=10000 Bytes=4290000) 2 1 TABLE ACCESS (FULL) OF 'T2' (TABLE) (Cost=73 Card=10000 Bytes=2050000) 3 1 TABLE ACCESS (FULL) OF 'T1' (TABLE) (Cost=76 Card=10000 Bytes=2240000) [/sourcecode] So looks like for analyze CBO will think the row length in the two tables are same but for DBMS_STATS will also consider the columns count, right?

By: Jonathan Lewis

Jonathan Lewis — Wed, 31 Mar 2010 21:35:43 +0000

Colin,

Read the first sentence – and then ask yourself what point I might have been trying to make a few years ago.

By: Colin 't Hart

Colin 't Hart — Wed, 31 Mar 2010 21:01:14 +0000

Isn’t the analyze command deprecated for gathering stats for the CBO?