Oracle RAC性能调整.docx

Oracle RAC性能调整1、/list/b/0217_1.shtml \o CPU \t _blankCPU和wait time调节尺寸 当在调节system时，比较系统的CPU time 和wait time是十分重要的，从而确定在相应时间中多少是用于有效的工作时间，多少是在等待由其他进程占用的资源。 从一般规律来看，wait time占主要部分的系统比CPU time占主要部分的系统更需要调节。另一方面，CPU的大量使用可能是由不好的SQL写操作造成了。 尽管CPU time与wait time的比率总是随着系统装载的增加而趋于减小的，wait time的急剧增加是存在冲突的表现，必须被有效的处理。 给node增加更多的CPUs或是给cluster增加nodes，在资源竞争中提供的benefit是非常有限的。相反，当加载系统装载增加时，CPU time的比率没有大幅下降的系统可能规模较好，更可能通过添加CPUs或是RAC Instances获得更多的benefit。 note：如果CPU time比率在前五个事件中，则automatic workload repository（AWR）报告在Top 5 Event段中显示了CPU时间和wait 时间。 2、RAC特有的调节 尽管对于RAC有其特有的调节方法，例如互联的传输，但通过对每个Instance进行像single-Instance 系统那样的调节会带来较大的benefit。至少它应该tuning的第一步。 显然，如果在single-Instance环境中存在序列化问题，在RAC中，该问题会更加严重。 RAC-reactive调节工具主要有：特定的等待事件、系统和队列统计、database control 性能页面、statspack和AWR 报告 RAC-proactive调节工具：AWR snapshots、ADDM（Automatic Database Diagnostic Monitor） 报告 如上，RAC的调节工具和single-Instance系统的基本类似。但部分特殊等待事件和统计信息的结合是RAC比较关键的调节情况。??3、分析在RAC中cache fusion（缓冲融合）的影响 在全局缓冲中访问blocks的影响和维护cache的相融合（coherency）是通过下面来表现的： * 对当前和cr blocks的全局缓冲服务统计：例如，gc当前的blocks received、gc cr blocks received等。 * 全局缓冲服务等待事件（对gc 当前 block? 3-way、gc cr grant 2-way等） cache fusion传输的响应时间是由物理交换链接组件、IPC协议和GCS协议使用的messaging时间和processing 时间决定的。 除了相关的log写操作，它是不受磁盘I/O因素的影响的。cache fusion 协议不需要对data files进行I/O，从而确保缓冲的coherency。并且RAC并不会引起比非clustered Instance更多的I/O操作。? 4、RAC操作特有的潜在因素 在RAC AWR报告中，在RAC统计一章包含了一个表，用于记录一些全局cache services和全局队列services操作的平均时间。该表被称作是Global cache and Enqueue services: workload characteristics。这些潜在因素应该得到定期的监控，并且应该对部分值的重大增加进行调查。基于经验观察，此表显示了一些代表值。引起这些潜在因素变更的因素主要有： *? IPC协议的使用。用户模式的IPC协议更快 * 当系统在CPU高效使用的情况下，时序安排的延迟 *? 对当前blocks 服务的log flush 其他在AWR报告中，RAC潜在因素多数是从V$GES_STATISTICS中获得的，并可能对调试非常有效。但无需进行频繁的监控。 note：处理缓存中一致读（consistent read CR）block的时间与（build time+flush time+send time）一致；处理缓存中当前block请求的时间与（pin time+ flush time+ send time）一致。? 5、RAC的等待事件 分析哪些sessions在等待是一个确定时间开销在哪里的重要方法。在RAC中，等待时间主要归因于影响获得实际请求结果的事件上。例如，当在某Instance上的一个session在Global cache查询某个block，并不知道是否将收到cache在其他Instance中的data或是是否将获得从disk上读取的消息。对于Global cach