12.2统计信息之管理统计信息

除了收集合适的统计信息,提供一个管理这些统计信息的综合架构同样重要。oracle提供了多个方法去做这些工作,包括恢复统计信息到以前的版本,提供从一个系统迁移统计信息到另外一个的选项,甚至你可以手动设置统计信息。这些选项在某些特定情形下都非常有用,但是仍然建议都通过DBMS_STATS包来收集统计信息。

恢复统计信息

当你用DBMS_STATS包来收集统计信息时,原来的统计信息会自动备份存储在字典表里,如果新生成的统计信息有问题则能很容易的通过DBMS_STATS.RESTORE_TABLE_STATS恢复之前的统计信息。视图DBA_TAB_STATS_HISTORY包含多个时间点保存的统计信息。

下面这个例子恢复了表t的统计信息至昨天,并自动使shared pool里所有涉及到T表的游标都失效。因为恢复了昨天的统计信息,所以想立刻想使用昨天的统计信息来影响新的游标。参数NO_INVALIDATE的值决定了表T相关的游标是否要失效。

1
2
3
4
5
6
7
8
BEGIN 
DBMS_STATS.RESTORE_TABLE_STATS(ownname => 'SYS',
tabname => 'T',
as_of_timestamp => SYSTIMESTAMP-1,
force => FALSE,
no_invalidate => FALSE);
END;
/

挂起统计信息

默认情况下,当统计信息收集以后,它们将会立刻被写入到数据字典表然后立刻被优化器所使用。从11g开始,oracle支持收集完统计信息以后不立即写入字典表,而是先存储在挂起表中,这样就可以在正式使用之前先进行测试。这些挂起统计信息可以对单个会话进行启用,以一种可控的方式让你在应用这些统计信息之前先进行验证。为了激活挂起统计信息的收集,需要使用DBMS_STATS.SET_*_PREFS其中的过程来改变PUBLISH参数的值从TRUE(默认值)变成FALSE

1
exec DBMS_STATS.SET_TABLE_PREFS('SYS', 'T', 'PUBLISH', 'FALSE');

跟之前一样正常收集统计信息

1
EXEC DBMS_STATS.GATHER_TABLE_STATS('SYS', 'T');

这时收集的统计信息都会储存在USER_*_PENDING_STATS数据字典中,可以指定优化器去使用这些挂起统计信息,通过ALTER SESSION命令去设置初始化参数OPTIMIZER_USE_PENDING_STATSTRUE然后运行sql。对于sql中那些没有挂起统计信息的表来说,优化器会自动选择它们当前存储在字典表的信息。当你启用了这些挂起统计信息,也可以通过DBMS_STATS.PUBLISH_PENDING_STATS去发布它们,将它们写入正式的数据字典当中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
sys@ORA12C> INSERT INTO T select * from t;                       >>>>==== 手动插入一些数据

55 rows created.

sys@ORA12C> commit;

Commit complete.

sys@ORA12C> EXEC DBMS_STATS.GATHER_TABLE_STATS('SYS', 'T');

PL/SQL procedure successfully completed.

sys@ORA12C> select table_name,NUM_ROWS ,BLOCKS ,LAST_ANALYZED from user_tables where table_name='T';

TABLE_NAME NUM_ROWS BLOCKS LAST_ANALYZED
-------------------- ---------- ---------- -------------------
T 55 1 2018-12-13 16:58:16 >>>>====旧的统计信息

sys@ORA12C> select table_name,NUM_ROWS ,BLOCKS ,LAST_ANALYZED from user_tab_pending_stats where table_name='T';

TABLE_NAME NUM_ROWS BLOCKS LAST_ANALYZED
-------------------- ---------- ---------- -------------------
T 110 1 2018-12-18 15:13:14 >>>>===挂起统计信息里显示正确的110行

更新挂起统计信息至正式表

1
2
3
4
5
6
7
8
9
10
11
12
13
sys@ORA12C> Exec dbms_stats.publish_pending_stats('SYS', 'T');

PL/SQL procedure successfully completed.

sys@ORA12C> select table_name,NUM_ROWS ,BLOCKS ,LAST_ANALYZED from user_tables where table_name='T';

TABLE_NAME NUM_ROWS BLOCKS LAST_ANALYZED
-------------------- ---------- ---------- -------------------
T 110 1 2018-12-18 15:13:14 >>>>====数据正确

sys@ORA12C> select table_name,NUM_ROWS ,BLOCKS ,LAST_ANALYZED from user_tab_pending_stats where table_name='T';

no rows selected

如果不想使用新的统计信息,可以直接删掉

1
Exec dbms_stats.delete_pending_stats('SYS', 'T');

导入导出统计信息

统计信息可以从一个库复制到另一个,比如在准生产环境通过从别的库复制过来的统计信息进行性能测试是很有用的。复制的时候是通过DBMS_STATS.EXPORT_*_STATSDBMS_STATS.IMPORT_*_STATS过程来实现。

在导出统计信息之前,你需要先通过DBMS_STATS.CREATE_STAT_TABLE创建一张表来储存这些信息。当表创建完毕以后,你就可以通过DBMS_STATS.EXPORT_*_STATS过程来将统计信息导出,当这些统计信息打包到表里以后,你就可以通过数据泵的方式将表的数据从生产环境导入到测试环境。当表导入测试数据库以后,就可以通过DBMS_STATS.IMPORT_*_STATS将统计信息导入字典当中。

1
2
3
4
5
exec DBMS_STATS.CREATE_STAT_TABLE('SYS','T','USERS');

exec dbms_stats.EXPORT_DATABASE_STATS('T','ST_TEST','SYS');

exec dbms_stats.IMPORT_DATABASE_STATS('T','ST_TEST','SYS');

复制分区统计信息

当处理分区表时,优化器需要同时依赖整表和单独分区的统计信息用于得到一个更优的执行计划。如果sql只需要访问单独的分区,优化器则只采用单独分区的统计信息。如果需要访问多个分区,则优化器会采用全局统计信息。

经常会有这样的场景,分区表增加分区,数据只会插入这个新分区。如果用户在这个分区收集统计信息之前去查询这些数据,那很可能就会得到一个比较差的执行计划。又一个很常见的场景就是传入谓词条件的值超过了列统计信息的最大值和最小值之间的范围,这就是被熟知的超出范围错误。在这种情况下,优化器根据谓词与最大值之间的距离来分配选择性(假设传参超过了最大值),谓词值与最大值或最小值越远,那么值的选择性就越低。

超出范围情况能通过DBMS_STATS.COPY_TABLE_STATS过程来避免,这个过程能将源分区的统计信息复制到新建的统计信息为空的分区中去。同时复制了依赖对象的统计信息:字段、本地索引等。分区字段的最小值和最大值按照如下进行调整:

  • 如果分区类型是HASH则目标分区的最大值和最小值和源分区一致
  • 如果分区类型是LIST并且目标分区不是一个默认分区,则目标分区的最小值设成用来定义分区的LIST值中的最小值,最大值就是LIST值中的最大值
  • 如果分区类型是LIST并且目标分区是一个默认分区,则目标分区的最小值设成源分区的最小值,目标分区的最大值设成源分区的最大值
  • 如果分区类型是RANGE,则目标分区的最小值设成前一个分区的上限值,目标分区的最大值设成定义目标分区的RANGE最大值,而如果RANGE最大值是MAXVALUE时,目标分区的最大值则设成前一个分区的上限值

