oracle 9i 性能调优 1、Overview

Who Tunes?

所有和oracle系统相关的人员(system architects, designers, developers, and database administrators) 都应该关心性能问题.

当问题发生时, DBA往往第一去试图解决它们,所以DBA要对database上的所有applications,以及他们之间的关系很熟悉.

What to Tune?

最好的调优方式是精心的去设计 systems 和 applications.大部分性能的优化是通过调优application来实现的.

如果能做到下面这几点，一般就很少会再有性能问题:

•硬件能够满足需求

•精心设计database

•application developers 写出高效的sql程序

•经常监控database，及时找出影响性能的bottlenecks(瓶颈)

How Much Tuning?

调优的效果对用户来说是要显而易见.所以有两个最基本的理由需要调优 database:

•缩短响应时间来加快语句执行数据

•提供high throughput scalability（吞吐能力）

这两个理由有共同的目的:

•尽可能少的获取 Oracle blocks 来解决用户的需求

•把经常用到的项缓存进内存

应对已经存在的问题或预防问题发生时需要调整 database .

Tuning Phases

Application 设计和编码

尽可能在这个水平上进行调优.如果设计的好，也许将来就不会碰到调优的问题了. 例如, 尽管规范化talbes设计用来减少冗余是很经典的好习惯,但是这样会造成大量的table joins.而使用费规范化的tables可以使application 应用的性能得到显著的提高.

Database Configuration

即使在快速磁盘上监控热点也是很重要的.你应该计划一个配置来保证快速恢复和快速访问.

Adding a New Application to an Existing Database

当添加新的应用到系统中时，一定要做好性能监控.

Troubleshooting and Tuning

用工具检测瓶颈. 检查可能造成瓶颈的数据. 通过假设实现一个解决方案. 然后通过一个测试负载来检验瓶颈是否已经消失.

Tuning Goals

调优目标包含以下几个方面:

•减少或消除等待

•最小化访问块数

•把块缓存到内存

•最小化响应时间

•增加吞吐量

•增加负载承受能力

•减少恢复时间

•实例命中率

量化调优的目标。

调优目标包括以下几个方面:

•减小等待和瓶颈的影响

•减少用户操作所花费的时间

•提高database 可用性

•减少影响DB和OS性能的内存分页和交换来提高内存利用率. 内存利用率也可能会影响到实例命中率.

实例命中率是一个很好的参照用来检测随时间变化性能是增加还是减少,但是也要慎重把命中率当作调优目标 .

Common Performance Problems

Bad Session Management

这通常和中间件相关.比如一个页面上不断的登录和登出database. 这将消耗用户大量时间.

Bad Cursor Management

这通常由编码错误导致而且很难被发现;比如,在where子句中没有使用绑定变量的应用.如果CURSOR_SHARING 被设置成SIMILAR 或 FORCE, 那么:

SELECT * FROM hr.employees WHERE employee_id = 7900;

和

SELECT * FROM hr.employees WHERE employee_id = 7369;

将各自解析成单独的游标.

Bad Relational Designs

这通常是过分规范化的结果.比如,创建了大量的 tables 可能导致需要表链接很多表来产生输出，而这个输出有可能通过一个单独的表来获得.

Tuning Steps During Development

新系统开发阶段的调优技术和生产系统的调优技术有恨到不同. 新系统有很多不可预知的因素:因此最好按照下面步骤进行:

1. Design

2. Application

3. Memory

4. Input/output (I/O)

5. Contention

6. Operating system

问题在越靠前的步骤中解决,后面就将有约少的问题.举个例子, 如果你的应用中使用了大量的全表扫描, 这将导致 I/O异常. 然而, 通过改变 buffer cache 大小或重新分布数据文件起不到一点优化的效果.你只能重写这个查询让它访问4个blocks 而不是40000个.

这前两步是系统架构师和应用开发者的职责; 尽管如此, DBA还是要参与应用的优化.

Collect a Baseline Set of Statistics

每个生产数据库最少有存储一个最低标准的统计集,万一数据库性能退化是用来参照.通过这个统计集合可以帮助DBA确定退化是真的发生了还是用户感觉它发生了.

如果退化是个事实,那么DBA可以确定数据库的那个区域改变了然后集中调整那个区域 .DBA可以创建一个假设是什么原因导致了这个问题怎样最好的解决它.

应用这个假设方案后,测试数据库重新收集统计和baseline比较.

如果新的统计显示实现了系统的性能目标,那么它可以被当作新的baseline. 你应当保存着以往的 baseline sets ,好用来提供长时期的系统变化视图.

Tuning Steps During Production

当调优一个生产database 时，你要集中调整能给你带来最大调优效果的地方.

DBA经常能够在用户感受到之前就解决掉问题. 比如, 一个公司知道它将增加很多新的用户访问database. DBA可以在提早开始应付这个变化预防系统变慢. 这种提前的优化需要DBA非常熟悉database, user base, 和applications的各个方面.

推荐的调优技术:

1. Define the problem: 收集关于问题的用户反馈. 集中获得事实信息. 例如, “这个月终报表过去常常8分钟之内完成.但是两个月之后它现在需要2个小时. 这个报表上午9点开始”

2. Examine the host system and Oracle statistics: 收集系统和数据统计信息并和baseline statistics进行比较. 通过不同之处检查须同发生了什么变化—这通常就是问题所在.

3. Consider some common performance errors:用你统计信息中的不同之处和普通性能错误作比较.确定系统是否发生了这些错误.

4. Build a conceptual model: 模型通过数据库整体的画面来帮助你找到为什么性能下降的答案,以及怎么解决问题从而提高性能达到你的目的?

5. Implement and measure the change: 当你去顶执行了调优之后. 最好一次执行一个改变，因为不同的改变会搅乱你这次改变对数据库的影响.

6. Check that the bottleneck has been resolved: 收集统计信息和 baseline set比较.如果你的假设方案是正确的那么你的新的统计信息将比前面得到的统计信息更加接近baseline.这个比较也将指示你是否还需要进一步的调整.
如果确定还需要继续调优那么返回到第二步重复这个过程.

Database Server Tuning Methodology

先检查直接的问题.

•检查日志或错误信息，这些可以给出一个找到问题所在的快速线索.

•保证初始化参数的设置有意义.如果需要建议每天不同时间设置不同的参数.

•检查CPU and 磁盘队列, 磁盘利用率, 和内存交换.这些事系统负载过重的信号. 如果应用已经相当的优化了,那么只有增加硬件来提高性能了.

每个服务进程会处于下面三个状态中的一个:

•Idle: Waiting for something to do (sleeping)

•Running code: Using the CPU or in a run queue

•Waiting (blocked):

  -等待某些资源

  -等待某个需要的活动结算

Oracle 服务器 提高和多种类“Wait Events” 来记录idle或waiting的processes的行为. Oracle 服务器也能记录正在执行的processes的CPU使用情况.

Performance Trade-Offs

影响性能的因素:

•Multiple control files

•Multiple redo log members in a group

•Frequent checkpointing

•Backing up datafiles

•Performing archiving

•Block check numbers

•Number of concurrent users and transactions

性能和安全需要合理设定.