CBO学习---第2章--表扫描（Tablescans）(九)
ion set "_optimizer_cache_stats" = false;
select count(*) from t1;
set autotrace off
在Cost上会略有影响，但是清理缓存后，计划仍然不变，是有些问题的，有待发展吧
/**************************************************************************************************************************************/
2.4 并行执行(Parallel Execution)
本章代码附件中：
[sql]
parallel.sql
关闭系统统计和CPU Cost计算，通过hint计算不同并行度下的Cost
by the way：在计划中，是无法看出并行度的，所有的计划都一样，只是Cost不同
本章代码附件中：
[sql]
parallel_2.sql
设置系统统计和开启CPU Cost计算，通过hint计算不同并行度下的Cost
得到下面的列表
[sql]
Degree 8i 9i (I/O) 10g (I/O) 9i (CPU) 10g (CPU)
Serial 1,518 1,519 1,519 5,031 5,030
2 1,518 760 844 2,502 2,779
3 1,518 507 563 1,668 1,852
4 1,518 380 422 1,252 1,389
5 1,518 304 338 1,002 1,111
6 1,518 254 282 835 926
7 1,518 217 242 716 794
8 1,518 190 211 627 695
8i中，Cost值不变的原因在于 "_optimizer_percent_parallel"=0 ，而9i中"_optimizer_percent_parallel"=101，该参数在0~101之间取值(10053的Resc~Resp)
[sql]
alter session set "_optimizer_percent_parallel"=0;
@parallel
10g中如此运行该脚本，所得Cost值就不变了
8i、9i、10g的IOCost计算公式如下：
[sql]
8i Cost at degree N = serial cost
9i Cost at degree N = ceil(serial cost / N )
10g Cost at degree N = ceil(serial cost / (0.9 * N))
10g比9i多了个0.9的因子
多用户并发时，通过参数parallel_adaptive_multi_user=ture来控制是否允许n个用户同时进行并行执行SQL，n是由隐藏参数"_parallel_adaptive_max_users"控制的，10g=2
[sql]
select x.ksppinm, y.ksppstvl, x.ksppdesc
from x$ksppi x , x$ksppcv y
where x.indx = y.indx
and y.inst_id = userenv('Instance')
and x.inst_id = userenv('Instance')
and x.ksppinm like '\_parallel_adaptive_max_users%' escape '\'
/
KSPPINM KSPPSTVL KSPPDESC
--------------------------------------------- ---------- ------------------------------------------------
_parallel_adaptive_max_users 2 maximum number of users running with default DOP
该参数貌似不能设置太大，而且执行时，可能还需要hint（有待研究，弄个并发工具先）；并且该参数是计算parallel_max_servers的参数之一
10g中，关闭系统统计的并行全表扫描，会直接进行路径读取（绕开缓冲区），为避免脏块，直读前检查点。
将parallel.sql中，set autotrace on，执行可以看到每次都是（10000 physical reads），缓存中已经有全部或者部分数据了，但依然会进行物理读取
11g中就已经改进了。(有待研究)
表中后两列值，是9i和10g启用系统统计(CPU Cost)，10g依然有0.9的计算因子；
并行度2的行2502几乎是5001的一半，但5001仅是IOCost，还有30的CPUCost丢失了？
其实并行仅仅是去直读，绕过了缓冲区，就消除了the CPU cost of locating,latching, and pinning a buffered block
/**************************************************************************************************************************************/
2.5 Index Fast Full Scan
Index Fast Full Scan与表的全表扫描类似，但索引是个有序的瘦表，包含一些无用信息（一列rowid和一些无意义的分枝块）。
但有时，快速扫描索引，比扫描数据后再排序更有效。
本章代码附件中：
[sql]
index_ffs.sql
hack_stats.sql
开通两个session，session1执行index_ffs.sql，session2执行hack_stats.sql，然后继续执行session1，查看Cost的变化
将m_numlblks := 4;改大一些（改到1000），效果更佳明显
通过修改索引不同的统计值，确认影响Index Fast Full Scan的基础参数是leaf_blocks
index_ffs.sql中有个模拟下面的场景（有待研究）
[sql]
Execution Plan ( 11.1.0.0 )
----------------------------------------------------------
0 SELECT STATEMENT Optimizer