可以根据给定的scale_factor参数来缩放统计信息(比如块的数量、行数等)。统计信息中像行的平均长度和唯一值数量并未进行调整,而是认为在目标分区中是相同的。

SALES_Q3_2011范围分区当中的统计信息复制到SALES_Q4_2011,设置缩放因子为2来缩放基础统计信息

1
EXEC DBMS_STATS.COPY_TABLE_STATS('SH','SALES','SALES_Q3_2002','SALES_Q4_2002', 2);

只有在索引分区名称与表分区名称一样时才会复制索引信息(默认值),全局统计信息默认情况下并不会更新。只有在全局统计信息不存在并且通过聚合生成了全局统计信息时,才能通过DBMS_STATS.COPY_TABLE_STATS过程影响全局统计信息。

统计信息比较

一个系统的执行计划于另一个系统不一样的一个重要原因就是优化器统计信息不一样。比如如果数据没有同步,测试环境的统计信息很可能就与生产环境的不一样。为了确定统计信息之间的差异,可以通过DBMS_STATS.DIFF_TABLE_STATS_*函数来比较两个源。A下面的表可以和B下面的表进行比较,同样可以对一个表的不同时间点的统计信息比较,或者当前统计信息与挂起统计信息比较。比如比较当前时间和昨天

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
sys@ORA12C> select report, maxdiffpct from dbms_stats.diff_table_stats_in_history(user, 'T', SYSDATE-1, SYSDATE, 2);

REPORT
---------------------------------------------------------------------------------------------
MAXDIFFPCT
----------
###############################################################################

STATISTICS DIFFERENCE REPORT FOR:
.................................

TABLE : T
OWNER : SYS
SOURCE A : Statistics as of 18-DEC-18 11.03.39.000000 AM +08:00
SOURCE B : Statistics as of 19-DEC-18 11.03.39.000000 AM +08:00
PCTTHRESHOLD : 2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TABLE / (SUB)PARTITION STATISTICS DIFFERENCE:
.............................................

OBJECTNAME TYP SRC ROWS BLOCKS ROWLEN SAMPSIZE
...............................................................................

T T A 55 1 3 55
B 110 1 3 110
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

COLUMN STATISTICS DIFFERENCE:
.............................

COLUMN_NAME SRC NDV DENSITY HIST NULLS LEN MIN MAX SAMPSIZ
...............................................................................

ID A 10 .009090909 YES 0 3 80 C10A 55
B 10 .004545454 YES 0 3 80 C10A 110
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


NO DIFFERENCE IN INDEX / (SUB)PARTITION STATISTICS
###############################################################################

比较不同库的两张表统计信息其实跟导入导出统计信息类似,也是将其中一个系统的表统计信息导出表然后导入第二个系统进行比较

最后通过dbms_stats.diff_table_stats_in_stattab完成

1
select report from dbms_stat.diff_table_stats_in_stattab( 'SCOTT', 'EMP', 'STAT_TAB_OLD', 'STAT_TAB_NEW');

DIFF函数同时比较依赖对象(索引、分区、列)的统计信息,如果统计信息之间的差异超过了阀值则会列出源端目标端对象的所有的统计信息。这个阀值可以作为入参传入,默认值是10%。计算的时候以源端统计信息作为基数。

锁定统计信息

有些情况下,你希望通过锁定表或者方案的统计信息来避免重新收集时产生影响。当统计信息被锁定后,任何操作都无法修改这些信息除非你重新解锁或则收集统计信息时设置FORCE参数为TRUE

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
sys@ORA12C> exec DBMS_STATS.LOCK_TABLE_STATS('SYS', 'T');

PL/SQL procedure successfully completed.

sys@ORA12C> EXEC DBMS_STATS.GATHER_TABLE_STATS('SYS', 'T');
BEGIN DBMS_STATS.GATHER_TABLE_STATS('SYS', 'T'); END;

*
ERROR at line 1:
ORA-20005: object statistics are locked (stattype = ALL)
ORA-06512: at "SYS.DBMS_STATS", line 36873
ORA-06512: at "SYS.DBMS_STATS", line 36507
ORA-06512: at "SYS.DBMS_STATS", line 8582
ORA-06512: at "SYS.DBMS_STATS", line 9461
ORA-06512: at "SYS.DBMS_STATS", line 35836
ORA-06512: at "SYS.DBMS_STATS", line 36716
ORA-06512: at line 1


sys@ORA12C> EXEC DBMS_STATS.GATHER_TABLE_STATS('SYS', 'T',force=>TRUE);

PL/SQL procedure successfully completed.

也可以锁定分区级别的统计信息

1
EXEC DBMS_STATS.LOCK_PARTITION_STATS('SH', 'SALES', 'SALES_Q3_2000');

需要注意锁定统计信息的层次问题,比如如果锁定了一个分区表统计信息,然后为了单独搜集一个分区的统计信息而将这个分区统计信息进行解锁,则会报错ORA-20005。因为即使分区锁被解锁了,表级锁仍然存在。所以为了统计单独分区只能通过设置FORCE为TRUE。

手动设置统计信息

在罕见的情况下,手动设置数据字典里的统计信息可能会很有帮助。比如全局临时表的统计信息。可以手动通过DBMS_STATS.SET_*_STATS来收集。

12.2统计信息之分区表

分区表上的统计信息要同时计算表级别和分区级别,11g以前新增一个分区或者修改少数分区的数据需要扫描整张表去刷新表的统计信息。如果跳过收集全局统计信息,那么优化器则会根据分区级别的统计信息去推断全局级别的统计信息。这种方法对于简单的表统计信息(例如行数)是准确的——通过聚合所有分区的行数,但是其他的统计信息就无法准确的推断。比如无法从每个分区独立的信息来准确推断出一个字段的唯一值记录(优化器使用的最重要统计信息之一)。

oracle 11g开始加强了这部分的统计信息收集手段,引入了增量全局统计信息。如果分区表的INCREMENTAL选项设置为true,DBMS_STATS.GATHER_*_STATSGRANULARITY参数包含GLOBAL,并且ESTIMATE_PERCENT设置成AUTO_SAMPLE_SIZE,Oracle 会对新的分区收集信息,并且通过只扫描那些新增或进行修改了的分区从而准确的更新全局统计信息,这时就不需要扫描全表。

增量全局统计信息会对每个分区储存_概要_,_概要_表示分区和分区字段的元数据。每个概要都是储存在SYSAUX表空间。然后通过聚合每个分区级别的统计信息和分区概要来收集全局统计信息,因此就不需要扫描整张表来收集表级别统计信息。当一个新分区添加到表中,你只需要收集单个分区的统计信息,全局统计信息会自动维护和使用新分区的概要来准确更新数据。

注意INCREMENTAL统计信息并不适用子分区,子分区和分区上的信息收集就跟正常的一样。只有分区上的统计信息用于更新全局或表级别的信息时,增量才有用。下面是如何使用增量统计信息

开启增量统计信息

1
EXEC DBMS_STATS.SET_TABLE_PREFS('SH', 'SALES', 'INCREMENTAL', 'TRUE');

