用Oracle并行查询发挥多CPU的威力（２）:2012年Oracle考试:应用技术-百考试题网

　让我们进一步看看CPU的数量是如何影响这些参数的。

　参数fast_start_parallel_rollback

　Oracle并行机制中一个令人兴奋之处是在系统崩溃时调用并行回滚得能力。当Oracle数据库发生少有的崩溃时，Oracle能自动检测未完成的事务并回滚到起始状态。这被称为并行热启动，而Oracle使用基于cpu_count的fast_start_parallel_rollback参数来决定未完成事务的秉性程度。

　并行数据操纵语言（DML）恢复能够在Oracle数据库崩溃后极大地加快其重新启动的速度。此参数的默认值是系统CPU数量的两倍，但是一些DBA们认为应该将这个值设置为cpu_count的四倍。

　参数parallel_max_servers_parameter

　Oracle一个显著的加强是自动决定OPQ并行的程度。由于Oracle清楚服务器中CPU的数量，它会自动分配合适的子进程的数量来提升并行查询的响应时间。当然，会有其它的外部因素，比如表的划分以及磁盘输入/输出子系统的布局等，但是根据cpu_count来设置parallel_max_servers参数将给Oracle一个合理的依据来选择并行的程度。

　由于Oracle的并行操作严重依赖服务器上CPU的数量，parallel_max_servers会被设置成服务器上CPU的数量。如果在一台服务器上运行多个实例，则默认值太大了，会导致过度的页面交换和严重的CPU负担。并行的程度还依赖于目标表中分区的数量，因此parallel_max_servers应该设置成足够大以允许Oracle为每个查询选择最佳数量的并行子查询。

　参数log_buffer

　参数log_buffer定义了供即刻写入redo日志信息的保留RAM的数量，这个参数受cpu_count的影响。Oracle推荐log_buffer最大为cpu_count乘以500KB或128KB。CPU的数量对于log_buffer来说非常重要，因为Oracle会生成多日志写入（LGWR）进程来异步释放redo信息。

　log_buffer是Oracle中最易误解的的RAM参数之一，通常存在下面几个配置错误：

　log_buffer被设置得太高（例如，大于1MB），这回引起性能问题，因为大容量的结果会使得写入同步进行（例如，日志同步等待事件非常高）。log_buffer不是db_block_size的倍数。在的Oracle9i中，log_buffer应该是2048字节的倍数。

　参数db_block_lru_latches

　 LRU锁的数量是在Oracle数据库内部用来管理数据库缓冲的，这严重依赖于服务器上CPU的数量。

　很多聪明的Oracle9i的DBA使用多冲数据缓冲（例如db_32k_cache_size），他们推荐将这个未公开声明的参数重设置为默认的最大值。db_block_lru_latches参数在Oracle8i中使用得很多，但是在Oracle9i中变成了一个未公开声明的参数，因为Oracle现在根据数据库拥有的CPU数量设置了一个合理的默认值。

　db_block_lru_latches默认被设置为服务器上cpu_count的一半（例如服务器上只有一个Oracle数据库）。Oracle推荐db_block_lru_latches千万不要超过cpu_count的两倍或三倍，或db_block_buffers的五十分之一。

　如果使用多缓冲池则这种计算方法有一个问题，因为不能控制分配给每个数据缓冲池的锁的数量。如果db_writers参数大于1，则默认值或许显得太小。

　加强服务器

　Oracle数据库总是在提升性能，根据外部服务器环境检测cpu_count和基本参数设置的能力对于Oracle软件来说是一个重要的加强。

　随着更多的Oracle系统转移到SMP上来，当客户要采取增强措施并将众多的数据库转移到拥有32个或64个CPU的巨大服务器上来的时候，这些参数显得愈发重要。