px运行前的注意点1：
1、sga的设置，由于px运行时，根据PARALLEL_AUTOMATIC_TUNING参数设置（官文上说那个参数已废，只是为了向后兼容），会占用shared pool或large pool的内存，至少要多占用25%的那个session的shared pool的量
2、回滚段的设置，由于px的每一个子进程都会开启一个transactions，而每一个transaction都会占一个回滚段，所以执行px时，虽然总的回滚量不会有太大变化，但是在执行px期间将会对回滚段产生极大的争用，所以执行前要注意观察回滚段的争用情况
3、redo的观察，由于px执行期间将极大地产生redo信息，所以在执行期间要观察 归档的产生量以及redo的切换的频繁程度，避免出现checkpoint not complete的情况。
4、pga的设置，主要是sort area和hash area，还有PARALLEL_BROADCAST_ENABLED设置成true时对pga的影响

px运行前的注意点2：
1、能不用px执行的尽量不用px，px slave processes采用的是direct path read来读取数据，也就是说，px肯定会产生很多物理读，因为不能利用buffer cache里的内容，那px slave processes是怎么取得信息呢：是通过 message pool来通信的，message pool跟parallel_automatic_tuning 参数有关，（前面说了，10g后该参数已经废掉，默认false），如果false，那就是放在 shared_pool 中，而放的多少，又主要与parallel_execution_message_size 参数有关，10g默认是 2K。所以说，对于小表，我们应该避免使用并行，因为效率反而没有 normal query高。这里贴上一个公式来说明：buffer space = (3 x size x users x groups x connections)。再贴上一坛友的执行计划来看看：

SQL> select count(*) from test;

  COUNT(*)
----------
    705705

已用时间:  00: 00: 00.06

-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |  2143   (2)| 00:00:26 |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| TEST |   657K|  2143   (2)| 00:00:26 |
-------------------------------------------------------------------

统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       9666  consistent gets
          0  physical reads
          0  redo size
        410  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
--------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------
SQL> select /*+ parallel(test,8)  */count(*) from test;

  COUNT(*)
----------
    705705

已用时间:  00: 00: 02.85

--------------------------------------------------------------------------------------------------------
| Id  | Operation              | Name     | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |          |     1 |   296   (1)| 00:00:04 |        |      |            |
|   1 |  SORT AGGREGATE        |          |     1 |            |          |        |      |            |
|   2 |   PX COORDINATOR       |          |       |            |          |        |      |            |
|   3 |    PX SEND QC (RANDOM) | :TQ10000 |     1 |            |          |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE     |          |     1 |            |          |  Q1,00 | PCWP |            |
|   5 |      PX BLOCK ITERATOR |          |   657K|   296   (1)| 00:00:04 |  Q1,00 | PCWC |            |
|   6 |       TABLE ACCESS FULL| TEST     |   657K|   296   (1)| 00:00:04 |  Q1,00 | PCWP |            |
--------------------------------------------------------------------------------------------------------

统计信息
----------------------------------------------------------
         40  recursive calls
          0  db block gets
       9977  consistent gets
       9655  physical reads
          0  redo size
        410  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processed

2、hint优先，如果一定要修改表的degree属性，那么一定要注意观察，不要一个过程就把表给死锁了
3、oracle并不一定根据我们指定的并行度来设定slave process，有以下几种情况会使我们指定的并行度被系统自动调整或根本不会用：
   3.1、在一个小表上使用px；
   3.2、使用px时有磁盘竞争，这里就建议对表空间指定多个小数据文件，而不是指定几个大的，因为优化器会觉得太多的并行进程在少数几个datafile上会引起磁盘竞争而减少并行度；
   3.3、cpu竞争，一般我们建议在每一个实例上设置的并行度不多于2*cpu个数，或者采用默认的并行度；
   3.4、不佳的分区表，这就是说如果我们有很多并行进程去操作很少量的分区表的话，系统会减少并行进程，比如3个并行进程就分别操作3个分区（我们原先设定20个）

parallel query：对于非分区表，全表扫描时将用到，根据rowid来分slave process
                对于分区表，全表扫描和index range scan(local index)时将用到，index range scan时，hint要使用parallel_index而不是parallel，根据分区来分slave process，也有可能一个slave process处理多个分区
                hint优先，如果没有hint，那各个关联的表中，取degree最高的那个
                如果有聚合操作，slave process的个数还将加倍
parallel dml：update和delete 只能是分区表，而且要 table access full或index range scan多个分区时才能并行
              insert：只有insert .. select ...才能使用并行，不论分区和非分区
              要想 dml 生效，一定要 enable parallel dml;
              具体的可看
              http://www.itpub.net/viewthread.php?tid=1242399&pid=14709002&page=1&extra=page%3D1
              这个网址
parallel ddl：不说了，^_^

观察 px
可看 v$px 或v$pq（说是ops的）开头的视图