跟平常一样收集,ESTIMATE_PERCENTGRANULARITY都是默认值

1
exec DBMS_STATS.GATHER_TABLE_STATS('SH', 'SALES');

检查当前INCREMENTAL

1
SELECT DBMS_STATS.GET_PREFS('INCREMENTAL', 'SH', 'SALES') FROM dual;

增量统计信息和过期

11g时,如果一个表上启用了增量统计信息,当一个分区的一行更新后,那么这个分区上的统计信息就被认为是过期的,如果要生成全局信息则必须要重新收集这个分区的统计信息。

12c有一个新的选项INCREMENTAL_STALENESS,能让你去控制什么时候分区统计信息被认为是过期的或者已经不适合用来生成全局统计信息了。默认这个值是NULL,表示分区有值变更时就立刻认为是过期(跟11g一样)。

它也可以设成USE_STALE_PERCENT或者USE_LOCKED_STATS,USE_STALE_PERCENT,表示变化的行数所占百分比小于设置的STALE_PRECENTAGE值时(默认10%),分区级别的统计信息一直被认为可用。USE_LOCKED_STATS表示如果一个分区的统计信息被锁定了,那么它就可以被用来生成全局统计信息而不用考虑这个分区从上次收集统计信息到现在有多少行记录做了变更。

给表ORDER_DEMO设置USE_STALE_PERCENT

1
2
3
4
5
6
7
8
BEGIN
DBMS_STATS.SET_TABLE_PREFS (
ownname => 'OE',
tabname => 'ORDERS_DEMO',
pname => 'INCREMENTAL_STALENESS',
pvalue => 'USE_STALE_PERCENT');
END;
/

修改默认的10%到20%

1
2
3
4
5
6
7
8
BEGIN
DBMS_STATS.SET_TABLE_PREFS (
ownname => 'OE',
tabname => 'ORDERS_DEMO',
pname => 'STALE_PERCENT',
pvalue => 20);
END;
/

分区表统计信息锁定的情况

给表ORDER_DEMO设置USE_LOCKED_STATS

1
2
3
4
5
6
7
8
BEGIN
DBMS_STATS.SET_TABLE_PREFS (
ownname => 'OE',
tabname => 'ORDERS_DEMO',
pname => 'INCREMENTAL_STALENESS',
pvalue => 'USE_LOCKED_STATS');
END;
/

给表ORDER_DEMO同时设置USE_STALE_PERCENT和USE_LOCKED_STATS

1
2
3
4
5
6
7
8
BEGIN
DBMS_STATS.SET_TABLE_PREFS (
ownname => 'OE',
tabname => 'ORDERS_DEMO',
pname => 'INCREMENTAL_STALENESS',
pvalue => 'USE_STALE_PERCENT,USE_LOCKED_STATS');
END;
/

增量统计和分区加载交换

分区的一个好处就是能快速而方便的加载数据,通过exchange partition命令能最小化对用户的影响。exchange partition命令可以让非分区表的数据交换到分区表中的指定分区。这个命令不是物理移动数据,而是更新数据字典交换指针从分区到表,反之亦然。

在之前的版本当中,是无法在分区交换的过程中对非分区表生成必要的统计信息用于支持增量统计信息。而是必须在分区交换动作完成以后才能收集,为了确保全家统计信息能被增量维护。

在12c中,必要的统计信息(概要)可以在交换之前就创建在非分区表上,所以在分区交换的过程中统计信息也被交换用于自动维护增量的全家统计信息。新的DBMS_STATS表选项INCREMENTAL_LEVEL可以被用来去确定一个将要做加载交换的非分区表。INCREMENTAL_LEVEL设成TABLE时(默认PARTITION),oracle将在收集统计信息时自动为表创建概要。这个表级别的概要将在分区交换完毕后变成分区的概要。

1
2
exec dbms_stats.set_table_prefs ('SH','EXCHANGETAB','INCREMENTAL','TRUE');
exec dbms_stats.set_table_prefs ('SH','EXCHANGETAB','INCREMENTAL_LEVEL','TABLE');

概要增强

对于那些含有大量分区表的数据仓库应用来说,增量维护节省了大量的时间。然而带来了性能上的收益却也伴随这磁盘费用的增加:概要信息都是储存在SYSAUX表空间,需要越来越多的磁盘用来存储那些超多分区、超多字段、特别是那些字段唯一性特别高的表的概要。除了磁盘的消耗,你必须也要考虑到维护大量概要信息所带来的资源消耗。

从12.2开始,DBMS_STATS包提供了对于收集唯一值信息的新算法,在精确度与以前相似的条件下产生少的多的概要。

DBMS_STATS的新选项APPROXIMATE_NDV_ALGORITHM用来控制创建哪种概要。默认值是REPEAT OR HYPERLOGLOG,表示那些已存在的自适应采用算法将适用于已存在的概要,但是新概要都通过新的HYPERLOGLOG算法。在同一张表中可以混合新旧算法同时使用。

当将一个12.2之前的版本升级到12.2(使用增量信息)时,有三个选项:

1.继续使用12.2以前的格式

调整DBMS_STATS参数为adaptive sampling

1
EXEC dbms_stats.set_database_prefs ('approximate_ndv_algorithm', 'adaptive sampling');

2.立刻调整旧算法为新的

所有分区的统计信息会被重新收集

1
2
EXEC dbms_stats.set_database_prefs ('approximate_ndv_algorithm', 'hyperloglog');
EXEC dbms_stats.set_database_prefs ('incremental_staleness', NULL);

3.逐渐用新算法替换旧算法

旧的概要不会被立即删掉,新的分区会采用新算法格式的概要。混合模式可能会产生不太准确的统计信息,但是这样就不需要在前台重新收集所有统计信息,因为自动统计信息收集任务将重新收集具有旧概要的分区信息,并使用新格式。到最后所有的概要都会处于新的格式,统计信息也都会精确。

1
2
EXEC dbms_stats.set_database_prefs ('approximate_ndv_algorithm', 'hyperloglog');
EXEC dbms_stats.set_database_prefs ('incremental_staleness', 'allow_mixed_format');

12.2统计信息之扩展统计信息

从11g开始引入了对列收集扩展统计信息,扩展统计信息包含了两种额外类型的统计信息:组合列和表达式统计信息。

组合列

对于真实数据来说,一个表中多个字段直接的数据通常具有关联性。比如在CUSTOMERS表中,CUST_STATE_PROVINCE字段会受到COUNTRY_ID字段值的影响,比如湖北只会出现在中国下面,如果只有基本的统计信息,优化器是没有办法知道这些关系的,如果在一个语句中这几个字段条件同时存在的话,优化器就会估算错误。这时如果有收集扩展统计信息的话,优化器就能知道它们之间的关系。

对组合列收集信息后,优化器能更好的计算出基数。可以通过函数DBMS_STATS.CREATE_EXTENDED_STATS去实现多个字段的组合收集。当组合字段的统计信息被收集以后,当这张表收集统计信息时,oracle会自动维护这个组合字段的统计信息,跟普通字段一样。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
ALTER SYSTEM FLUSH SHARED_POOL;

conn xb/xb;

drop table t1 purge;

