并行查询

并行查询的两种方法：

1、直接在查询中使用一个提示；

2、修改表，要求考虑并行执行路径。

第一种方法：select /*+paralle(a,4)*/ count(status) from big_table;

第二种方法：alter table big_table parallel 4;

还有一种方法比较智能，即在系统CPU资源比较充足的时候，并行度会增加，而相反在CPU资源比较紧张的时候，并行度会减少。

启用这种方式如下所示：

alter table big_table parallel;

并行查询需要保证两个前提

第一，你需要执行一个大任务，例如，一个长时间运行的查询，这个查询的运行时间要分钟、小时、天为单位来度量，而不是秒或者次秒。

第二、需要有充足的资源，如CPU、磁盘I/O和内存。

并行DML

select并行查询不需要显示开启就可以用并行查询，而PDML（insert、delete、update、merge）需要显式启用会话并行查询：

alter session enable parallel dml;

由于PDML 采用的一种伪分布式的实现，因此存在一些限制：

• PDML 操作期间不支持触发器。在我看来，这是一个很合理的限制，因为触发器可能会向更新增加大量开销，而你使用PDML 的本来目的是为了更快一些，这两方面是矛盾的，不能放在一起。
• PDML 期间，不支持某些声明方式的引用完整性约束，因为表中的每一片（部分）会在单独的会话中作为单独的事务进行修改。例如，PDML 操作不支持自引用完整性。如果真的支持自引用完整性，可能会出现死锁和其他锁定问题。
• 在提交或回滚之前，不能访问用PDML 修改的表。
• PDML 不支持高级复制（因为复制特性的实现要基于触发器）。
• 不支持延迟约束（也就是说，采用延迟模式的约束）。
• 如果表是分区的，PDML 只可能在有位图索引或LOB 列的表上执行，而且并行度取决于分区数。在这种情况下，无法在分区内并行执行一个操作，因为每个分区只有一个并行执行服务器来处理。
• 执行PDML 时不支持分布式事务。
• PDML 不支持聚簇表。

如果违反了上述任何一个限制，就会发生下面的某种情况：

语句会串行执行（完全不涉及并行化），或者会产生一个错误。例如，如果对表T 执行PDML，然后在结束事务之前试图查询表T，就会收到一个错误。

并行DDL

以下SQL DDL 命令允许”并行化“：

• CREATE INDEX：多个并行执行服务器可以扫描表、对数据排序，并把有序的段写出到索引结构。
• CREATE TABLE AS SELECT：执行SELECT 的查询可以使用并行查询来执行，表加载本身可以并行完成。
• ALTER INDEX REBUILD：索引结构可以并行重建。
• ALTER TABLE MOVE：表可以并行移动。
• ALTER TABLE SPLIT|COALESCE PARTITION：单个表分区可以并行地分解或合并。
• ALTER INDEX SPLIT PARTITION：索引分区可以并行地分解。

并行DDL 和使用外部表的数据加载，在create table as select 语句建表的时候启用并行，如下：

SQL> create table new_table parallel
 2 as
 3 select a.*, b.user_id
 4 from big_table a, user_info b
 5 where a.owner = b.username;

并行DDL 和区段截断

区段空间管理有两种方法。

一种是字段管理区段空间，一种是本地管理区段空间。

分别对应的参数为：uniform size 和 autoallocate。在并行直接路径加载操作中，前者不会发生区段截断而后者会发生区段截断。

应该使用哪种方法呢？

如果你的目标是尽可能经常并行地执行直接路径加载，建议采用AUTOALLOCATE作为区段管理策略。诸如此类的并行直接路径操作不会使用对象HWM 以下的已用空间，即不会用freelits 上的空间。除非你还要对表执行一些传统路径插入，否则UNIFORM 分配方法会在这些表中永久地保留一些从不使用的额外空闲空间。除非你能把UNIFORM LMT 的区段大小定得更小，否则，过一段时间后，就会看到区段过度浪费的情况：而且要记住，这些空间与段有关，所以对表进行完全扫描时也必须扫描这些空间。

并行恢复

Oracle 中还有另一种形式的并行执行，即能够执行并行恢复。并行恢复（parallel recovery） 可以在实例级完成，使得软件、操作系统或一般系统失败后可以更快地执行所需的恢复。还可以在介质恢复中应用并行恢复（例如，从备份恢复）。