oracle 并行查询 parallel query 81 53,5297p_base_day_i_newtareduser2009-06-25 17:28:562009-06-25 18:24:2155insert成功base 82 53,5300p_base_day_i_newtareduser_test2009-06-25 17:29:312009-06-25 17:54:2124insert成功base 这是两个同样的过程 访问
oracle 并行查询 parallel query
81    53,5297 p_base_day_i_newtareduser 2009-06-25 17:28:56 2009-06-25 18:24:21 55 insert 成功 base
82    53,5300 p_base_day_i_newtareduser_test 2009-06-25 17:29:31 2009-06-25 17:54:21 24 insert 成功 base
这是两个同样的过程 访问6千万的数据进行inner join 统计 前个花了55分钟 后一个花了24分钟
insert /*+parallel(t_newtraed_test,4) */ into  t_newtraed_test 
  select  b.addtime,0,b.username,sysdate,0,c.lotid,0,c.playid,0,0,sysdate
  from
  (
       select  username,min(addtime) as addtime 
       from
       (
              select /*+ parallel(x, 5) parallel(z, 5)*/ x.f_username as username ,x.f_addtime as addtime
              from t_gather_prouser x
              inner join t_gather_project z on x.f_projectid = z.f_id and x.f_lotteryid=z.f_lotteryid
 ....
对表可以
alter table ba.p_admin   parallel ( degree default instances default );
这个由oracle 自己决定
可经常报 ora-12801: 并行查询服务器 p029 中发出错误信号
ora-00018: 超出最大会话数
由此可见 它开了太多的会话数。
下面些资料可供参考
由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的巨大服务器上来的时候，这些参数显得愈发重要。