create table t1 as
select 1 col1,2 col2
from dual
connect by level>=5000
union all
select 2 col1,1 col2
from dual
connect by level>=5000;

select dbms_stats.create_extended_stats(user,'t1','(COL1,COL2)') name from dual;

NAME
--------------------------------------------------------------------------
SYS_STUFLHATC5RBD6JHJZWT$X2AAH

exec dbms_stats.gather_table_stats(user,'t1');

建完组合列和重新收集统计信息后,会看到一个额外由系统生成名称的列

1
2
3
4
5
6
7
8
9
10
col column_name for a60
select column_name,num_distinct,num_nulls,histogram
from user_tab_col_statistics
where table_name='T1';

COLUMN_NAME NUM_DISTINCT NUM_NULLS HISTOGRAM
------------------------------------------------------------ ------------ ---------- ---------------------------------------------
COL1 2 0 NONE
COL2 2 0 NONE
SYS_STUFLHATC5RBD6JHJZWT$X2AAH 2 0 NONE >>>>====新生成的字段名

如果要查用户有哪些其他的扩展统计信息,可以查询视图USER_STAT_EXTENSIONS

1
2
3
4
5
6
7
8
9
10
col table_name for a30
col extension_name for a60
col extension for a60
select table_name,extension_name,extension
from USER_STAT_EXTENSIONS
where creator='USER';

TABLE_NAME EXTENSION_NAME EXTENSION
------------------------------ ------------------------------------------------------------ ------------------------------------------------------------
T1 SYS_STUFLHATC5RBD6JHJZWT$X2AAH ("COL1","COL2")

自动组合列检测

尽管组合列统计信息非常有用,能很方便的生成好的执行计划,但是一般来说不容易知道在一个特定的负载下该收集哪些组合列的信息。

自动组合列检测决定了在一个特定的负载状态下,表的哪些组合列的统计信息应该被收集。注意此功能不对函数字段生成扩展信息,只对组合列适用。自动组合列检测由以下三个步骤完成:

种子列使用

为了决定适当的组合列,oracle必须了解具有代表性的负载情况。负载情况可以通过SQL Tuning Set查到或者通过负载监控工具。通过过程DBMS_STATS.SEED_COL_USAGE来显示负载,并告诉oracle这个负载要观察多久。下面这个例子表示对当前系统监控5分钟。

1
2
3
4
begin 
dbms_stats.seed_col_usage(null,null,300);
end;
/

这个监控过程会收集储存在sys.col_usage$当中的信息并储存到sys.col_group_usage$去。包含在这个监控窗口范围内所有执行或解析的sql,当这个监控窗口结束,可以通过一个新的函数DBMS_STATS.REPORT_COL_USAGE去查看到所有表的特定列的使用信息。这个函数会生成一个报告,列出了表所有谓词条件里过滤、关联、group by等操作涉及到的列。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
xb@ORA12C> select count(1) from t1 where col1=1 and col2=2;

COUNT(1)
----------
5000

xb@ORA12C> select dbms_stats.report_col_usage(user,'T1') from dual;

DBMS_STATS.REPORT_COL_USAGE(USER,'T1')
-----------------------------------------------------------------------
LEGEND:
.......

EQ : Used in single table EQuality predicate
RANGE : Used in single table RANGE predicate
LIKE : Used in single table LIKE predicate
NULL : Used in single table is (not) NULL predicate
EQ_JOIN : Used in EQuality JOIN predicate
NONEQ_JOIN : Used in NON EQuality JOIN predicate
FILTER : Used in single table FILTER predicate
JOIN : Used in JOIN predicate
GROUP_BY : Used in GROUP BY expression
...............................................................................

###############################################################################

COLUMN USAGE REPORT FOR XB.T1
.............................

1. COL1 : EQ >>>>====
2. COL2 : EQ >>>>====
3. SYS_STUFLHATC5RBD6JHJZWT$X2AAH : EQ >>>>====
4. (COL1, COL2) : FILTER >>>>====
###############################################################################

创建组合列

对每张表调用函数DBMS_STATS.CREATE_EXTENDED_STATS,会自动根据之前监控窗口中得到的有用信息创建必要的组合列。当扩展统计信息创建以后,每当表统计信息被收集时,组合列的统计信息也会自动维护。

1
2
3
4
5
6
7
8
9
10
11
xb@ORA12C> select dbms_stats.create_extended_stats(user,'T1') from dual;

DBMS_STATS.CREATE_EXTENDED_STATS(USER,'T1')
-------------------------------------------------------------------------------------
###############################################################################

EXTENSIONS FOR XB.T1
....................

1. (COL1, COL2) : SYS_STUFLHATC5RBD6JHJZWT$X2AAH exists >>>>====我这里提示已存在
###############################################################################

也可以手动指定要组合的列

1
xb@ORA12C> select dbms_stats.create_extended_stats(user,'T1','(COL1,COL2)') from dual;

重新收集统计信息

最后一步就是重新收集表的统计信息,这样新创建的组合列就会拥有统计信息。

1
exec dbms_stats.gather_table_stats(null,'T1')

SQL计划指示和组合列

sql计划指示不仅仅指示用来优化sql执行计划,可以参考12c Adaptive Statistics,同样可以用来决定组合列是否可以有效解决基数估算不准的问题。如果一个sql计划指示创建了,同时优化器认为基数估算不准的问题可以被这个组合列解决,12cR1中oracle会在下次表分析的时候自动创建组合列。

但是到了12cR2的时候这个特性有了变化,自动创建组合列的功能默认是被关闭的,可以通过包DBMS_STATS包来开启或关闭。

1
2
3
exec dbms_stats.set_global_prefs ('AUTO_STAT_EXTENSIONS', 'OFF');  >>>>====表示不自动创建

exec dbms_stats.set_global_prefs ('AUTO_STAT_EXTENSIONS', 'ON'); >>>>====表示会根据SQL计划指示自动创建

如果你的版本是12.1的话,想关闭这个特性可以通过打补丁解决21171382

表达式统计信息

可以对表达式或函数收集扩展统计信息,去帮助优化器去估算那些谓词条件中包含表达式或者函数的情况。比如条件中含有upper(name)=,那么这时候收集upper(name)的扩展统计信息就会非常有帮助。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
drop table t1 purge;

create table t1 (name varchar2(10));

insert into t1 values('xb');
insert into t1 values('XB');
insert into t1 values('Xb');
commit;

select dbms_stats.create_extended_stats(NULL,'T1','(UPPER(NAME))') from dual;

DBMS_STATS.CREATE_EXTENDED_STATS(NULL,'T1','(UPPER(NAME))')
------------------------------------------------------------------------
SYS_STUMMY#LUDFVUOI56L724JL4ZO

跟组合列一样,定义表达式统计信息以后需要重新收集统计信息。收集完毕后,可以通过USER_TAB_COL_STATISTICS视图查询,同样详细信息也可以通过USER_STAT_EXTENSIONS视图查询

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
col column_name for a60
select column_name,num_distinct,num_nulls,histogram
from user_tab_col_statistics
where table_name='T1';

COLUMN_NAME NUM_DISTINCT NUM_NULLS HISTOGRAM
------------------------------------------------------------ ------------ ---------- ---------------------------------------------
NAME 3 0 NONE
SYS_STUMMY#LUDFVUOI56L724JL4ZO 1 0 NONE >>>>====可以看到经过函数以后的估算值是1


