关于创建索引时使用parallel的疑问

chiyiangel

在创建index 的时候 使用create index index_name_xxx on table_name_xxx(column_name_xxx) tablespace tablespace_name_xxx NOLOGGING PARALLEL 8;

在创建完索引以后在dba_indexes里对应的 degree 为8
请问如果建完索引后 不ALTER INDEX index_name_xxx NOPARALLEL;我在使用索引的时候会有什么影响

能否具体分析下 parallel 带来的优劣？

Maclean Liu(刘相兵

ODM TEST:

SQL> select count(*) from small;

  COUNT(*)
----------
     72772
         

SQL> set autotrace traceonly;
SQL> set timing on;      
SQL> select * from small;

72772 rows selected.

Elapsed: 00:00:01.30

Execution Plan
----------------------------------------------------------
Plan hash value: 2557977142

---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       | 84312 |    16M|   284   (1)| 00:00:04 |
|   1 |  TABLE ACCESS FULL| SMALL | 84312 |    16M|   284   (1)| 00:00:04 |
---------------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       5815  consistent gets
          0  physical reads
          0  redo size
    8329374  bytes sent via SQL*Net to client
      53884  bytes received via SQL*Net from client
       4853  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      72772  rows processed


SQL> select /*+ parallel */ * from small;

72772 rows selected.

Elapsed: 00:00:02.63


Execution Plan
----------------------------------------------------------
Plan hash value: 3363491925

--------------------------------------------------------------------------------------------------------------
| Id  | Operation            | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |          | 84312 |    16M|    39   (0)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR      |          |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)| :TQ10000 | 84312 |    16M|    39   (0)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |    PX BLOCK ITERATOR |          | 84312 |    16M|    39   (0)| 00:00:01 |  Q1,00 | PCWC |            |
|   4 |     TABLE ACCESS FULL| SMALL    | 84312 |    16M|    39   (0)| 00:00:01 |  Q1,00 | PCWP |            |
--------------------------------------------------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement (level=2)
   - automatic DOP: skipped because of IO calibrate statistics are missing


Statistics
----------------------------------------------------------
         98  recursive calls
          0  db block gets
       1685  consistent gets
          0  physical reads
          0  redo size
    3793382  bytes sent via SQL*Net to client
      53884  bytes received via SQL*Net from client
       4853  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
      72772  rows processed

Maclean Liu(刘相兵

启用并行 的前提是 并行能带来收益 ，

试想对于一些OLTP类型的操作 如小表的FULL TABLE SCAN或者 Nested Loop等，  表本身的大小只有 几兆 ，串行的全表逻辑扫描只需要 几毫秒，   但是如果并行执行， 那么并行需要 分配并行子进程、分配Slave进程的工作范围，并行的工作协调PX COORDINATOR 这些都是额外的开销 ， 对于一个简单的可以在几至 几十毫秒完成的OLTP操作而言， 复杂的并行开销 比操作本身 要耗时 和耗费资源的多， 换句话说 在这种场景中使用 并行 那么是为了并行而并行 ，不是为了 提高效率或性能。

一个实例本身的并行资源是有限的，例如parallel slave的总数受到实例参数的限制， 并行进程还会大量消耗PGA内存。在OLTP环境中 查询或DML操作的频率是很高的，如果每一个select或者DML 都要用到parallel并行的话，就会造成并行资源的争用，造成糟糕的性能。

此外 并行参数还会让 optimizer 更青睐于 FULL TABLE SCAN 、Fast FULL INDEX SCAN这类操作。