分类： Oracle
2010-07-05 17:41:26
同事发来的一份statspack,自己提了一些拙见,希望大侠们看看我判断的是不是正确,同时还有一点疑问,盼各位多提意见. statspack的报告在附件中. 问题: 1.cache buffers chains锁存器的争用很高,怎样分析和解决? 2.参数中open_cursors 8000是不是高的有点离谱了? 3.除了我怀疑的几点,还有那些明显的问题? 用UltraEdit打开你发给我的那个statspack报告。 Soft Parse %: 76.49###第42行 % SQL with executions>1: 12.70 12.68###第49行 这两个值都比较低，通常意味着SQL没有被重用，参考：%2Bcursor%5C_sharing%2B Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Ela Time -------------------------------------------- ------------ ----------- -------- log file sync 1,439 281 33.63 CPU time 153 18.25 log buffer space 195 127 15.18 db file parallel write 158 101 12.14 control file parallel write 127 66 7.90 log file sync： log buffer space的说明：当会话必须等待日志缓冲区中的空间变成可用以写如新信息时产生log buffer space（日志缓冲区空间）等待事件。LGWR进程周期性地从日志缓冲区写入重做日志文件，使得那些日志缓冲区可以重复使用。该等待表示应用程序生成重做日志的速度比LGWR进程将其写入重做日志文件的速度快。这要么是日志缓冲区太小，要么是重做日志文件在磁盘上存在I/O争用。（根据你的系统，Log Buffer:3,072K，已经够大了。可能是I/O争用） db file parallel write的说明：处理此事件时，需要注意1）db file parallel write事件只属于DBWR进程。2）缓慢的DBWR可能影响前台进程。3）大量的db file parallel write等待时间很可能是I/O问题引起的。（在确认os支持异步io的前提下，你可以在系统中检查disk_asynch_io参数，保证为TRUE。可以通过设置db_writer_processes来提高DBWR进程数量，当然前提是不要超过cpu的数量。） DBWR进程执行经过SGA的所有数据库写入，当开始写入时，DBWR进程编译一组脏块（dirty block），并且将系统写入调用发布到操作系统。DBWR进程查找在各个时间内写入的块，包括每隔3秒的一次查找，当前台进程提交以清除缓冲区中的内容时：在检查点处查找，当满足_DB_LARGE_DIRTY_QUEUE、_DB_BLOCK_MAX_DIRTY_TARGET和FAST_START_MTTR_TARGET阀值时，等等。 虽然用户会话从来没有经历过db file parallel write等待事件，但这并不意味着它们不会受到这种事件的影响。缓慢的DBWR写入性能可以造成前台会话在write complete waits或free buffer waits事件上等待。DBWR写入性能可能受到如下方面的影响：I/O操作的类型（同步或异步）、存储设备（裸设备或成熟的文件系统）、数据库布局和I/O子系统配置。需要查看的关键数据库统计是当db file parallel write、free buffer waits和write complete waits等待事件互相关联时，系统范围内的TIME_WAITED和AVERAGE_WAIT。 如果db file parallel write平均等待时间大于10cs（或者100ms），则通常表明缓慢的I/O吞吐量。可以通过很多方法来改善平均等待时间。主要的方法是使用正确类型的I/O操作。如果数据文件位于裸设备（raw device）上，并且平台支持异步I/O，就应该使用异步写入。但是，如果数据库位于文件系统上，则应该使用同步写入和直接I/O（这是操作系统直接I/O）。除了确保正在使用正确类型的I/O操作，还应该检查你的数据库布局并使用常见的命令监控来自操作系统的I/O吞吐量。例如sar -d或iostat -dxnC。 当db file parallel write平均等待时间高并且系统繁忙时，用户会话可能开始在free buffer waits事件上等待。这是因为DBWR进程不能满足释放缓冲区的需求。如果free buffer waits事件的TIME_WAITED高，则应该在高速缓存中增加缓冲区数量之前说明DBWR I/O吞吐量的问题。 高db file parallel write平均等待时间的另一个反响是在write complete waits等待事件上的高TIME_WAITED。前台进程不允许修改正在传输到磁盘的块。换句话说，也就是位于DBWR批量写入中的块。前台的会话在write complete waits等待事件上等待。因此，write complete waits事件的出现，一定标志着缓慢的DBWR进程，可以通过改进DBWR I/O吞吐量修正这种延迟。 根据你的系统的event事件，并没有出现free buffer waits和write complete waits，而且你可以根据第48行： Memory Usage %: 88.40 89.16 看出，你系统并没有使用全部的内存，内存还是比较宽裕的，但是有一点，SGA似乎不应该超过总内存的60%，如果超过了，那os的内存就少了，会产生一定的页导入，降低服务器整体性能。但是我不知道你服务器的使用情况，不能断言。 如何改进DBWR平均写入时间： 如果硬件支持，则打开异步写入；如果不支持，则使用同步写入和多个数据库写入进程。遗憾的是，启动异步I/O并不像设置DISK_ASYNCH_IO参数为TRUE一样简单。如果操作系统确实不支持异步I/O，这并不意味着什么。HP-UX操作系统只在裸设备上支持异步I/O。solaris操作系统在裸设备和文件系统上支持异步I/O。然而，在裸设备上，它使用内核异步I/O（KAIO）系统调用，而在文件系统上，它产生多个进行异步I/O调用（read()、write()、pwrite()、pread()、pwrite64()、pread64()）的次要进程（LWP），以模仿异步I/O。AIX操作系统也在裸设备和文件系统上支持异步I/O。在裸设备上，由内核处理异步I/O（也称为快速路径AIO），但在文件系统上，AIO服务器通过kprocs内核进程处理异步I/O。 如果你在V$system_event视图中看到同步磁盘I/O等待事件上的TIME_WAITED值较高，或者在truss的输出中看到许多AIOWAIT,这就表明异步I/O并不适合你。 |