col table_name for a30
col extension_name for a60
col extension for a60
select table_name,extension_name,extension
from USER_STAT_EXTENSIONS
where creator='USER';

TABLE_NAME EXTENSION_NAME EXTENSION
------------------------------ ------------------------------------------------------------ ------------------------------------------------------------
T1 SYS_STUMMY#LUDFVUOI56L724JL4ZO (UPPER("NAME"))

扩展统计信息的限制

扩展统计信息只适用于那些谓词条件为等于或者IN-LIST。如果列上有直方图信息但是组合列没有,则扩展统计信息不被使用。

12.2统计信息之直方图

介绍

很早之前的版本中,如何执行一个sql语句是由RBO(Rule Based Optimizer)决定的,根据一些设定好的规则来生成执行计划。

后来的版本中CBO(Cost Based Optimizer)被引入进来。CBO检查sql所有可能的执行计划然后选择其中cost最低的一个,cost其实就是反应了执行计划估算的资源消耗。cost越低,这个执行计划也就被认为效率越高。为了能让CBO计算出更准确的cost值,就必须要有sql所有的访问对象的相关信息,包括表、索引等。

这些必要的信息统称为统计信息,理解和管理统计信息对于获得一个好的执行计划是非常重要的。

什么是统计信息

统计信息是用来描述数据库和它其中的对象的数据,这些信息能被优化器使用用于对每个sql生成最好的执行计划。统计信息储存在数据字典当中,能直接通过字典视图来访问,例如USER_TAB_STATISTICS

大部分的统计信息需要定期收集和更新,用来确保当前的信息能真实反映实际储存在数据库中的数据情况。举个例子:部分交易表非常活跃,经常有大量数据的操作,那么这些表就需要经常更新统计信息。而另外一些历史归档表由于历史数据并没有被经常使用,只是时而被查询,那么这些表就不需要定期更新。所以是否需要收集统计信息完全是根据需要来的。

表和列的统计信息

表的统计信息包含有多少行数据,使用了多少个数据块,平均每一行数据使用了多少个byte等等。优化器使用这些信息并且结合其他的一些相关信息,计算出不同执行计划所需的cost,并且估算出各个操作所返回的记录数。比如访问某张表的cost则是用表的数据块数结合参数DB_FILE_MULTIBLOCK_READ_COUNT计算得出。你可以直接通过视图USER_TAB_STATISTICS来查询。

列的统计信息则包括列的唯一值数量(NDV),和列的最大值与最小值,可以通过USER_TAB_COL_STATISTICS视图查询。优化器通过这些信息结合表的相关信息来估算出sql每一步操作会返回的记录数。如果一张表有100行,查询的列上有10个唯一值,那么优化器估算的返回值也为100/10=10。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
drop table t purge;

create table t as
select mod(level,10) id from dual
connect by level>=100;

sys@ORA12C> @grp id t
count id in table t...

ID COUNT(*)
---------- ----------
0 10
1 10
2 10
3 10
4 10
5 10
6 10
7 10
8 10
9 10

sys@ORA12C> select count(1) from t where id=1;


Execution Plan
----------------------------------------------------------
Plan hash value: 2966233522

---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 | 2 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 13 | | |
|* 2 | TABLE ACCESS FULL| T | 10 | 130 | 2 (0)| 00:00:01 | >>>>==== ROWs估算为10
---------------------------------------------------------------------------

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

2 - filter("ID"=1)

Note
-----
- dynamic statistics used: dynamic sampling (level=2)


Statistics
----------------------------------------------------------
6 recursive calls
5 db block gets
19 consistent gets
0 physical reads
0 redo size
542 bytes sent via SQL*Net to client
607 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

额外列统计信息

表和列的统计信息给了优化器很多信息,但是其无法提供一个机制来告诉优化器表或列当中数据的性质。比如这些统计信息无法提供列的数据是否分布均匀,或者多个列的数据是否有关联关系。这种类型的信息只能通过扩展统计信息来获得。其中包括直方图,组合列和表达式统计信息。如果没有这些,那么优化器会默认数据是分布均匀的,然后所有列之间的数据并无关联关系。

直方图

直方图给优化器提供了列数据的分布情况,根据之前的例子,优化器是默认用总行数/唯一值来估算返回记录,如果列的数据分布不均匀,那么得到的结果就区别很大。为了准确反映一个不均匀的数据分布,就需要对列收集直方图。

oracle会自动决定列是否要收集直方图,取决于列的使用情况(SYS.COL_USAGE$),和数据倾斜的状况。比如当一个唯一列总是以等式出现在谓词条件中时,oracle不会对其自动创建直方图。

目前总共有4种直方图:frequency, top-frequency, height-balanced 和 hybrid(top-frequency和hybrid是12c新引入),oracle自动选择合适的类型。一般取决于列上的唯一值数量,可以通过user_tab_col_statistics视图的histogram字段来查询每一列的直方图类型。

frequency Histograms

当列的唯一值小于最大的桶的数量阀值时,默认创建frequency直方图。桶的最大值默认是254,但是可以通过DBMS_STATS来修改成最高至2048(从12c开始)

将之前的数据做下处理,然后收集直方图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
delete from t where id=1 and rownum >=9;
delete from t where id=2 and rownum >=8;
delete from t where id=3 and rownum >=7;
delete from t where id=4 and rownum >=6;
delete from t where id=5 and rownum >=5;
delete from t where id=6 and rownum >=4;
delete from t where id=7 and rownum >=3;
delete from t where id=8 and rownum >=2;
delete from t where id=9 and rownum >=1;
commit;

sys@ORA12C> @grp id t
count id in table t...

ID COUNT(*)
---------- ----------
0 10
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9

exec dbms_stats.gather_table_stats(USER,'T',method_opt=>'for all columns size auto');

现在来看一下直方图的情况

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
select endpoint_value,endpoint_number,endpoint_number-lag(endpoint_number,1,0) over(order by endpoint_number) as frequency
from user_tab_histograms
where table_name='T'
and column_name='ID'
order by 2;

ENDPOINT_VALUE ENDPOINT_NUMBER FREQUENCY
-------------- --------------- ----------
0 10 10
1 11 1
2 13 2
3 16 3
4 20 4
5 25 5
6 31 6
7 38 7
8 46 8
9 55 9

FREQUENCY表示每一个桶值,也就是这个值有多少条记录数。oracle频度直方图将桶称为”endpoint values”,上面的结果就是表示有0-9总共10个桶,ENDPOINT_NUMBER这代表着累计频度,比如endpoint values为1的累计频度就是前后的FREQUENCY的累加值,10+1=11。

注意到ENDPOINT_VALUE为number型,所以对于非number类型的字段收集直方图以后,存储在ENDPOINT_VALUE字段的值也会转码成number型。

1
2
3
4
5
6
7
8
9
10
11
sys@ORA12C> @desc user_tab_histograms
Name Null? Type
------------------------------- -------- ----------------------------
1 TABLE_NAME VARCHAR2(128)
2 COLUMN_NAME VARCHAR2(4000)
3 ENDPOINT_NUMBER NUMBER
4 ENDPOINT_VALUE NUMBER >>>>====这里是number类型
5 ENDPOINT_ACTUAL_VALUE VARCHAR2(4000)
6 ENDPOINT_ACTUAL_VALUE_RAW RAW(2000)
7 ENDPOINT_REPEAT_COUNT NUMBER
8 SCOPE VARCHAR2(7)

