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