一次分析的全过程,和大家交流!

eygle

Oracle9iR2是最后一个支持RBO的版本，Oracle10i将不再支持RBO，所以一切使用RBO的可以考虑作适当的转换了。

参考
Rule Based Optimizer is to be Desupported in Oracle10i
http://www.itpub.net/showthread.php?threadid=88905

SQL优化的方法是多种多样的，Oracle的COST就是在计算这些因素，当全表扫描优于索引扫描的时候Oracle自然会选择全表扫描。可是在CBO的优化上，Oralce是不值得完全信赖的，所以我们需要人为的介入。

在《Oracle 8优化技术》一书中，有如下说法：
• 非常喜欢O r a c l e，在于其具有灵活的可调节性。
• 非常厌恶O r a c l e，也在于其有灵活的可调节性。

实际上，只要能够达到可以接受的范围，那么我们的工作就是有效的。

没有最优，只有更优

Fenng

看你分析了半天,还不知道你的几个表的基本情况呢,

你的几个表各有多少数据阿?


优化分析怎么不考虑这个呢,呵呵,离开实际情况的分析怕是站不住脚

chao_ping

这个问题的Eygle的分析处理步骤和大家的进展，大家可以在china oracle user group SQL TUning那边找到。
看看问题的分析和尝试的步骤，还是蛮有意思的。

TOM

好

eygle

最初由 Fenng 发布
[B]看你分析了半天,还不知道你的几个表的基本情况呢,

你的几个表各有多少数据阿?


优化分析怎么不考虑这个呢,呵呵,离开实际情况的分析怕是站不住脚 [/B]

所作的优化是我们的生产数据库，这个问题是在开发中实际遇到的。

所以并非脱离实际，实际上，如果脱离实际要生成这样的结果也是不容易的

其实即使不知道表的基本情况和数据量，从执行计划中也是可以看出前后的变化及结果的!

SQL> select 'sp_item' table_name,count(*) num_rows from sp_item
  2  union
  3  select 'sp_trans' table_name,count(*) num_rows from sp_trans
  4  union
  5  select 'sp_trans_sub' table_name,count(*) num_rows from sp_trans_sub
  6  /

TABLE_NAME     NUM_ROWS
------------ ----------
sp_item           29821
sp_trans          34627
sp_trans_sub     136916

SQL> select table_name,num_rows
from user_tables where table_name in ('SP_ITEM','SP_TRANS','SP_TRANS_SUB');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
SP_ITEM                             29763
SP_TRANS                            34321
SP_TRANS_SUB                       136371

SQL>

hotmango

不错，eygle说的这番话非常有道理。ｏｒａｃｌｅ给我提供了非常灵活的选择方式。虽然ｒｂｏ推出舞台，但是我们也不能完全信任ｃｂｏ，具体情况还是要具体分析。


QUOTE]最初由 eygle 发布
[B]Oracle9iR2是最后一个支持RBO的版本，Oracle10i将不再支持RBO，所以一切使用RBO的可以考虑作适当的转换了。

参考
Rule Based Optimizer is to be Desupported in Oracle10i
http://www.itpub.net/showthread.php?threadid=88905

SQL优化的方法是多种多样的，Oracle的COST就是在计算这些因素，当全表扫描优于索引扫描的时候Oracle自然会选择全表扫描。可是在CBO的优化上，Oralce是不值得完全信赖的，所以我们需要人为的介入。

在《Oracle 8优化技术》一书中，有如下说法：
• 非常喜欢O r a c l e，在于其具有灵活的可调节性。
• 非常厌恶O r a c l e，也在于其有灵活的可调节性。

实际上，只要能够达到可以接受的范围，那么我们的工作就是有效的。

没有最优，只有更优 [/B][/QUOTE]

忍者神龟

这个china oracle user group在哪里？
cp师兄

最初由 chao_ping 发布
[B]这个问题的Eygle的分析处理步骤和大家的进展，大家可以在china oracle user group SQL TUning那边找到。
看看问题的分析和尝试的步骤，还是蛮有意思的。 [/B]

忍者神龟

最初由 huang0905 发布
[B]eygle:
     请详细介绍如何得出的 execution plan and statistics 结果，是否是从表 plan_table 中? [/B]

http://www.xiaomai.org/read.php?id=217

hiwanghao

When the Optimizer Uses Full Table Scans

The optimizer uses a full table scan in any of the following cases:

1.Lack of Access Paths: If the query is unable to use any existing indexes, then it uses a full table scan.
2.Large Amount of Data: If the optimizer thinks that the query will access most of the
blocks in the table, then it uses a full table scan, even though indexes might be
available.
3.Small Table: If a table contains less than DB_FILE_MULTIBLOCK_READ_COUNT
blocks under the high water mark, which can be read in a single I/O call, then a full
table scan might be cheaper than an index range scan, regardless of the fraction of
tables being accessed or indexes present.
4.Old Statistics :If the table has not been analyzed since it was created, and if it has less than DB_FILE_MULTIBLOCK_READ_COUNT blocks under the highwater mark,
then the optimizer thinks that the table is small and uses a full table scan. Look at
the LAST_ANALYZED and BLOCKS columns in the ALL_TABLES table to see what
the statistics reflect.

hiwanghao

Why a Full Table Scan Is Faster for Accessing Large Amounts of Data ?

Full table scans are cheaper than index range scans when accessing a large fraction
of the blocks in a table. This is because full table scans can use larger I/O calls, and
making fewer large I/O calls is cheaper than making many smaller calls.

The elapsed time for an I/O call consists of two components:
1. Call setup time (head seek time, rotational latency)
2. Data transfer time (typically 10 MB a second or better)

In a typical I/O operation, setup costs consume most of the time. Data transfer time
for an 8-K buffer is less than 1 msec (out of the total time of 10 msec). This means
that you can transfer 128 KB in about 20 msec with a single 128 KB call, as opposed
to needing 160 msec with sixteen 8-KB calls.

Example Full Table Scan Compared to Index Range Scan
Consider a case in which 20% of the blocks in a 10,000-block table are accessed. The
following are true:
DB_FILE_MULTIBLOCK_READ_COUNT = 16
DB_BLOCK_SIZE = 8 K
Number of 8 K I/O calls required for index access = 2,000 (table) + index
Number of 128 K I/O calls required for full table scan = 10,000/16 = 625

Assume that each 8 K I/O takes 10 msec, and about 20 seconds are spent doing
single block I/O for the table blocks. This does not include the additional time to
perform the index block I/O. Assuming that each 128 K I/O takes 20 msec, about
12.5 seconds are spent waiting for the data blocks, with no wait required for any
index blocks.