当直方图创建完毕以后,优化器就能估算的更加准确。比如id=1时,优化器立刻能知道记录只有1条,就会走索引之类。

高度平衡直方图

与频度直方图相反的是,当列的唯一值大于最大的桶的数量阀值时,默认创建高度平衡直方图。桶的最大值默认是254,但是可以通过DBMS_STATS来修改成最高至2048(从12c开始)。

频度直方图在面对字段有大量唯一值时就比较乏力,因为它每个桶中只存放了一个值,所以随着直方图数量的不断增加,系统在存储、使用和维护这些直方图时就会需要大量的资源。12c开始,在多数情况下oracle采用了新的混合直方图来取代高度平衡直方图,稍后会介绍到混合直方图。

假设一个表含有字段COL1,值从1到1000,下图展示出将数据切分成数个范围。值从1到100的记录数有1000行,值从201到300直接的值突然增高到3000

如果将同样的数据换成高度平衡直方图的话,通过平衡每个范围的大小,可以将每个范围的值调整成近似相等。换句话说,每个垂直条都有近似的高度。比如值1-200有2000行,下一个范围201-267也保持在2000行左右,因为201-300范围的值比较多。

Top-Frequency直方图

传统而言当列的唯一值大于最大的桶的数量阀值时,就会创建高度平衡直方图或者混合直方图。然而有些情况下列中大多数数据都是重复的,其余的相对少量数据却含有大量的唯一值,也就是说数据分布极不均匀。在这种情况下,更适合对表的大多数记录创建频度直方图,忽略对统计信息不重要的一组记录(基数小但是唯一值多)。当选择频度直方图时,数据库必须决定最大的桶数阀值是否足够去准确的计算基数,即使行中的唯一值数量已经超过了这个阀值。它计算列中99.6%的行中有多少个不同的值(99.6%是默认值,但是这个值会根据直方图的数量进行调整)。如果有足够的直方图桶可以用来容纳前N个不同的值,那么将为这些活跃的值创建频率直方图。

在收集统计信息时,只有参数ESTIMATE_PERCENT被设成AUTO_SAMPLE_SIZE(默认值)时,才会创建Top-Frequency直方图,因为必须查看列中的所有值,才能判断是否满足必要的条件(行中的99.6%有254或者更少的唯一值)。

构建一张表包含10000条数据,其中9000条随机1-9,大致上每个值含有1000条数据,其余的值都是唯一值。故总的唯一值数为1009,远超254的阀值。参数METHOD_OPT限制每个桶不超过10

1
2
3
4
5
6
7
8
9
10
11
DROP TABLE t1 PURGE;

CREATE TABLE t1 AS
SELECT CASE
WHEN level >= 9000 THEN TRUNC(DBMS_RANDOM.value(1,10))
ELSE level
END AS id
FROM dual
CONNECT BY level >= 10000;

EXEC DBMS_STATS.gather_table_stats(USER, 't1', method_opt => 'FOR COLUMNS ID SIZE 10');

通过USER_TAB_COLUMNS视图可以查到直方图类型

1
2
3
4
5
6
7
8
9
SELECT column_id,
column_name,
histogram
FROM user_tab_columns
WHERE table_name = 'T1';

COLUMN_ID COLUMN_NAME HISTOGRAM
---------- -------------------- ---------------------------------------------
1 ID TOP-FREQUENCY

下面这个查询展示了Top-Frequency直方图中每个值以及其结束点值和频度,注意到重复度高的值展示的是一个正常的频度直方图,而重复度低的值则被分组成一个低频度的组。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
select endpoint_value,endpoint_number, endpoint_number-lag(endpoint_number,1,0) over(order by endpoint_number) as frequency
from user_tab_histograms
where table_name='T1'
and column_name='ID'
order by 2;

ENDPOINT_VALUE ENDPOINT_NUMBER FREQUENCY
-------------- --------------- ----------
1 995 995
2 1981 986
3 2971 990
4 3950 979
5 4960 1010
6 5950 990
7 6932 982
8 7952 1020
9 9000 1048
10000 9001 1
混合直方图

混合直方图类似频度和高度平衡直方图的一个结合,大多数情况下,12c采用混合直方图来取代传统的高度直方图。跟高度平衡直方图不一样的是,混合直方图中结束点值不能跨越桶,除了桶中的最高值外,混合直方图还储存最高值的次数,从而准确的了解其活跃程度,同时也能了解其他结束点值的活跃程度。那么混合直方图如何表示一个活跃的值呢?记录每个结束点值的频率(记录在新字段endpoint_repeat_count),从而提供每个结束点值的活跃程度。

下面这张表有10000行,有5000行随机1-99,其余5000行值唯一。

1
2
3
4
5
6
7
8
9
DROP TABLE t1 PURGE;

CREATE TABLE t1 AS
SELECT CASE
WHEN MOD(level,2) = 0 THEN TRUNC(DBMS_RANDOM.value(1,100))
ELSE level
END AS id
FROM dual
CONNECT BY level >= 10000;

这里为了触发在正常收集统计信息的时候收集直方图,先用重复度的高的条件查询一遍做硬解析。

1
2
3
4
5
6
7
8
9
sys@ORA12C> select count(1) from t1 where id=1;

COUNT(1)
----------
48

sys@ORA12C> EXEC DBMS_STATS.gather_table_stats(USER, 't1');

PL/SQL procedure successfully completed.

通过USER_TAB_COLUMNS视图可以查到直方图类型

1
2
3
4
5
6
7
8
9
SELECT column_id,
column_name,
histogram
FROM user_tab_columns
WHERE table_name = 'T1';

COLUMN_ID COLUMN_NAME HISTOGRAM
---------- -------------------- ---------------------------------------------
1 ID HYBRID

下面的结果可以看到混合直方图同时具有频度和高度平衡直方图的特性,桶可以包含多个值,终点值存储累计频度。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
select histogram,num_buckets
from user_tab_col_statistics
where table_name='T1'
and column_name='ID';

HISTOGRAM NUM_BUCKETS
--------------------------------------------- -----------
HYBRID 254

select endpoint_value,endpoint_number,endpoint_repeat_count, endpoint_number-lag(endpoint_number,1,0) over(order by endpoint_number) as frequency
from user_tab_histograms
where table_name='T1'
and column_name='ID'
order by 2;

