使用dbms

dbms_stats包问世以后 Oracle专家可通过一种简单的方式来为CBO收集统计数据 目前 已经不再推荐你使用老式的分析表和dbms_utility方法来生成CBO统计数据 那些古老的方式甚至有可能危及SQL的性能 因为它们并非总是能够捕捉到有关表和索引的高质量信息 CBO使用对象统计 为所有SQL语句选择最佳的执行计划

dbms_stats能良好地估计统计数据（尤其是针对较大的分区表） 并能获得更好的统计结果 最终制定出速度更快的SQL执行计划

清单A展示了dbms_stats的一次示范执行情况 其中使用了options子句

execdbms_stats gather_schema_stats(

ownname => SCOTT

options => GATHER AUTO

estimate_percent => dbms_stats auto_sample_size

method_opt => for all columns size repeat

degree =>

)

为了充分认识dbms_stats的好处 你需要仔细体会每一条主要的预编译指令（directive） 下面让我们研究每一条指令 并体会如何用它为基于代价的SQL优化器收集最高质量的统计数据

options参数

使用 个预设的方法之一 这个选项能控制Oracle统计的刷新方式

gather——重新分析整个架构（Schema）

gather empty——只分析目前还没有统计的表

gather stale——只重新分析修改量超过 %的表（这些修改包括插入 更新和删除）

gather auto——重新分析当前没有统计的对象 以及统计数据过期（变脏）的对象 注意 使用gather auto类似于组合使用gather stale和gather empty

注意 无论gather stale还是gather auto 都要求进行监视 如果你执行一个alter table xxx monitoring命令 Oracle会用dba_tab_modifications视图来跟踪发生变动的表 这样一来 你就确切地知道 自从上一次分析统计数据以来 发生了多少次插入 更新和删除 *** 作

estimate_percent选项

以下estimate_percent参数是一种比较新的设计 它允许Oracle的dbms_stats在收集统计数据时 自动估计要采样的一个segment的最佳百分比

estimate_percent => dbms_stats auto_sample_size

要验证自动统计采样的准确性 你可检视dba_tables sample_size列 一个有趣的地方是 在使用自动采样时 Oracle会为一个样本尺寸选择 到 的百分比 记住 统计数据质量越好 CBO做出的决定越好

method_opt选项

dbms_stats的method_opt参数尤其适合在表和索引数据发生变化时刷新统计数据 method_opt参数也适合用于判断哪些列需要直方图（histograms）

某些情况下 索引内的各个值的分布会影响CBO是使用一个索引还是执行一次全表扫描的决策 例如 假如在where子句中指定的值的数量不对称 全表扫描就显得比索引访问更经济

如果你有一个高度倾斜的索引（某些值的行数不对称） 就可创建Oracle直方图统计 但在现实世界中 出现这种情况的机率相当小 使用CBO时 最常见的错误之一就是在CBO统计中不必要地引入直方图 根据经验 只有在列值要求必须修改执行计划时 才应使用直方图

为了智能地生成直方图 Oracle为dbms_stats准备了method_opt参数 在method_opt子句中 还有一些重要的新选项 包括skewonly repeat和auto method_opt=> for all columns size skewonly

method_opt=> for all columns size repeat

method_opt=> for all columns size auto

skewonly选项会耗费大量处理时间 因为它要检查每个索引中的每个列的值的分布情况

假如dbms_stat发现一个索引的各个列分布得不均匀 就会为那个索引创建直方图 帮助基于代价的SQL优化器决定是进行索引访问 还是进行全表扫描访问 例如 在一个索引中 假定有一个列在 %的行中 如清单B所示 那么为了检索这些行 全表扫描的速度会快于索引扫描

SKEWONLY option—Detailed ysis

Use this method for a first time ysis for skewed indexes

This runs a long time because all indexes are examined

begin

dbms_stats gather_schema_stats(

ownname => SCOTT

estimate_percent => dbms_stats auto_sample_size

method_opt => for all columns size skewonly

degree =>

);

end;

重新分析统计数据时 使用repeat选项 重新分析任务所消耗的资源就会少一些 使用repeat选项（清单C）时 只会为现有的直方图重新分析索引 不再搜索其他直方图机会 定期重新分析统计数据时 你应该采取这种方式

REPEAT OPTION Only re yze histograms for indexes

that have histograms

Following the initial ysis the weekly ysis

job will use the repeat option The repeat option

tells dbms_stats that no indexes have changed and

it will only re yze histograms for

indexes that have histograms

begin

dbms_stats gather_schema_stats(

ownname => SCOTT

estimate_percent => dbms_stats auto_sample_size

method_opt => for all columns size repeat

degree =>

);

end;

使用alter table xxx monitoring;命令来实现Oracle表监视时 需要使用dbms_stats中的auto选项 如清单D所示 auto选项根据数据分布以及应用程序访问列的方式（例如通过监视而确定的一个列的工作量）来创建直方图 使用method_opt=> auto 类似于在dbms_stats的option参数中使用gather auto begin

dbms_stats gather_schema_stats(

ownname => SCOTT

estimate_percent => dbms_stats auto_sample_size

method_opt => for all columns size auto

degree =>

);

end;

并行收集

Oracle允许以并行方式来收集CBO统计数据 这就显著提高了收集统计数据的速度 但是 要想并行收集统计数据 你需要一台安装了多个CPU的SMP服务器

更快的执行速度

dbms_stats是提高SQL执行速度的一种出色机制 通过使用dbms_stats来收集最高质量的统计数据 CBO能够正确判断执行任何SQL查询时的最快途径 dbms_stats还在不断地改进 目前 它的一些令人激动的新特性（自动样本大小和自动直方图生成）已经显著简化了Oracle专家的工作

一般在周末的时候使用dbms_stats和estimate

2％的DB Cache

指表的块数(hwm之下的blocks)为db_cache_size的 %

这个包的下面四个存储过程分别收集index table schema database的统计信息

gather_index_stats

gather_table_stats

gather_schema_stats

gather_database_stats

lishixinzhi/Article/program/Oracle/201311/16499

Oracle选择索引的过程是由查询优化器来完成的，其目标是尽可能地优化查询性能，最终选择最合适的索引。但是有时候，优化器也会选择不是最合适的索引，这可能是由以下原因造成的：

1 统计信息不准确：查询优化器在选择索引时需要依赖数据表的统计信息，包括行数、列的基数和直方图等。如果这些统计信息不准确或者过时，就会导致查询优化器选择不合适的索引。

2 索引失效：如果查询中含有不等于（<>）或者非（NOT） *** 作符，那么索引将无法使用。此时，查询优化器可能会选择其他索引或全表扫描。

3 索引使用成本高：有时候，一个索引虽然能够帮助查询优化器加速查询速度，但是索引本身的使用成本可能很高。例如，在某些情况下，对索引进行大量的随机访问可能比执行全表扫描更为低效。

4 数据分布均匀：当表的某个列的值分布比较均匀时，使用索引可能不如全表扫描更有效率。因为查询优化器需要在索引和表之间来回切换，消耗了额外的资源。

在实际应用中，优化查询性能是一个复杂的过程，需要仔细考虑多个因素。因此，在设计索引时，需要仔细评估不同的因素，以确定最佳的索引方案。

以上就是关于使用dbms全部的内容，包括:使用dbms、oracle索引为什么会选不是最合适的索引、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！