下午1.30到3.00.这可能包括凌晨12:00到6:00的批处理窗口。

It is important to identify these peakperiods at the site and install a monitoring tool that gathers performance datafor those high-load times. Optimally, data gathering should be configured fromwhen the application is in its initial trial phase during the QA cycle.Otherwise, this should be configured when the system is first in production.

找到这些这些高峰时段和安装一个能够收集高负载时段性能数据的监控工具都是非常重要的。理想情况下，数据采集应该是从应用的质量保证生命周期中的初始化试验阶段开始配置。否则，应该在系统首次应用于生产时配置。

Ideally, baseline data gathered shouldinclude the following:

理想情况下，基准线数据应该包括以下内容：

In the Automatic Workload Repository,baselines are identified by a range of snapshots that are preserved for futurecomparisons. See "Overview of the Automatic Workload Repository".

在自动工作量知识库里面，基线由一系列的快照形成，这些快照会被保存以便日后比较。祥见“自动工作负载库概述”。

1.1.2.3症状和问题

A common pitfall in performance tuning is tomistake the symptoms of a problem for the actual problem itself. It isimportant to recognize that many performance statistics indicate the symptoms,and that identifying the symptom is not sufficient data to implement a remedy.For example:

性能调优的一个常见陷阱是错误的把问题的症状（表现）当成是问题的实质了。认识到大量性能统计信息预示着问题的症状是很重要的。当然，同时认识到症状并不能给问题补救提供充分的数据也非常重要。

Generally, this is caused bypoorly-configured disks. However, it could also be caused by a significantamount of unnecessary physical I/O on those disks issued by poorly-tuned SQL.

通常情况下，这是由较次配置的磁盘引起的。然而他也可能由大量的不必要的磁盘物理输入输出引起，而这些输入输出是由垃圾sql导致。

Rarely is latch contention tunable byreconfiguring the instance. Rather, latch contention usually is resolvedthrough application changes.

通过重新配置实例来实现闩锁争用问题可调是很少的，相反闩锁争用通常通过改变应用程序来解决。

Excessive CPU usage usually means that thereis little idle CPU on the system. This could be caused by an inadequately-sizedsystem, by untuned SQL statements, or by inefficient application programs.

过高的cpu使用率通常意味着系统会有很少空闲的cpu。这可能由系统规模不适当 或未经优化的sql 或者 低效率的应用程序导致。

1.1.2.4何时调优

There are two distinct types of tuning:

两种不同方式的调优

1.1.2.4.1主动监测

Proactive monitoring usually occurs on aregularly scheduled interval, where a number of performance statistics areexamined to identify whether the system behavior and resource usage haschanged. Proactive monitoring can also be considered as proactive tuning.

主动监测通常发生在一个定期的计划间隔，那里，一定数量的性能统计数据会被检测来确定系统的运行和资源利用率是否已经被改变。主动监测也可以被看作是主动调优。

Usually, monitoring does not result inconfiguration changes to the system, unless the monitoring exposes a seriousproblem that is developing. In some situations, experienced performanceengineers can identify potential problems through statistics alone, althoughaccompanying performance degradation is usual.

Experimenting with or tweaking a system whenthere is no apparent performance degradation as a proactive action can be adangerous activity, resulting in unnecessary performance drops. Tweaking asystem should be considered reactive tuning, and the steps for reactive tuningshould be followed.