ENDPOINT_VALUE ENDPOINT_NUMBER ENDPOINT_REPEAT_COUNT FREQUENCY
-------------- --------------- --------------------- ----------
1 48 48 48
2 92 44 44
3 146 54 54
4 195 49 49
5 245 50 50
6 301 56 56
7 351 50 50
8 397 46 46
9 440 43 43
10 478 38 38
11 517 39 39
12 565 48 48
13 602 37 37
14 649 47 47
15 704 55 55
16 744 40 40
17 799 55 55
18 856 57 57
19 912 56 56
20 962 50 50
21 1008 46 46
22 1068 60 60
23 1127 59 59
24 1185 58 58
25 1231 46 46
26 1282 51 51
27 1333 51 51
28 1385 52 52
29 1434 49 49
30 1481 47 47
31 1530 49 49
32 1579 49 49
33 1630 51 51
34 1681 51 51
35 1736 55 55
36 1799 63 63
37 1852 53 53
38 1908 56 56
39 1966 58 58
40 2009 43 43
41 2061 52 52
42 2109 48 48
43 2158 49 49
44 2213 55 55
45 2253 40 40
46 2307 54 54
47 2362 55 55
48 2415 53 53
49 2460 45 45
50 2516 56 56
51 2557 41 41
52 2618 61 61
53 2665 47 47
54 2733 68 68
55 2787 54 54
56 2838 51 51
57 2895 57 57
58 2951 56 56
59 3023 72 72
60 3068 45 45
61 3123 55 55
62 3179 56 56
63 3235 56 56
64 3272 37 37
65 3342 70 70
66 3392 50 50
67 3439 47 47
68 3498 59 59
69 3557 59 59
70 3596 39 39
71 3645 49 49
72 3695 50 50
73 3745 50 50
74 3782 37 37
75 3842 60 60
76 3891 49 49
77 3948 57 57
78 3989 41 41
79 4048 59 59
80 4095 47 47
81 4153 58 58
82 4198 45 45
83 4250 52 52
84 4308 58 58
85 4346 38 38
86 4395 49 49
87 4448 53 53
88 4505 57 57
89 4554 49 49
90 4604 50 50
91 4644 40 40
92 4689 45 45
93 4743 54 54
94 4797 54 54
95 4851 54 54
96 4894 43 43
97 4953 59 59
98 5003 50 50
99 5050 47 47
163 5082 1 32
227 5114 1 32
291 5146 1 32
355 5178 1 32
419 5210 1 32
483 5242 1 32
547 5274 1 32
611 5306 1 32
677 5339 1 33
741 5371 1 32
805 5403 1 32
869 5435 1 32
933 5467 1 32
997 5499 1 32
1061 5531 1 32
1125 5563 1 32
1189 5595 1 32
1253 5627 1 32
1317 5659 1 32
1383 5692 1 33
1447 5724 1 32
1511 5756 1 32
1575 5788 1 32
1639 5820 1 32
1703 5852 1 32
1767 5884 1 32
1831 5916 1 32
1895 5948 1 32
1959 5980 1 32
2025 6013 1 33
2089 6045 1 32
2153 6077 1 32
2217 6109 1 32
2281 6141 1 32
2345 6173 1 32
2409 6205 1 32
2473 6237 1 32
2537 6269 1 32
2601 6301 1 32
2665 6333 1 32
2731 6366 1 33
2795 6398 1 32
2859 6430 1 32
2923 6462 1 32
2987 6494 1 32
3051 6526 1 32
3115 6558 1 32
3179 6590 1 32
3243 6622 1 32
3307 6654 1 32
3371 6686 1 32
3437 6719 1 33
3501 6751 1 32
3565 6783 1 32
3629 6815 1 32
3693 6847 1 32
3757 6879 1 32
3821 6911 1 32
3885 6943 1 32
3949 6975 1 32
4013 7007 1 32
4077 7039 1 32
4143 7072 1 33
4207 7104 1 32
4271 7136 1 32
4335 7168 1 32
4399 7200 1 32
4463 7232 1 32
4527 7264 1 32
4591 7296 1 32
4655 7328 1 32
4719 7360 1 32
4785 7393 1 33
4849 7425 1 32
4913 7457 1 32
4977 7489 1 32
5041 7521 1 32
5105 7553 1 32
5169 7585 1 32
5233 7617 1 32
5297 7649 1 32
5361 7681 1 32
5425 7713 1 32
5491 7746 1 33
5555 7778 1 32
5619 7810 1 32
5683 7842 1 32
5747 7874 1 32
5811 7906 1 32
5875 7938 1 32
5939 7970 1 32
6003 8002 1 32
6067 8034 1 32
6131 8066 1 32
6197 8099 1 33
6261 8131 1 32
6325 8163 1 32
6389 8195 1 32
6453 8227 1 32
6517 8259 1 32
6581 8291 1 32
6645 8323 1 32
6709 8355 1 32
6773 8387 1 32
6839 8420 1 33
6903 8452 1 32
6967 8484 1 32
7031 8516 1 32
7095 8548 1 32
7159 8580 1 32
7223 8612 1 32
7287 8644 1 32
7351 8676 1 32
7415 8708 1 32
7479 8740 1 32
7545 8773 1 33
7609 8805 1 32
7673 8837 1 32
7737 8869 1 32
7801 8901 1 32
7865 8933 1 32
7929 8965 1 32
7993 8997 1 32
8057 9029 1 32
8121 9061 1 32
8185 9093 1 32
8251 9126 1 33
8315 9158 1 32
8379 9190 1 32
8443 9222 1 32
8507 9254 1 32
8571 9286 1 32
8635 9318 1 32
8699 9350 1 32
8763 9382 1 32
8827 9414 1 32
8891 9446 1 32
8957 9479 1 33
9021 9511 1 32
9085 9543 1 32
9149 9575 1 32
9213 9607 1 32
9277 9639 1 32
9341 9671 1 32
9405 9703 1 32
9469 9735 1 32
9533 9767 1 32
9599 9800 1 33
9663 9832 1 32
9727 9864 1 32
9791 9896 1 32
9855 9928 1 32
9919 9960 1 32
9983 9992 1 32
9999 10000 1 8

查询v$lock慢

最近分析锁问题的时候发现查询v$lock视图很慢,查询v$lock主要就是查询下面这些内存结构表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Fixed tables :-
-----------------
X$KSUSE
X$KDNSSF
X$KSQEQ
X$KTADM
X$KTATRFIL
X$KTATRFSL
X$KTATL
X$KTSTUSC
X$KTSTUSS
X$KTSTUSG
X$KTCXB
X$KSQRS
X$KSLWT
X$KSLED

通常对于我们一般的表来说,如果表上没有相关的统计信息,那么CBO优化器会自动进行动态采样,而对于fixed tables却不会做这些操作,所以必须要收集它们的统计信息

MOS上这篇文章Query Against v$lock Run from OEM Performs Slowly (Doc ID 1328789.1)比较相似,但是其给出的解决方案是执行exec dbms_stats.GATHER_FIXED_OBJECTS_STATS,这个操作如果是在一个比较繁忙的数据库上会比较危险

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
SYS@xb> set autotrace traceonly

SYS@xb> select * from v$lock;

SYS@xb> set timing on

SYS@xb> select * from v$lock;

Elapsed: 00:00:04.14

Execution Plan
----------------------------------------------------------
Plan hash value: 554400005

