oracle parallel computing

用Oracle并行查询发挥多CPU的威力

在一个单独的服务器中安装更多的 CPU成为目前的一个趋势。使用对称多处理服务器（SMP）的情况下，一个Oracle服务器拥有8个、16个或32个CPU以及几吉比特RAM的SGA 都不足为奇。
    Oracle跟上了硬件发展的步伐，提供了很多面向多CPU的功能。从Oracle8i开始，Oracle在每个数据库 函数 中都实现了并行性，包括SQL 访问（全表检索）、并行数据操作和并 行恢复。对于Oracle专业版的挑战是为用户的数据库配置尽可能多的CPU。

    在Oracle环境中实现并行性最好的方法之一是使用Oracle并行查询（OPQ）。我将讨论OPQ是如何工作的和怎样用它来提升大的全表检索的响应时 间以及调用并行事务回滚等等。

   使用OPQ

    当在Oracle中进行一次合法的、大型的全表检索时，OPQ能够极大地提高响应时间。通过OPQ，Oracle将表划分成如图A所示的逻辑块。

    由 OPQ划分的表

    一旦表被划分成块，Oracle启用并行的子查询（有时称为杂务进程），每个子查询同时读取一个大型表中的一块。所有子查询完毕以后，Oracle将结果 会传给并行查询调度器，它会重新安排数据，如果需要则进行排序，并且将结果传递给最终用户。OPQ具有无限的伸缩性，因此，以前需要花费几分钟的全表检索 现在的响应时间却不到1秒。

    OPQ严重依赖于处理器的数量，通过并行运行之所以可以极大地提升全表检索的性能，其前提就是使用了N-1个并行进程（N=Oracle服务器上CPU的 数量）。

    必须注意非常重要的一点，即Oracle9i能够自动检测外部环境，包括服务器上CPU的数量。在安装时，Oracle9i会检查服务器上CPU的数量， 设置一个名为cpu_count的参数，并使用cpu_count作为默认的初始化输入参数。这些初始化参数会影响到Oracle对内部查询的处理。

    下面就是Orale在安装时根据cpu_count而设置的一些参数：

    fast_start_parallel_rollback
    parallel_max_servers
    log_buffer
    db_block_lru_latches

参数     

    让我们进一步看看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的巨大服务器上来的时候，这些参数显 得愈发重要。

 

 

 

oracle parallel execution example

引子：以前一直没太关注oracle并行这个特性。前几天一个兄弟碰 到的一个问题，才让我觉得这个东西还是有很多需要注意的地方，有必要仔细熟悉下。其实碰到的问题不复杂:

类似如下的一条语句：insert into xxxx select /*+parallel(a) */ * from xxx a;数据量大约在75G左右，这位兄弟从上午跑到下午还没跑完，过来问我咋回事，说平常2hrs能跑完的东西跑了好几个小时还撒动静。查看系统性能也比较 正常，cpu，io都不繁忙，平均READ速度在80M/s左右（勉强凑合），但平均写速度只有10M不到。等待事件里面大量的‘ ‘PX Deq Credit : send blkd ’，这里能看出并行出了问题，从而最 后得知是并行用法有问题，修改之后20分钟完成了该操作。正确的做法应该是：
alter session enable dml parallel；

insert /*+parallel(xxxx,4) */ into xxxx select /*+parallel(a) */ * from xxx a;

因为oracle默认并不会打开PDML，对DML语句必须手工启用。 另外不得不说的是，并行不是一个可扩展的特性，只有在数据仓库或作为DBA等少数人的工具在批量数据操作时利于充分利用资源，而在OLTP环境下使用并行 需要非常谨慎。事实上PDML还是有比较多的限制的，例如不支持触发器，引用约束，高级复制和分布式事务等特性，同时也会带来额外的空间占用，PDDL同 样是如此。有关Parallel excution可参考官方文档 ，在Thomas Kyte的新书《Expert Oracle Database architecture》也有精辟的讲述。