Chinaunix首页 | 论坛 | 博客
  • 博客访问: 104673128
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类: Oracle

2008-05-23 13:09:47

   来源:

在过去的十年中,Oracle已经成为世界上最专业的数据库之一。对于IT专家来说,就是要确保利用Oracle的强大特性来他们公司的生产力。最有效的方法之一是通过Oracle调优。它有大量的调整参数和技术来改进你的Oracle数据库的。

Oracle调优是一个复杂的主题。关于调优可以写整整一本书,不过,为了改善Oracle数据库的性能,有一些基本的概念是每个Oracle DBA都应该遵从的。

在这篇简介中,我们将简要地介绍以下的Oracle主题:

外部调整:我们应该记住Oracle并不是单独运行的。因此我们将查看一下通过调整Oracle服务器以得到高的性能。

Rowre-sequencing以减少磁盘I/O:我们应该懂得Oracle调优最重要的目标是减少I/O。

Oracle SQL调整:Oracle SQL调整是Oracle调整中最重要的领域之一,只要通过一些简单的SQL调优规则就可以大幅度地提升SQL语句的性能,这是一点都不奇怪的。

调整Oracle排序:排序对于Oracle性能也是有很大影响的。

调整Oracle的竞争:表和索引的参数设置对于UPDATE和INSERT的性能有很大的影响。

我们首先从调整Oracle外部的环境开始。如果内存和的资源不足的话,任何的Oracle调整都是没有帮助的。

外部的性能问题

Oracle并不是单独运行的。Oracle数据库的性能和外部的环境有很大的关系。这些外部的条件包括有:

◆CPU--CPU资源的不足令查询变慢。当查询超过了Oracle服务器的CPU性能时,你的数据库性能就受到CPU的限制。

◆内存--可用于Oralce的内存数量也会影响SQL的性能,特别是在数据缓冲和内存排序方面。

◆网络--大量的Net8通信令SQL的性能变慢。

许多新手都错误的认为应该首先调整Oracle数据库,而不是先确认外部资源是否足够。实际上,如果外部环境出现瓶颈,再多的Oracle调整都是没有帮助的。

在检查Oracle的外部环境时,有两个方面是需要注意的:

1、当运行队列的数目超过服务器的CPU数量时,服务器的性能就会受到CPU的限制。补救的方法是为服务器增加额外的CPU或者关闭需要很多处理资源的组件,例如Oracle Parallel Query 。

2、内存分页。当内存分页时,内存容量已经不足,而内存页是与磁盘上的交换区进行交互的。补救的方法是增加更多的内存,减少Oracle SGA的大小,或者关闭Oracle的多线程服务器。

可以使用各种标准的服务器工具来得到服务器的统计数据,例如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视图得到。

阅读(254) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~