-------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 156 | 0 (0)| 00:00:01 |
|* 1 | HASH JOIN | | 1 | 156 | 0 (0)| 00:00:01 |
| 2 | VIEW | GV$_LOCK | 10 | 760 | 0 (0)| 00:00:01 |
| 3 | UNION-ALL | | | | | |
|* 4 | FILTER | | | | | |
| 5 | VIEW | GV$_LOCK1 | 2 | 152 | 0 (0)| 00:00:01 |
| 6 | UNION-ALL | | | | | |
|* 7 | FIXED TABLE FULL| X$KDNSSF | 1 | 102 | 0 (0)| 00:00:01 |
|* 8 | FIXED TABLE FULL| X$KSQEQ | 1 | 102 | 0 (0)| 00:00:01 |
|* 9 | FIXED TABLE FULL | X$KTADM | 1 | 102 | 0 (0)| 00:00:01 |
|* 10 | FIXED TABLE FULL | X$KTATRFIL | 1 | 102 | 0 (0)| 00:00:01 |
|* 11 | FIXED TABLE FULL | X$KTATRFSL | 1 | 102 | 0 (0)| 00:00:01 |
|* 12 | FIXED TABLE FULL | X$KTATL | 1 | 102 | 0 (0)| 00:00:01 |
|* 13 | FIXED TABLE FULL | X$KTSTUSC | 1 | 102 | 0 (0)| 00:00:01 |
|* 14 | FIXED TABLE FULL | X$KTSTUSS | 1 | 102 | 0 (0)| 00:00:01 |
|* 15 | FIXED TABLE FULL | X$KTSTUSG | 1 | 102 | 0 (0)| 00:00:01 |
|* 16 | FIXED TABLE FULL | X$KTCXB | 1 | 102 | 0 (0)| 00:00:01 |
| 17 | MERGE JOIN CARTESIAN | | 100 | 8000 | 0 (0)| 00:00:01 |
|* 18 | FIXED TABLE FULL | X$KSUSE | 1 | 32 | 0 (0)| 00:00:01 |
| 19 | BUFFER SORT | | 100 | 4800 | 0 (0)| 00:00:01 |
| 20 | FIXED TABLE FULL | X$KSQRS | 100 | 4800 | 0 (0)| 00:00:01 |
-------------------------------------------------------------------------------------

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

1 - access("SADDR"="S"."ADDR" AND TO_CHAR(USERENV('INSTANCE'))||RAWTOHEX("
RADDR")=TO_CHAR("R"."INST_ID")||RAWTOHEX("R"."ADDR"))
4 - filter(USERENV('INSTANCE') IS NOT NULL)
7 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
8 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
9 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
10 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
11 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
12 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
13 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
14 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
15 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
16 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSPAFLG",1)>>0)
18 - filter("S"."INST_ID"=USERENV('INSTANCE'))


Statistics
----------------------------------------------------------
0 recursive calls
2 db block gets
0 consistent gets
0 physical reads
0 redo size
2780 bytes sent via SQL*Net to client
545 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
36 rows processed

这里可以看到第17步存在笛卡尔积,优化器估算的X$KSUSE(v$session)表只有1行,X$KSQRS(V$RESOURCE)为100行,按照这个统计值,笛卡尔积并无问题。第3步的UNION ALL考虑了各种锁的情况,最后将所有的结果汇总。一般来说v$session查出来的数据都远不止一行,所以对这两个内存结构表进行表分析

1
2
3
4
5
6
7
8
SYS@xb> 
begin
dbms_stats.gather_table_stats('SYS','x$ksuse',method_opt=>'for all columns size 1');
dbms_stats.gather_table_stats('SYS','x$ksqrs',method_opt=>'for all columns size 1');
end;
5 /

PL/SQL procedure successfully completed.

查看x$表的统计信息情况

1
2
3
4
5
SYS@xb> select OWNER, TABLE_NAME, LAST_ANALYZED from dba_tab_statistics where table_name='X$KSUSE';

OWNER TABLE_NAME LAST_ANALYZED
------------------------------------------------------------------------------------------ --------------------------------------------------------------- ---------------
SYS X$KSUSE 02-NOV-18

重新查看执行计划

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
SYS@xb> select * from v$lock;

38 rows selected.

Elapsed: 00:00:00.04

Execution Plan
----------------------------------------------------------
Plan hash value: 1453144240

--------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 51198 | 5699K| 3 (100)| 00:00:01 |
|* 1 | HASH JOIN | | 51198 | 5699K| 3 (100)| 00:00:01 |
|* 2 | HASH JOIN | | 739 | 67988 | 2 (100)| 00:00:01 |
|* 3 | FIXED TABLE FULL | X$KSUSE | 1522 | 24352 | 0 (0)| 00:00:01 |
| 4 | VIEW | GV$_LOCK | 739 | 56164 | 2 (100)| 00:00:01 |
| 5 | UNION-ALL | | | | | |
|* 6 | FILTER | | | | | |
| 7 | VIEW | GV$_LOCK1 | 731 | 55556 | 2 (100)| 00:00:01 |
| 8 | UNION-ALL | | | | | |
|* 9 | FIXED TABLE FULL| X$KDNSSF | 1 | 40 | 0 (0)| 00:00:01 |
|* 10 | FIXED TABLE FULL| X$KSQEQ | 730 | 29930 | 2 (100)| 00:00:01 |
|* 11 | FIXED TABLE FULL | X$KTADM | 1 | 102 | 0 (0)| 00:00:01 |
|* 12 | FIXED TABLE FULL | X$KTATRFIL | 1 | 102 | 0 (0)| 00:00:01 |
|* 13 | FIXED TABLE FULL | X$KTATRFSL | 1 | 102 | 0 (0)| 00:00:01 |
|* 14 | FIXED TABLE FULL | X$KTATL | 1 | 102 | 0 (0)| 00:00:01 |
|* 15 | FIXED TABLE FULL | X$KTSTUSC | 1 | 102 | 0 (0)| 00:00:01 |
|* 16 | FIXED TABLE FULL | X$KTSTUSS | 1 | 102 | 0 (0)| 00:00:01 |
|* 17 | FIXED TABLE FULL | X$KTSTUSG | 1 | 102 | 0 (0)| 00:00:01 |
|* 18 | FIXED TABLE FULL | X$KTCXB | 1 | 102 | 0 (0)| 00:00:01 |
| 19 | FIXED TABLE FULL | X$KSQRS | 6928 | 148K| 1 (100)| 00:00:01 |
--------------------------------------------------------------------------------------

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

1 - access(TO_CHAR(USERENV('INSTANCE'))||RAWTOHEX("RADDR")=TO_CHAR("R"."INS
T_ID")||RAWTOHEX("R"."ADDR"))
2 - access("SADDR"="S"."ADDR")
3 - filter("S"."INST_ID"=USERENV('INSTANCE'))
6 - filter(USERENV('INSTANCE') IS NOT NULL)
9 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND BITAND("KSSOBFLG",1)>>0
AND "INST_ID"=USERENV('INSTANCE'))
10 - filter(BITAND("KSSOBFLG",1)>>0 AND ("KSQLKMOD">>0 OR "KSQLKREQ">>0)
AND "INST_ID"=USERENV('INSTANCE'))
11 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
12 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
13 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
14 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
15 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
16 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
17 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSOBFLG",1)>>0)
18 - filter(("KSQLKMOD">>0 OR "KSQLKREQ">>0) AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("KSSPAFLG",1)>>0)


Statistics
----------------------------------------------------------
1 recursive calls
2 db block gets
0 consistent gets
0 physical reads
0 redo size
2876 bytes sent via SQL*Net to client
545 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
38 rows processed