关于创建索引时使用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(刘相兵

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

试想对于一些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这类操作。

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