Oracle Parallel Query

Oracle Parallel Query(OPQ)可以将一个SQL statement分成多个片(chunks)，然后在独自的CPU上通过多个process（子查询）进行并行运行。每个子查询同时读取一个大型表中的 一块。所有子查询完毕以后，Oracle将结果会传给并行查询调度器，他会重新安排数据，如果需要则进行排序，并且将结果传递给最终用户。OPQ具有无限 的伸缩性，因此，以前需要花费几分钟的全表检索目前的响应时间却不到1秒。

OPQ 严重依赖于处理器的数量，通过并行运行之所以能极大地提升 全表检索的性能，其前提就是使用了 N-1 个并行进程（ N=Oracle 服务器上 CPU 的数量）。Oracle 能够自动检测外部环境，包括服务器上 CPU 的数量。在安装时， Oracle9i 会检查服务器上 CPU 的数量，设置一个名为 cpu_count 的参数，并使用 cpu_count 作为默认的初始化输入参数。这些初始化参数会影响到 Oracle 对内部查询的处理。

一、相关参数

1.cpu_count

CPU_COUNT specifies the number of CPUs available to Oracle. On single-CPU computers, the value of CPU_COUNT is 1. On most platforms, Oracle automatically sets the value of CPU_COUNT to the number of CPUs available to your Oracle instance. Do not change the value of CPU_COUNT .

2. parallel_min_servers

3.parallel_max_servers

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

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

4.parallel_automatic_tuning

TRUE : ORACLE会尽量使用PARALLEL.

5.fast_start_parallel_rollback

Oracle并行机制中一个令人兴奋之处是在系统崩溃时调用并行回滚的能力。当Oracle数据库发生少有的崩溃时，Oracle能自动检测未完成的事务 并回滚到起始状态。这被称为并行热启动，而Oracle使用基于cpu_count的fast_start_parallel_rollback参数来决 定未完成事务的并行程度。能够在Oracle数据库崩溃后极大地加快其重新启动的速度。此参数的默认值是系统CPU数量的两倍，不过一些DBA们认为应该 将这个值设置为cpu_count的四倍。

FAST_START_PARALLEL_ROLLBACK determines the maximum number of processes that can exist for performing parallel rollback. This parameter is useful on systems in which some or all of the transactions are long running.Values:

 

• FALSE indicates that parallel rollback is disabled

• LOW limits the number of rollback processes to 2 * CPU_COUNT

• HIGH limits the number of rollback processes to 4 * CPU_COUNT

6.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字节的倍数。

7.db_block_lru_latches

 

二、OPQ的使用

OBJECT级

ALTER  TABLE/INDEX  XXX  PARALLEL (DEGREE 1  INSTANCES 1)

OR

ALTER  TABLE/INDEX  XXX  NOPARALLEL;

OR

Alter table customer parallel degree 35;

• Instance： Specifies the number of instances to use（除非在OPS环境，否则只需要设置为1，其他的都是无意义的）
• DEGREE: Specifies the number of slave processes to use on each instance

STATEMENT级

SELECT   --+ PARALLEL （table_alias, degree, nodes） from table …..

       或

SQLLDR

SQLLOAD scott/tiger CONTROL=con1.ctl DIRECT=TRUE PARALLEL=TRUE

Parallel Recovery

1，RECOVERY_PARALLELISM

2，RECOVER TABLESPACE tab PARALLEL (DEGREE 4);

   RECOVER DATABASE PARALLEL (DEGREE DEFAULT);

 

三、OPQ的局限性

Paralle Query并不一定是最好的，尤其是武断的把所有TABLE都设置成Paralle Query更是危险的，因为CBO会改变评估标准而尽量使用parallel full-table scans而不是index scans。因为CBO认为parallel full-table scan的cost比full-table scan低，所以如果非要这么做，那么需要调整optimizer_index_cost_adj。此值默认是1000，如果调整为10则基本都会用 INDEX，那么可以调整为小于1000的某个值，然后及时监控性能并再作调整。

ORACLE 提供了CBO、RBO两种SQL优化器：

1.Rule Based Optimizer（RBO）基于规则；

2.Cost Based Optimizer（CBO）基于成本，或者讲统计信息.

 

四、相关数据字典

select * from v_$pq_sysstat;

select * from v_$px_process;

select * from v_$px_sesstat;

select * from v_$px_process_sysstat;