Chinaunix首页 | 论坛 | 博客
  • 博客访问: 824647
  • 博文数量: 109
  • 博客积分: 650
  • 博客等级: 上士
  • 技术积分: 1483
  • 用 户 组: 普通用户
  • 注册时间: 2012-03-01 17:29
文章分类

全部博文(109)

文章存档

2016年(5)

2015年(21)

2014年(16)

2013年(38)

2012年(29)

分类: Oracle

2016-08-15 15:05:04

在CBO的优化模式下,我们可以使用optimizer_mode参数控制优化模式。主要有两种模式,一种是ALL_ROWS模式,另外一种是FIRST_ROWS模式。

ALL_ROWS模式适用场景:
希望优化程序给出一种尽快得到全部记录的执行计划,目标是增加系统的吞吐量。
FIRST_ROWS模式使用场景:
希望优化程序给出一种可以迅速的得到第一行的执行计划,目标是减少系统的响应时间。

两种模式需要具体场景具体分析,比如常见的Web应用,很少有一次性得到全部记录的情况,都是分多页交互的响应操作者,因此默认的ALL_ROWS模式就不太适合了,应该考虑使用FIRST_ROWS模式进行优化。
又如,我们想要生成全部数据的报表,那么默认的ALL_ROWS模式就比较的适合。

通过一个实验看一下两种优化模式下的执行计划的不同之处。
1.默认情况下,数据库采用ALL_ROWS模式。
sec@ora10g> show parameter optimizer_mode

NAME                TYPE                 VALUE
------------------- -------------------- -----------------
optimizer_mode      string               ALL_ROWS

2.创建千万级别的测试表t,开启autotrace,查看一下默认ALL_ROWS模式下的执行计划。
sec@ora10g> set autot trace explain
sec@ora10g> select t1.x, t2.x from t t1, t t2 where t1.x = t2.x and t1.owner='SEC';

Execution Plan
----------------------------------------------------------
Plan hash value: 2371815244

--------------------------------------------------------------------------------------
| Id  | Operation             | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |      | 99695 |  2823K|       | 43627   (1)| 00:08:44 |
|*  1 |  HASH JOIN            |      | 99695 |  2823K|  3408K| 43627   (1)| 00:08:44 |
|*  2 |   TABLE ACCESS FULL   | T    | 99695 |  2239K|       | 29985   (1)| 00:06:00 |
|   3 |   INDEX FAST FULL SCAN| PK_T |  9969K|    57M|       |  4871   (2)| 00:00:59 |
--------------------------------------------------------------------------------------

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

   1 - access("T1"."X"="T2"."X")
   2 - filter("T1"."OWNER"='SEC')


优化程序给出了一个快速获得t表全部记录的执行计划,使用到了索引快速全扫描的方式执行,总的执行时间较快。

3.修改优化模式为FIRST_ROWS模式后,再次查询其执行计划。
sec@ora10g> alter session set optimizer_mode =first_rows;

Session altered.

sec@ora10g> select t1.x, t2.x from t t1, t t2 where t1.x = t2.x and t1.owner='SEC';

Execution Plan
----------------------------------------------------------
Plan hash value: 217223811

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      | 99695 |  2823K|   129K  (1)| 00:25:57 |
|   1 |  NESTED LOOPS      |      | 99695 |  2823K|   129K  (1)| 00:25:57 |
|*  2 |   TABLE ACCESS FULL| T    | 99695 |  2239K| 29985   (1)| 00:06:00 |
|*  3 |   INDEX UNIQUE SCAN| PK_T |     1 |     6 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------

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

   2 - filter("T1"."OWNER"='SEC')
   3 - access("T1"."X"="T2"."X")


优化程序给出了一种快速获得t表第一条记录的执行计划,使用到了索引唯一性扫描的方式执行,总的执行时间相对ALL_ROWS模式就长了许多。

4.参考一下Oracle 10g官方文档关于
optimizer_mode参数的描述

OPTIMIZER_MODE

Property Description
Parameter type String
Syntax OPTIMIZER_MODE =

{ first_rows_[1 | 10 | 100 | 1000] | first_rows | all_rows }

Default value all_rows
Modifiable ALTER SESSION, ALTER SYSTEM

OPTIMIZER_MODE establishes the default behavior. for choosing an optimization approach for the instance.

Values:

  • first_rows_n

    The optimizer uses a cost-based approach and optimizes with a goal of best response time to return the first nrows (where n = 1, 10, 100, 1000).

  • first_rows

    The optimizer uses a mix of costs and heuristics to find a best plan for fast delivery of the first few rows.

  • all_rows

    The optimizer uses a cost-based approach for all SQL statements in the session and optimizes with a goal of best throughput (minimum resource use to complete the entire statement).


5.小结

这种优化手段给我们的启示是什么?Oracle默认的优化模式并不一定是我们想要的,必须根据自己的系统特点细心的定制。
Oracle的自动化进程越来越快,这就给一些DBA一种普遍的误解,认为在数据库层面上基本上不用做过多的优化调整,只要按照Oracle的自动化策略走就可以了。这种想法是不正确的。越是自动化,其优化细节就隐藏的越深,越是要静下心来深入的探索和调整。
阅读(2093) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~