http://space.itpub.net/17203031/viewspace-751151
目前,CBO(Cost-Based Optimizer)是Oracle默认使用的查询优化器Query Optimizer模式。在CBO中,SQL执行计划的生成,是以一种寻找成本(Cost)最优为目标导向的执行计划探索过程。所谓成本(Cost)就是将CPU和IO消耗整合起来的量化指标,每一个执行计划的成本就是经过优化器内部公式估算出的数字值。
与RBO(Rule-Based Optimizer)不同,CBO的灵活性建立在对数据统计量的强依赖关系上。CBO Query Optimizer工作的原料就是数据表、索引等对象统计量信息。在绝大部分情况下,CBO是可以帮助我们寻找到最优的执行计划的。但是,在一些特殊的场合下,CBO在估算方面存在一些问题,可能导致一些问题。本篇主要介绍Oracle中多列统计量估算偏差问题。
上篇中,我们介绍了Multi-Column/Column Group的使用。本篇中我们继续研究其中的本质问题。
4、Multi-Column本质论
在Oracle中,是怎么组织多列组的信息呢?我们首先从列统计量入手分析。
SQL> select column_name, num_distinct,SAMPLE_SIZE, AVG_COL_LEN, HISTOGRAM from user_tab_col_statistics where table_name='T';
COLUMN_NAM NUM_DISTINCT SAMPLE_SIZE AVG_COL_LEN HISTOGRAM
---------- ------------ ----------- ----------- ---------------
ID 3 5 3 FREQUENCY
NAME 4 5 3 FREQUENCY
SYS_STUIA0 4 5 12 FREQUENCY
V924QODN5R
5SCAKM60G#
在列中存在一个特殊列的统计信息,这里的列名同我们生成拓展统计量时候的那个字符串。
SQL> var vc_res varchar2(100);
SQL> exec :vc_res := dbms_stats.create_extended_stats('SCOTT','T','(id,name)');
PL/SQL procedure successfully completed
vc_res
---------
SYS_STUIA0V924QODN5R5SCAKM60G#
同时,Oracle也提供了一个视图user_stat_extensions来查看生成的拓展统计量。
SQL> select * from user_stat_extensions where extension_name = 'SYS_STUIA0V924QODN5R5SCAKM60G#';
TABLE_NAME EXTENSION_NAME EXTENSION CREATOR DROPPABLE
---------- ------------------------------ -------------------- ------- ---------
T SYS_STUIA0V924QODN5R5SCAKM60G#("ID","NAME") USER YES
那么,Oracle是不是同函数索引采用相同的内部策略,构建一个虚拟列进行管理呢?我们只有去到col$基表中进行检查。
SQL> select object_id from dba_objects where object_name='T' and wner='SCOTT';
OBJECT_ID
----------
75482
SQL> select col#, name,DEFAULT$ from col$ where obj#=75482;
COL# NAME DEFAULT$
---------- ---------- ------------------------------
1 ID
2 NAME
0 SYS_STUIA0 SYS_OP_COMBINED_HASH("ID","NAM
V924QODN5R E")
5SCAKM60G#
果然,此处显示的内容是:Oracle使用类似虚拟列的方法,构建了一个列。之后对这个列进行统计量收集。
5、Column Group的失效场景
在笔者的实验中,发现并不是建立了column group之后,所有的统计量估算都是正确的。起码当条件中存在非等号之后,拓展统计量估值是可能错误的。
SQL> exec dbms_stats.gather_table_stats(user,'EMP',cascade => true);
PL/SQL procedure successfully completed
--结果集合为3
SQL> select * from emp where job='MANAGER' and sal>2000;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
----- ---------- --------- ----- ----------- --------- --------- ------
7566 JONES MANAGER 78391981-4-2 2975.00 20
7698 BLAKE MANAGER 78391981-5-1 2850.00 30
7782CLARK MANAGER 78391981-6-9 2450.00 10
查看执行计划中的估算值。
SQL> explain plan for select * from emp where job='MANAGER' and sal>2000;
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3956160932
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1| 38 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP | 1| 38 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("JOB"='MANAGER' AND "SAL">2000)
13 rows selected
此时,我们收集一下拓展统计量。
SQL> var vc_res varchar2(1000);
SQL> exec :vc_res := dbms_stats.create_extended_stats('SCOTT','EMP','(job,sal)');
PL/SQL procedure successfully completed
vc_res
---------
SYS_STU73TUM4UV1A$7U9OVY05$MH6
SQL> select * from user_stat_extensions;
TABLE_NAME EXTENSION_NAME EXTENSION CREATOR DROPPABLE
---------- ------------------------------ -------------------- ------- ---------
EMP SYS_STU73TUM4UV1A$7U9OVY05$MH6 ("JOB","SAL") USER YES
SQL> exec dbms_stats.gather_table_stats(user,'EMP',method_opt => 'for columns (job,sal) size skewonly');
PL/SQL procedure successfully completed
SQL> select column_name, num_distinct,SAMPLE_SIZE, AVG_COL_LEN, HISTOGRAM from user_tab_col_statistics where table_name='EMP';
COLUMN_NAM NUM_DISTINCT SAMPLE_SIZE AVG_COL_LEN HISTOGRAM
---------- ------------ ----------- ----------- ---------------
(篇幅原因,有省略。。。。。。)
DEPTNO 3 14 3 FREQUENCY
SYS_STU73T 12 14 12 FREQUENCY
UM4UV1A$7U
9OVY05$MH6
此时,执行计划并没有改变。
SQL> explain plan for select * from emp where job='MANAGER' and sal>2000;
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3956160932
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 38 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP | 1| 38 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("JOB"='MANAGER' AND "SAL">2000)
13 rows selected
这说明拓展统计量在非等号情况下,是存在一些问题的。
6、其他注意问题和结论
此外,在使用column group上,我们还需要注意下面的问题:
ü 拓展列中不允许出现虚拟列(Virtual Column);
ü 不能对sys schema下的数据表列建立column group;
ü 不能对聚簇表(Cluster Table)、索引组织表(Index Organized Table)、临时表(Temporary Table)和外部表(External Table)上的列创建Column Group;
ü 一个数据表中创建的拓展列数目不能超过20和数据表10%非虚拟列的数目;
ü 一个拓展列组中包括了列数目位于2-32的范围内;
ü 一个列只能出现在一个拓展列组中;
ü 列组中不能包括表达式;
ü compatible参数必须在11.0.0.0以上;
最后,个人感觉在实际中,特别是开发环境下很少会使用到column group的功能。因为解决执行计划问题的手段很多,column group不是最优的方法。而在运维环境中,常常会遇到书写很糟糕的SQL和设计。此时运维人员通常没有机会修改SQL源代码。所以,column group作为一种运维手段,是可以进行尝试的。
1、环境准备
我们在Oracle 11g中进行试验。
SQL> select * from v$version;
BANNER
----------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0–Production
创建数据表T,并且按照常规方法收集统计量信息。
SQL> create table t (id number, name varchar2(100));
Table created
SQL> select * from t;
ID NAME
---------- ----------
1 TT
2 MT
3 FT
1 MM
1 TT
SQL> exec dbms_stats.gather_table_stats(user,'T',cascade => true);
PL/SQL procedure successfully completed
2、Multi-Columns估算偏差问题展现
此时,我们需要获取到id=1并且name=’TT’的记录。我们首先生成执行计划。
SQL> explain plan for select * from t where id=1 and name='TT';
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation | Name |Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 6 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T | 1| 6 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("NAME"='TT' AND "ID"=1)
13 rows selected
注意,从估算结果看,该SQL执行返回的Row Source数量为1。也就是说,Oracle优化器认为该SQL返回的结果数量为1。但是实际上数量是多少呢?
--实际运行结果
SQL> select * from t where id=1 and name='TT';
ID NAME
---------- ----------
1 TT
1 TT
这就是出现了执行计划与实际Row Source差异的现象。产生这种问题的原因,在于Oracle中默认只对单列进行统计量收集,而SQL中出现多列情况组合,就会发生问题。
具体来说,对数据表T,Oracle只会分别对列id和name进行统计量收集。在进行组合估算的时候,只会进行组合方式“剔除”结果集合。如果出现数据表T这种id=1和name=’TT’较多且符合的情况,估算出执行计划的row source就会有偏差出现。
Row source在执行计划成本公式中地位是很重要的,直接与进行逻辑物理读(Logical/Physical Get)数据块的个数相关,进而影响到Cost计算。如果发生Multi Columns估算问题,执行计划成本估算的cost就会相对较小。
公允的说,在大多数情况下,由于Multi Column统计量引起的执行计划错误问题是很少发生的。真正出现的场景是一些特殊的数据分布结构和查询方式上。如果深究这些问题,都能或多或少的存在数据库设计不合理或者应用开发不适当的问题。
在过去的Oracle版本中,Multi Column问题是不能处理的。在Oracle 11g中,我们可以使用Oracle拓展统计量(也称为Column Group)来解决这个问题。
3、Multi-Column和Column Group
Oracle 11g对统计量提供了多列统计量的拓展功能。也就是说,我们可以指定对多列数据制定一个列组(Column Group),针对这个列组进行统计量收集过程。
在11g的dbms_stats包中,添加了函数create_extended_stats,用于收集拓展统计量。
function create_extended_stats(
ownname varchar2,
tabname varchar2,
extension varchar2)
return varchar2;
具体使用上,步骤如下:
根据create_extended_stats方法的提示,要求compatible参数选取在11以上。
SQL> show parameter compatible
NAME TYPE VALUE
------------------------------------ ----------- -------------
compatible string 11.2.0.0.0
创建id和name共同构成的column group。
SQL> var vc_res varchar2(100);
SQL> exec :vc_res := dbms_stats.create_extended_stats('SCOTT','T','(id,name)');
PL/SQL procedure successfully completed
vc_res
---------
SYS_STUIA0V924QODN5R5SCAKM60G#
调用方法后,反馈回一个内部的编号。之后,我们重新收集统计量信息。
--可以让Oracle给Column Group收集直方图信息;
SQL> exec dbms_stats.gather_table_stats(user,'T',cascade => true,method_opt =>'for columns (id,name) size skewonly');
PL/SQL procedure successfully completed
SQL> explain plan for select * from t where id=1 and name='TT';
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2| 12 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T | 2| 12 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("NAME"='TT' AND "ID"=1)
13 rows selected
注意,此时Oracle执行计划正确的获得了结果集合row source信息。多列统计量生效。
那么,Oracle在内部是怎么进行组织和管理的呢?以及调用create_extend_stats方法获得到那个随机字符串是什么含义呢?我们下面继续进行探讨。
在CBO时代,执行计划决策过程完全取决于各个备选执行计划的成本预估算值。提高统计量精准度、优化CBO对于每个执行步骤的成本估算值是我们进行SQL优化的一个重要工作方向。
对Oracle是如何评估group by操作的,我们在前文《How CBO estimate the row source for group operation》(http://space.itpub.net/17203031/viewspace-751065)已经进行过比较详细的研究。
在前文中,我们发现,如果统计量存在的时候,单列group by的评估值就是数据列的distinct值。而多列group by的情况下,多列笛卡尔乘积代表了操作的结果极限情况。同时,Oracle考虑到了列相关性(Column Correlation)的问题,对笛卡尔积估算结果进行一定因子比例的收缩。
但是,无论如何评估,group by多列的情况下,都不能够实现精确的评估。
那么,我们有什么方法来解决这个问题呢?笔者猜测11g的“多列统计量”(Multi-Column Statistic)可以解决问题。本篇就进行这个尝试。
2、实验环境和对比研究
我们使用Oracle 11g进行试验,并且创建数据表T。
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> create table t as select * from dba_objects;
Table created
使用dbms_stats包收集统计量。
SQL> exec dbms_stats.gather_table_stats(user,'T',cascade => true);
PL/SQL procedure successfully completed
SQL> select column_name, num_distinct from dba_tab_columns where wner='SCOTT' and table_name='T';
COLUMN_NAME NUM_DISTINCT
------------------------------ ------------
OWNER 32
OBJECT_NAME 43924
SUBOBJECT_NAME 125
OBJECT_ID 72719
DATA_OBJECT_ID 7868
OBJECT_TYPE 44
CREATED 1087
(篇幅原因,省略部分……)
15 rows selected
统计量收集在column层面准确估算出列的distinct值。下面我们看执行计划情况。
SQL> explain plan for select owner, object_type, count(*) from t group by owner,object_type;
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 47235625
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 996 | 14940 | 268 (2)| 00:00:04 |
| 1 | HASH GROUP BY | | 996 | 14940 | 268 (2)| 00:00:04 |
| 2 | TABLE ACCESS FULL| T | 72718 | 1065K| 266 (1)| 00:00:04 |
---------------------------------------------------------------------------
9 rows selected
--经验公式:
分析:32×44/1.41421=995.61
但是语句真实执行的结果为:
SQL> set autotrace traceonly;
SQL> select /*+ gather_plan_statistics*/
2 owner, object_type, count(*)
3 from t
4 group by owner, object_type;
已选择266行。
SQL> select sql_id from v$sqlarea where sql_text like 'select /*+ gather_plan_statistics*/%';
SQL_ID
-------------
aa21h3vcy4ghw
SQL> select * from table(dbms_xplan.display_cursor(sql_id=>'aa21h3vcy4ghw',format => 'allstats last'));
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
SQL_ID aa21h3vcy4ghw, child number 0
-------------------------------------
select /*+ gather_plan_statistics*/ owner, object_type, count(*)
from t group by owner, object_type
Plan hash value: 47235625
--------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buff
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 266 |00:00:00.05 | 1
| 1 | HASH GROUP BY | | 1 | 996 | 266|00:00:00.05 | 1
| 2 | TABLE ACCESS FULL| T | 1 | 72718 | 72718 |00:00:00.12 | 1
--------------------------------------------------------------------------------
15 rows selected
差异存在比较大。下面尝试使用多列统计量。
3、多列统计量设置
Oracle 11g推出的多列统计量,就是应对多列相关性而导致的估算值不准的情况。在实现原理方面,多列统计量本质上就是创建一个虚拟信息统计列。
SQL> var vc_res varchar2(100);
SQL> exec :vc_res := dbms_stats.create_extended_stats ( user, 'T', '(owner,object_type)');
PL/SQL procedure successfully completed
vc_res
---------
SYS_STUXJ8K0YTS_5QD1O0PEA514IY
SQL> exec dbms_stats.gather_table_stats(user,'T',cascade => true,method_opt => 'for columns (owner,object_type) size skewonly');
PL/SQL procedure successfully completed
我们可以发现,在统计量中存在一个新的计量列。
SQL> select column_name, num_distinct from dba_tab_col_statistics where wner='SCOTT' and table_name='T';
COLUMN_NAME NUM_DISTINCT
------------------------------ ------------
(篇幅原因,省略部分……)
NAMESPACE 21
EDITION_NAME 0
SYS_STUXJ8K0YTS_5QD1O0PEA514IY 266
16 rows selected
SQL重新收集执行计划。
SQL> explain plan for select owner, object_type, count(*) from t group by owner, object_type;
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 47235625
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 266 | 3990 | 275 (2)| 00:00:04 |
| 1 | HASH GROUP BY | | 266| 3990 | 275 (2)| 00:00:04 |
| 2 | TABLE ACCESS FULL| T | 72719 | 1065K| 273 (1)| 00:00:04 |
---------------------------------------------------------------------------
9 rows selected
比对执行结果:
SQL> select sql_id from v$sqlarea where sql_text like 'select /*+ gather_plan_statistics*/%';
SQL_ID
-------------
aa21h3vcy4ghw
SQL> select * from table(dbms_xplan.display_cursor(sql_id=>'aa21h3vcy4ghw',format => 'allstats last'));
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
SQL_ID aa21h3vcy4ghw, child number 0
-------------------------------------
select /*+ gather_plan_statistics*/ owner, object_type, count(*)
from t group by owner, object_type
Plan hash value: 47235625
--------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buff
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 266 |00:00:00.05 | 1
| 1 | HASH GROUP BY | | 1 | 266 | 266|00:00:00.05 | 1
| 2 | TABLE ACCESS FULL| T | 1 | 72719 | 72719 |00:00:00.10 | 1
--------------------------------------------------------------------------------
15 rows selected
完全匹配成功。
4、结论
Oracle多列统计量是应对列相关性的重要优化手段。默认情况下,Oracle对数据列的收集不考虑相关性的。所以在多条件处理的时候,执行计划步骤中会存在不准的情况。
11g中,Oracle推出了新特性多列统计量,解决了由于多列相关性引起的估算不准确的问题。在本篇中,我们也证明了多列统计量在评估group by操作过程中的使用场景。
另一方面,多列统计量意味着更多的辅助统计量信息需要保存在数据字典中。所以在使用的时候,也要关注这部分数据的膨胀问题。