当前位置: > 数据库 > Oracle >

Oracle调优(入门及提高篇)(4)

时间:2015-07-12 16:17来源:linux.it.net.cn 作者:IT



    可以使用各种标准的服务器工具来得到服务器的统计数据,例如 vmstat,glance,top 和 sar 。 DBA 的目标是确保数据库服务器拥有足够的 CPU 和内存资源来处理 Oracle 的请求。

    以下让我们来看一下 Oracle 的 row-resequencing 是如何能够极大地减少磁盘 I/O 的。

    Row-resequencing (行的重新排序)

    就象我们上面提到的,有经验的 Oracle DBA 都知道 I/O 是响应时间的最大组成部分。其中磁盘 I/O 特别厉害,因为当 Oracle 由磁盘上的一个数据文件得到一个数据块时,读的进程就必须等待物理 I/O 操作完成。磁盘操作要比数据缓冲慢 10,000 倍。因此,如果可以令 I/O 最小化,或者减少由于磁盘上的文件竞争而带来的瓶颈,就可以大大地改善 Oracle 数据库的性能。

    如果系统响应很慢,通过减少磁盘 I/O 就可以有一个很快的改善。如果在一个事务中通过按一定的范围搜索 primary-key 索引来访问表,那么重新以 CTAS 的方法组织表将是你减少 I/O 的首要策略。通过在物理上将行排序为和 primary-key 索引一样的顺序,就可以加快获得数据的速度。

    就象磁盘的负载平衡一样,行的重新排序也是很简单的,而且也很快。通过与其它的 DBA 管理技巧一起使用,就可以在高 I/O 的系统中大大地减少响应的时间。

    在高容量的在线事务处理环境中( online transaction processing , OLTP ),数据是由一个 primary 索引得到的,重新排序表格的行就可以令连续块的顺序和它们的 primary 索引一样,这样就可以在索引驱动的表格查询中,减少物理 I/O 并且改善响应时间。这个技巧仅在应用选择多行的时候有用,或者在使用索引范围搜索和应用发出多个查询来得到连续的 key 时有效。对于随机的唯一 primary-key (主键)的访问将不会由行重新排序中得到好处。

    让我们看一下它是如何工作的。考虑以下的一个 SQL 的查询,它使用一个索引来得到 100 行:

    selectsalaryfromemployeewherelast_name like 'B%';

    这个查询将会使用 last_name_index ,搜索其中的每一行来得到目标行。这个查询将会至少使用 100 次物理磁盘的读取,因为 employee 的行存放在不同的数据块中。

    不过,如果表中的行已经重新排序为和 last_name_index 的一样,同样的查询又会怎样处理呢?我们可以看到这个查询只需要三次的磁盘 I/O 就读完全部 100 个员工的资料(一次用作索引的读取,两次用作数据块的读取),减少了 97 次的块读取。

    重新排序带来的性能改善的程度在于在你开始的时候行的乱序性如何,以及你需要由序列中访问多少行。至于一个表中的行与索引的排序键的匹配程度,可以查看数据字典中的 dba_indexes 和 dba_tables 视图得到。

    在 dba_indexes 的视图中,查看 clustering_factor 列。如果 clustering_factor 的值和表中的块数目大致一样,那么你的表和索引的顺序是一样的。不过,如果 clustering_factor 的值接近表中的行数目,那就表明表格中的行和索引的顺序是不一样的。

    行重新排序的作用是不可以小看的。在需要进行大范围的索引搜索的大表中,行重新排序可以令查询的性能提高三倍。

    一旦你已经决定重新排序表中的行,你可以使用以下的工具之一来重新组织表格。

    . 使用 Oracle 的 Create Table As Select (CTAS) 语法来拷贝表格
    . Oracle9i 自带的表格重新组织工具


    以下,我们来看以下 SQL 语句的调优。

    SQL 调优

    Oracle 的 SQL 调优是一个复杂的主题,甚至是需要整本书来介绍 Oracle SQL 调优的细微差别。不过有一些基本的规则是每个 Oracle DBA 都需要跟从的,这些规则可以改善他们系统的性能。 SQL 调优的目标是简单的:

    . 消除不必要的大表全表搜索:不必要的全表搜索导致大量不必要的 I/O ,从而拖慢整个数据库的性能。调优专家首先会根据查询返回的行数目来评价 SQL 。在一个有序的表中,如果查询返回少于 40% 的行,或者在一个无序的表中,返回少于 7% 的行,那么这个查询都可以调整为使用一个索引来代替全表搜索。对于不必要的全表搜索来说,最常见的调优方法是增加索引。可以在表中加入标准的 B 树索引,也可以加入 bitmap 和基于函数的索引。要决定是否消除一个全表搜索,你可以仔细检查索引搜索的 I/O 开销和全表搜索的开销,它们的开销和数据块的读取和可能的并行执行有关,并将两者作对比。在一些情况下,一些不必要的全表搜索的消除可以通过强制使用一个 index 来达到,只需要在 SQL 语句中加入一个索引的提示就可以了。

    . 在全表搜索是一个最快的访问方法时,将小表的全表搜索放到缓存中,调优专家应该确保有一个专门的数据缓冲用作行缓冲。在 Oracle7 中,你可以使用 alter table xxx cache 语句,在 Oracle8 或以上,小表可以被强制为放到 KEEP 池中缓冲。

    . 确保最优的索引使用 :对于改善查询的速度,这是特别重要的。有时 Oracle 可以选择多个索引来进行查询,调优专家必须检查每个索引并且确保 Oracle 使用正确的索引。它还包括 bitmap 和基于函数的索引的使用。

    . 确保最优的 JOIN 操作:有些查询使用 NESTED LOOP join 快一些,有些则是 HASH join 快一些,另外一些则是 sort-merge join 更快。

    这些规则看来简单,不过它们占 SQL 调优任务的 90% ,并且它们也无需完全懂得 Oracle SQL 的内部运作。以下我们来简单概览以下 Oracle SQL 的优化。

    我们首先简要查看 Oracle 的排序,并且看一看排序操作是如何影响性能的。

    调整 Oracle 的排序操作

    排序是 SQL 语法中一个小的方面,但很重要,在 Oracle 的调整中,它常常被忽略。当使用 create index 、 ORDER BY 或者 GROUP BY 的语句时, Oracle 数据库将会自动执行排序的操作。通常,在以下的情况下 Oracle 会进行排序的操作:


使用 Order by 的 SQL 语句
    使用 Group by 的 SQL 语句

 

    在创建索引的时候

    进行 table join 时,由于现有索引的不足而导致 SQL 优化器调用 MERGE SORT

    当与 Oracle 建立起一个 session 时,在内存中就会为该 session 分配一个私有的排序区域。如果该连接是一个专用的连接 (dedicated connection) ,那么就会根据 init.ora 中 sort_area_size 参数的大小在内存中分配一个 Program Global Area (PGA) 。如果连接是通过多线程服务器建立的,那么排序的空间就在 large_pool 中分配。不幸的是,对于所有的 session ,用做排序的内存量都必须是一样的,我们不能为需要更大排序的操作分配额外的排序区域。因此,设计者必须作出一个平衡,在分配足够的排序区域以避免发生大的排序任务时出现磁盘排序( disk sorts )的同时,对于那些并不需要进行很大排序的任务,就会出现一些浪费。当然,当排序的空间需求超出了 sort_area_size 的大小时,这时将会在 TEMP 表空间中分页进行磁盘排序。磁盘排序要比内存排序大概慢 14,000 倍。


    上面我们已经提到,私有排序区域的大小是有 init.ora 中的 sort_area_size 参数决定的。每个排序所占用的大小由 init.ora 中的 sort_area_retained_size 参数决定。当排序不能在分配的空间中完成时,就会使用磁盘排序的方式,即在 Oracle 实例中的临时表空间中进行。


    磁盘排序的开销是很大的,有几个方面的原因。首先,和内存排序相比较,它们特别慢;而且磁盘排序会消耗临时表空间中的资源。 Oracle 还必须分配缓冲池块来保持临时表空间中的块。无论什么时候,内存排序都比磁盘排序好,磁盘排序将会令任务变慢,并且会影响 Oracle 实例的当前任务的执行。还有,过多的磁盘排序将会令 free buffer waits 的值变高,从而令其它任务的数据块由缓冲中移走。


    接着,让我们看一下 Oracle 的竞争,并且看一下表的存储参数的设置是如何影响 SQL UPDATE 和 INSERT 语句的性能的。


(责任编辑:IT)

------分隔线----------------------------