《Oracle系统参数调整和优化原则》由会员分享，可在线阅读，更多相关《Oracle系统参数调整和优化原则（3页珍藏版）》请在金锄头文库上搜索。
1、Oracle 系统参数调整和优化原则(来自时代朝阳数据库技术中心)粗略来讲，系统调整一般反映在下列方面：Shared Pool and Library Cache Performance Tuning( 共享池和 Library Cache) ： Oracle 将 SQL 语句、存储包、对象信息和很多其他的项目保存在 SGA 中一个叫共享池（ shared pool）的地方。这个可共享的区域由一个成熟的高速缓存和堆管理器管理。它有 3 个基本的问题要克服：o 内存分配的单元不是个常量。从池中分配的内存单元可能是从几个字节到几千个字节。o 在用户完成工作时，不是所有的内存都能够释放出来，因为共享
2、池的目标是使信息最大程度的共享。o 没有一个象其他常规的高速缓存的文件做后备的存储那样磁盘空间供整页的导出。只有可重新创建的信息可以从 Cache 中丢弃，在他被再次需要的时候再重新创建。共享池调整的技巧有：o 刷（ Flush）共享池可以使小块的内存合并为大块的内存。 当共享池的碎片过多时， 这能够暂时恢复性能。刷共享池可以使用语句： alter system flush shared_pool;o 注意执行这个语句将会造成性能的暂时尖峰，因为对象都要重新加载。所以应当在数据库的负载不是很大的情况下进行。o确保联机事务处理（OLTP ）应用使用绑定变量（bind variables）. 这一
3、点对于决策支持系统（DSS）并不重要。o确保 library cache 的命中率 95%o 增大共享池并不总能解决命中率过多的问题。Buffer Cache Performance Tuning( 数据库缓存调整)：数据库缓存保持了从磁盘上读去的数据块的备份。因为缓存通常受到内存约束的限制， 不是磁盘上所有的数据都可以放到缓存里。 当缓存满了的时候， 后来的缓存不中使得 Oracle 将已经在缓存中的数据写到磁盘上。后续的对写到磁盘上的数据的访问还会造成缓存不中。从缓存调整的角度看，应力求避免以下的问题：o缓存的最近最少使用(LRN) 链（cache buffers LRU chain）的加
4、锁竞争o 平均写队列 （ Average Write Queue ）长度过大o 过多时间花在等待 写完毕等待上 （write complete waits ）o 过多时间花在等待 缓冲释放等待 上 （ free buffer waits ）Latch Contention 加锁（插销）竞争：插销加锁是SGA 中保护共享数据结构的低层的串行化机制。插销latch 是一类可以非常快的获得和释放的锁。插销锁的实现是依赖于操作系统的，尤其在关于一个进程是否会等待一个锁，和等多久方面。有如下的锁（插销）需要调整：oRedo Copy/Allocation Latch ：重写日志的复制/分配插销oShar
5、ed Pool Latch：共享池的插销oLibrary Cache Latch ：Library Cache 插销Redo Log Buffer Performance Tuning （重写日志缓冲的调整）：LGWR将重写日志缓冲中的重写项写到重写日志文件中。一旦 LGWR 将这些项复制到重写日志文件中，用户进程就可以重写这些项。统计项目 redo log space requests反映了用户进程等待重写日志缓冲中空间的时间的数字。设置重写日志大小的一些提示：o redo log space requests的值应该接近 0。o设定合适的重写日志的大小，建议每15-30 分钟进行一次重写日
6、志的切换。Query Performance Tuning（查询效率的调整）：如果查询运行得很慢，请考虑这些方面：o 你希望这个查询运行的有多快以及有理由这样要求吗？o 优化模式 OPTIMIZER_MODE 设为何值？o 查询涉及的索引都是有效的吗？o 在数据库中有没有其他的长时间运行的查询（大查询）o 对于 CBO( 基于成本的优化 )In case of CBO:o 表和索引上有统计信息吗？o 统计信息是被计算出来的还是被估计出来的？o 对于查询的性能调整由两个主要的调试工具：TKPROFAUTOTRACERollback Segment Performance Tuning（回滚段的调
7、整）：Oracle 数据库提供了任何数据库对象上的SELECT, INSERT,UPDATE, 和 DELETE 操作的读一致性。回滚段用于保存由那些要回滚的动作或系统需要产生一个和前面某一时间读一致的影像所产生的可取消事务。设置回滚段大小的技巧如下：o 建议最少每 4 个事务一个回滚段o 建议为长时间运行的大查询提供一个大回滚段。ov$rollstat 中的 wrap 数接近 0。否则增大扩展大小（extent size）。SELECT b.name, a.wraps FROM V$ROLLSTAT a, V$ROLLNAME b;n Temporary Tablespace Perform
8、ance Tuning（临时表空间的调整）：从 RDBMS release 7.3 开始， Oracle 引入了临时表空间的概念。这个表空间用于保存临时对象，如排序段。排序段采用它所在的表空间的缺省存储参数（DEFAULT STORAGE (NEXT) 子句）作为自己的存储参数。临时表空间的调整的技巧如下:o如果即使在稳定的状态下也存在很多的排序扩展锁（Sort Extent Pool latch ）的竞争，你应该通过修改临时表空间的 DEFAULT STORAGE子句的 NEXT 值来增大扩展块的大小。o 如果存在很多的排序扩展锁 （ Sort Extent Pool latch ）的竞争并
9、且这种等待是由于过多的并发的排序造成的，你应该增大 SORT_AREA_SIZE 参数的大小，以使更多的排序能保存在内存中。o建议让扩展块的大小和SORT_AREA_SIZE参数相同。Utlbstat/Utlestat Performance Tuning （ Utlbstat/Utlestat 调整）： Utlbstat/Utlestatt是一堆存放在你的$ORACLE_HOME/rdbms/admin目录下的 SQL 脚本，他们对于捕获系统范围的数据库性能统计的快照非常有用。UTLESTAT创建这些视图的第二个快照，并将两个快照之间的差异报告到文件report.txt 中。Utlbstat
10、.sql在你的sys 用户下创建一系列的表和视图，其中包括开始时数据库性能统计的快照。Utlesta.sql在你的sys 用户下创建一系列的表，其中包括结束时数据库性能统计的快照和一个叫report.txt 的文件。使用方法：o确保你已经将TIMED_STATSTICS设为 TRUE ( 这仅仅给数据库操作增加了一点非常小的开销)。o 确保数据库在运行 utlbstat 前，已经启动并且运行了一段时间。o 从 svrmgrl 中而不是 sql*plus 中运行 utbstat.sql 和 utlestat.sql。o确保在脚本utlbstat/estat 运行时，数据库不被Down 掉，否则产
11、生的统计就不正确。o 至少运行 utlbstat/estat 1-3 个小时，才好调试你的数据库。Checkpoint Performance Tuning （检查点性能调整）：检查点（Checkpoint）是一个数据库事件，用来同步内存和磁盘上的数据文件中的数据块。检查点的目的有两个：o 建立数据的一致性o 是数据库恢复更快。检查点调整方法如下：o如果 LOG_CHECKPOINT_INTERVAL的值比重写日志（ORACLE 进行日志从一个组到另一组切换的时候才发生。redo log）的大小大，那么checkpoint 只在这正是我们希望的。这个行为在Oracle 8i 中有了变化。o当把LOG_CHECKPOINTS_TO_ALERT设为TRUE时，将把checkpoint 启动和停止的时间记录在alert log日志里。这对于你确定checkpoint 是否正以最佳的频率发生很有帮助。o 理想的情况是， checkpoint 在仅在日志切换时发生。Import Performance Tuning （数据载入性能调整）：没有什么固定的信息是关于如何加速那些慢得让人难以忍受的import 的。显然import 要花费它完成所需要的时间，但是作一些事情可以缩短他们所花的时间。方法很简单，并行操作
