oracle数据库调优描述（二）.txt

上一篇中提到的全是理论。本篇具体介绍实例调优。

数据库层面出于性能考虑，首先应该关注初始化参数、回滚段设置、重做日志文件的配置。
undo_management设置为auto后，回滚段自动管理，可以通过v$undostat查看。
redo log file主要关注大小是否合理，数量是否充足。
深入到表空间级别，需要创建必要的永久表空间和临时表空间。
再深入到表级别，在创建表段等时应该指定自动表空间管理，并根据表段的特点（大小、更新频率等）设置详细的存储选项。

表的创建和管理方面，若空间紧张，可以设置压缩表来节省空间，但访问时性能会受影响；
如果表上的dml操作频繁，可以使用segment advisor工具得到建议信息，并参照此信息对表进行空间回收、碎片整理操作；
数据导入完成后，应该创建必要的索引。

使用共享服务器，可以有效地缓解大量用户同时登录时的负载。通过v$dispatcher、v$dispatcher_rate可以查看相关信息。减少dispatcher过程争用的方法包括增加dispatcher进程、开启连接池以及允许session multiplexing。

数据库的统计信息包括等待事件、时间信息、活动会话历史数据、系统和会话信息。
根据不同的等待事件种类可能找到性能的主要问题，而减少DB time可以作为调优的目标。

性能诊断方面最常用的工具就是自动负载报告AWR。oracle默认情况下每小时产生系统快照信息，保存周期为八天，AWR就是通过对快照的比较得出的。
只有某些时间点的信息是不够的，oracle的baselines弥补了这个缺陷，baseline包含了一段时间内的性能数据，可以作为性能问题发生时比较问题症结的一种方法。
baseline分为三类，fixed baselines是dba指定的过去某个时间段的baseline信息，可以作为比较的基准；moving window baseline是系统自动产生的，时间小于或等于快照保留天数；baseline templates又包含single和repeating两类,类似job，在未来生成baseline。single 类一般是用于未来某个时期的baseline生成，比如系统测试的时间段；repeating是未来某个重复的时间段生成baselines，如每周一。
AWR占用的空间由快照的生成时间间隔、历史数据保留周期和给定时间内系统的活动会话数量决定。
AWR数据不要随便删除，会被ADDM、SQL Tuning Advisor、Undo Advisor、Segment Advisor调用。

AWR 的管理将在实验篇中介绍。

用AWR收集到的信息可以进行人工的问题排查，而oracle提供的ADDM则是根据AWR提供一些待优化问题的总结和建议。运行ADDM产生报告是dba在遭遇数据库性能问题时采用的第一步。ADDM是以时间为依据进行优化的。可以在数据库、实例、多个实例上生成ADDM报告

AWR在监测长事务方面已经足够了，但对于短事务可能不能有效捕获，就需要ASH进行补充。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26451536/viewspace-752186/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26451536/viewspace-752186/