一般表数据量比较大（超过100万）时，可以使用parallel强制启动并行度来提升查询速度
创新互联专业为企业提供宁陕网站建设、宁陕做网站、宁陕网站设计、宁陕网站制作等企业网站建设、网页设计与制作、宁陕企业网站模板建站服务，10年宁陕做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。
用法：/*+parallel(table_short_name,cash_number)*/
可以加到insert、delete、update、select的后面来使用
比如：select /*+paralle(t,32)*/ from table t; table_short_name使用别名，Parallel后面的数字，越大，执行效率越高，一般用8，10，12，16，32。不过，数值越大，占用的资源也会相对增大。如果在查询where后的条件有加索引查询效率会大大提高。
建索引时，我们为了建索引快，会加上并行，加上并行之后，此列索引就会是并行了。访问有并行度的索引时，CBO可能可能会考虑并行执行，这可能会引发一些问题，如在服务器资源紧张的时候用并行会引起更加严重的争用。当使用并行后，需要把并行度改回来。\x0d\x0aSQL drop table test purge;\x0d\x0aSQL create table test as select * from dba_objects;\x0d\x0aSQL create index ind_t_object_id on test(object_id) parallel 4 ;\x0d\x0aSQL select s.degree\x0d\x0afrom dba_indexes s\x0d\x0awhere s.index_name = upper('ind_t_object_id');\x0d\x0aDEGREE\x0d\x0a----------------------------------------\x0d\x0a4\x0d\x0a\x0d\x0aSQL alter index ind_t_object_id noparallel;\x0d\x0a\x0d\x0aSQL select s.degree\x0d\x0afrom dba_indexes s\x0d\x0awhere s.index_name = upper('ind_t_object_id');\x0d\x0aDEGREE\x0d\x0a----------------------------------------\x0d\x0a1
Redo log 是用于恢复和一个高级特性的重要数据 一个redo条目包含了相应操作导致的数据库变化的所有信息 所有redo条目最终都要被写入redo文件中去 Redo log buffer是为了避免Redo文件IO导致性能瓶颈而在sga中分配出的一块内存 一个redo条目首先在用户内存(PGA)中产生 然后由oracle服务进程拷贝到log buffer中 当满足一定条件时 再由LGWR进程写入redo文件 由于log buffer是一块 共享 内存 为了避免冲突 它是受到redo allocation latch保护的 每个服务进程需要先获取到该latch才能分配redo buffer 因此在高并发且数据修改频繁的oltp系统中 我们通常可以观察到redo allocation latch的等待 Redo写入redo buffer的整个过程如下
在PGA中生产Redo Enrey 服务进程获取Redo Copy latch(存在多个 CPU_COUNT* ) 服务进程获取redo allocation latch(仅 个) 分配log buffer 释放redo allocation latch 将Redo Entry写入Log Buffer 释放Redo Copy latch;
shared strand
为了减少redo allocation latch等待 在oracle 中 引入了log buffer的并行机制 其基本原理就是 将log buffer划分为多个小的buffer 这些小的buffer被成为strand(为了和之后出现的private strand区别 它们被称之为shared strand) 每一个strand受到一个单独redo allocation latch的保护 多个shared strand的出现 使原来序列化的redo buffer分配变成了并行的过程 从而减少了redo allocation latch等待
shared strand的初始数据量是由参数log_paralleli *** 控制的;在 g中 该参数成为隐含参数 并新增参数_log_paralleli *** _max控制shared strand的最大数量;_log_paralleli *** _dynamic则控制是否允许shared strand数量在_log_paralleli *** 和_log_paralleli *** _max之间动态变化
HELLODBA select nam ksppinm val KSPPSTVL nam ksppdesc from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm LIKE _% AND upper(nam ksppinm) LIKE %LOG_PARALLE% ; KSPPINM KSPPSTVL KSPPDESC _log_paralleli *** Number of log buffer strands _log_paralleli *** _max Maximum number of log buffer strands _log_paralleli *** _dynamic TRUE Enable dynamic strands
每一个shared strand的大小 = log_buffer/(shared strand数量) strand信息可以由表x$kcrfstrand查到(包含shared strand和后面介绍的private strand g以后存在)
HELLODBA select indx strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa != ; INDX STRAND_SIZE_KCRFA HELLODBA show parameter log_buffer NAME TYPE VALUE log_buffer integer
关于shared strand的数量设置 个cpu之内最大默认为 当系统中存在redo allocation latch等待时 每增加 个cpu可以考虑增加 个strand 最大不应该超过 并且_log_paralleli *** _max不允许大于cpu_count
注意 在 g中 参数_log_paralleli *** 被取消 shared strand数量由_log_paralleli *** _max _log_paralleli *** _dynamic和cpu_count控制
Private strand
为了进一步降低redo buffer冲突 在 g中引入了新的strand机制——Private strand Private strand不是从log buffer中划分的 而是在shared pool中分配的一块内存空间
HELLODBA select * from V$sgastat where name like %strand% ;POOL NAME BYTES shared pool private strands HELLODBA select indx strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa = ;INDX STRAND_SIZE_KCRFA
Private strand的引入为Oracle的Redo/Undo机制带来很大的变化 每一个Private strand受到一个单独的redo allocation latch保护 每个Private strand作为 私有的 strand只会服务于一个活动事务 获取到了Private strand的用户事务不是在PGA中而是在Private strand生成Redo 当flush private strand或者mit时 Private strand被批量写入log文件中 如果新事务申请不到Private strand的redo allocation latch 则会继续遵循旧的redo buffer机制 申请写入shared strand中 事务是否使用Private strand 可以由x$ktcxb的字段ktcxbflg的新增的第 位鉴定
HELLODBA select decode(bitand(ktcxbflg ) ) used_private_strand count(*) from x$ktcxb where bitand(ksspaflg ) != and bitand(ktcxbflg ) != group by bitand(ktcxbflg );USED_PRIVATE_STRAND COUNT(*)
对于使用Private strand的事务 无需先申请Redo Copy Latch 也无需申请Shared Strand的redo allocation latch 而是flush或mit是批量写入磁盘 因此减少了Redo Copy Latch和redo allocation latch申请/释放次数 也减少了这些latch的等待 从而降低了CPU的负荷 过程如下
事务开始 申请Private strand的redo allocation latch (申请失败则申请Shared Strand的redo allocation latch) 在Private strand中生产Redo Enrey Flush/Commit 申请Redo Copy Latch 服务进程将Redo Entry批量写入Log File 释放Redo Copy Latch 释放Private strand的redo allocation latch
注意 对于未能获取到Private strand的redo allocation latch的事务 在事务结束前 即使已经有其它事务释放了Private strand 也不会再申请Private strand了
每个Private strand的大小为 K g中 shared pool中的Private strands的大小就是活跃会话数乘以 K 而 g中 在shared pool中需要为每个Private strand额外分配 k的管理空间 即 数量* k
g:SQL select * from V$sgastat where name like %strand% ;POOL NAME BYTES shared pool private strands HELLODBA select trunc(value * KSPPSTVL / ) * * from (select value from v$parameter where name = transactions ) a (select val KSPPSTVL from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_paralleli *** _mul ) b;TRUNC(VALUE*KSPPSTVL/ )* * g:HELLODBA select * from V$sgastat where name like %strand% ;POOL NAME BYTES shared pool private strands HELLODBA select trunc(value * KSPPSTVL / ) * ( + ) * from (select value from v$parameter where name = transactions ) a (select val KSPPSTVL from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_paralleli *** _mul ) b;TRUNC(VALUE*KSPPSTVL/ )*( + )*
Private strand的数量受到 个方面的影响 logfile的大小和活跃事务数量
参数_log_private_mul指定了使用多少logfile空间预分配给Private strand 默认为 我们可以根据当前logfile的大小(要除去预分配给log buffer的空间)计算出这一约束条件下能够预分配多少个Private strand
HELLODBA select bytes from v$log where status = CURRENT ;BYTES HELLODBA select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))* (select to_number(val KSPPSTVL) from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_mul ) / / ) as calculated private strands from dual;calculated private strands HELLODBA select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa = ;actual private strands
当logfile切换后(和checkpoint一样 切换之前必须要将所有Private strand的内容flush到logfile中 因此我们在alert log中可能会发现日志切换信息之前会有这样的信息 Private strand flush not plete 这是可以被忽略的) 会重新根据切换后的logfile的大小计算对Private strand的限制
HELLODBA alter system switch logfile;System altered HELLODBA select bytes from v$log where status = CURRENT ;BYTES HELLODBA select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))* (select to_number(val KSPPSTVL) from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_mul ) / / ) as calculated private strands from dual;calculated private strands HELLODBA select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa = ;actual private strands
参数_log_private_paralleli *** _mul用于推算活跃事务数量在最大事务数量中的百分比 默认为 Private strand的数量不能大于活跃事务的数量
HELLODBA show parameter transactionsNAME TYPE VALUE transactions integer transactions_per_rollback_segment integer HELLODBA select trunc((select to_number(value) from v$parameter where name = transactions ) * (select to_number(val KSPPSTVL) from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_paralleli *** _mul ) / ) as calculated private strands from dual;calculated private strands HELLODBA select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa = ;actual private strands
注 在预分配Private strand时 会选择上述 个条件限制下最小一个数量 但相应的shared pool的内存分配和redo allocation latch的数量是按照活跃事务数预分配的
lishixinzhi/Article/program/Oracle/201311/17848
Oracle试图自动化系统配置来使并行操作的性能最大化。然而，仍然有许多手工调整的空间，我们可以调整数据库，优化SQL并行性能。
判断并行度
合适的并行度DOP对于良好的并行性能很关键。Oracle会按如下方式设定DOP：
1、如果指定或请求了并行执行，但是没有指定DOP，默认DOP会设置为该系统上CPU内核数量的两倍。对于RAC系统，DOP值会是整个集群内核数量的两倍。默认值是由配置参数“PARALLEL_ THREADS_PER_CPU”控制的。
2、对于Oracle 11g R2之后的版本，如果“ PARALLEL_DEGREE_POLICY”被设置为“AUTO”，Oracle将根据被执行的运行性质和涉及对象的大小自动调整DOP值。
3、如果“PARALLEL_ADAPTIVE_MULTI_USER”被设置为“TRUE”，Oracle将基于该系统的整个负载调整DOP。当系统承受更重的负载时，DOP值将会减少。
4、在Oracle 11g或者更高版本中，如果“PARALLEL_IO_CAP ”被设置为TRUE，Oracle将把DOP限制为IO子系统可以支持的值。这些IO子系统限制可以通过“DBMS_RESOURCE_ MANAGER.CALIBRATE_IO”存储过程计算。
5、DOP可以被指定到表或者索引一级，可以通过在“CREATE TABLE”，“CREATE INDEX”，“ALTER TABLE”或者“ALTER INDEX”中使用“PARALLEL ”从句来实现。
6、“PARALLEL ”关键字可以被用来指定某个查询中指定表的DOP。
7、不管任何其它设置，DOP不能超过“PARALLEL_MAX_SERVERS”可以支持的数量。对于大部分SQL语句，服务器数量需要是请求DOP的两倍。
正如我们可以看到的，超过优化点增减DOP会导致进一步性能提升的失败。然而，超过最佳优化限制强行增加DOP值会对整个系统性能带来重大的负面影响。尽管被并行化的SQL可能不会随着DOP的增加而降低，但是该系统的负载会持续增加，而且会引起其它并发运行的SQL要遭受响应时间降低的影响。
当我们达到最优DOP点时(该系统中的值大约是8)，查询时间的减少变的平缓了。然而，其它会话在等待CPU可用上花费的时间会持续增长。其它等待访问CPU的会话将需要继续等待，这会导致响应时间变慢。
并行概念
并行执行（parallel execution）是Oracle企业版才有的特性（标准版中没有这个特性），指能够将一个大型串行任务（任何DML，或者一般的DDL）物理地划分为多个较小的部分，这些较小的部分可以同时得到处理。
并行包括：
并行查询：这是指能使用多个操作系统进程或线程来执行一个查询。Oracle会发现能并行执行的操作（如全表扫描或大规模排序），并创建一个查询计划来实现）。
并行DML（PDML）：这在本质上与并行查询很相似，但是PDML主要是使用并行处理来执行修改（INSERT、UPDATE、DELETE和MERGE）。
并行DDL：并行DDL是指Oracle能并行地执行大规模的DDL操作。例如，索引重建、创建一个新索引、数据加载以及大表的重组等都可以使用并行处理。
并行恢复：这是指数据库能并行地执行实例（甚至介质）恢复，以减少从故障恢复所需的时间。
过程并行化：这是指能并行地运行所开发的代码。
何时使用并行
在应用并行执行之前，需要保证以下两点成立：
必须有一个非常大的任务，如对50GB数据进行全面扫描。
必须有足够的可用资源（CPU、I/O、内存）。在并行全面扫描50GB数据之前，你要确保有足够的空闲CPU（以容纳并行进程），还要有足够的I/O通道。
如果只有一个小任务（通常OLTP系统中执行的查询就是这种典型的小任务），或者你的可用资源不足（这也是OLTP系统中很典型的情况），其中CPU和I/O资源通常已经得到最大限度的使用，那就根本不用考虑并行执行。
如果一个任务只需要几秒（或更短时间）就能串行地完成，引入并行执行后，相关的管理开销可能会让整个过程花费更长的时间。
举例如，写一页文档若12个人来写，需要开会分段等，可能并不如一个人来写更快。而如果写1200页，12个人写需要的时间只为原来的1/12，就算分配任务可能也就1/12，还是比一个人写要快多了。
并行查询
并行查询允许将一个SQL SELECT语句划分为多个较小的查询，每个部分的查询并发地运行，然后会将各个部分的结果组合起来，提供最终的答案。
在并行进程和扫描文件之间并不存在1对1映射，可以多个进程扫描同一个文件。
各个并行进程可称为并行执行服务器（parallel execution server），有时也称为并行查询（parallel
query，PQ）从属进程。各个并行执行服务器都是单独的会话，就像是专业服务器进程一样连接数据库。每个并行执行服务器分别负责扫描表中一个部分（各
个部分都不重叠），汇总其结果子集，将其输出发回给协调服务器（即原始会话的服务器进程），它再将这些子结果汇总为最终答案。
在默认情况下，Oracle是不启用并行查询的。启用并行查询有多种方法，可以直接在查询中使用一个提示，或者修改表要求考虑并行执行路径等。
【并行查询方法】
1）暗示hints式，临时有效
select /*+parallel(table_name num)*/ count(*) from table_name;
多表关联时多表并行：
select /*+parallel(table_name1,num1) parallel(table_name2,num2)*/ count(*) from table_name1, table_name2;
2）alter table对象式，长期有效
alter table table_name parallel num;
3）alter session会话式，会话生命周期有效
alter session force parallel query parallel num;
4）并行DDL式，会话生命周期有效
alter session enable parallel dml;
对于前两种方式，若省略num则Oracle将自动根据负载确定并行度。并行度要随着系统上工作负载的增减而变化。如果有充足的空闲资源，并行度会
上升；如果可用资源有限，并行度则会下降。这样就不会为机器强加一个固定的并行度。利用这种方法，允许Oracle动态地增加或减少查询所需的并发资源
量。
【查看默认并行数】
1）确定会话SID
select sid from v$mystat where rownum = 1;
2）在其他会话中查询
select sid,qcsid,server#,degree from v$px_session where qcsid = num;
一般而言，如果能访问尽可能多的资源（CPU、内存和I/O），并行执行就能最好地发挥作用。但这并不是说如果整个数据集都在一个磁盘上，就从并行
查询得不到任何好处。不过如果整个数据集都在一个磁盘上，可能确实不如使用多个磁盘那样能有更多收获。即使使用一个磁盘，在响应时间上也可能可以得到一定
的速度提升。原因在于：给定的一个并行执行服务器在统计行时并不读取这些行，反之亦然。所以，与执行串行相比，两个并行执行服务器可以在更短的时间内完成
所有行的统计。
数据分布在多个物理设备上可以提高I/O，如表分区、跨磁盘等。
在Oracle 11g Release2及以上版本中，引入了一项新功能来限制资源过度使用：并行语句排除（Parallel
Statement
Queuing,PSQ）。使用PSQ时，数据库会限制并发执行的并行查询数，并把更多的并行请求放在一个执行队列中。CPU资源用尽时数据库会阻止新的
请求变为活动状态。这些请求并没有失败，它们只是会延迟开始，也就是说它们将排队。资源可用时，数据库就会开始执行队列中的查询。
并行DML
Oracle文档将并行DML（PDML）一词的范围限制为只包括INSERT、UPDATE、DELETE和MERGE（不像平常的DML那样还
包括SELECT）。在PDML期间，Oracle可以使用多个并行执行服务器来执行INSERT、UPDATE、DELETE或MERGE，而不是只利
用一个串行进程。在一个有充足I/O带宽的多CPU主机上，对于大规模的DML操作，可能会得到很大的速度提升。
不过，不能把PDML当成提高OLTP应用速度的一个特性。因为并行操作设计为要充分、完全地利用一台机器上的所有资源。通过这种设计，一个用户可
以完全使用机器上的所有磁盘、CPU和内存。在某些数据仓库中（有大量数据，而用户很少），这可能正是你想要的。而在一个OLTP系统中（大量用户都在做
很短、很快的事务），可能就不能希望如此了，你不想让用户能够完全占用机器资源。
类似于Oracle执行的分布式查询，PDML操作采用同样的方式执行，即每个并行执行服务器相当于一个单独数据库实例中的一个进程。这些事务都结束后，会执行一个相当于快速2PC的过程来提交这些单独的独立事务。这些事务要么都由PDML协调会话提交，要么无一提交。
由于PDML采用的一种伪分布式的实现，因此存在一些限制：
PDML操作期间不支持触发器。这是一个很合理的限制，因为触发器可能会向更新增加大量开销，而你使用PDML的本来目的是为了更快一些，这两方面是矛盾的，不能放在一起。
PDML期间，不支持某些声明方式的引用完整性约束，因为表中的每一片（部分）会在单独的会话中作为单独的事务进行修改。例如，PDML操作不支持自引用完整性。如果真的支持自引用完整性，可能会出现死锁和其他锁定问题。
在提交或回滚之前，不能访问用PDML修改的表。
PDML不支持高级复制（因为复制特性的实现要基于触发器）。
不支持延迟约束（也就是说，采用延迟模式的约束）。
如果表是分区的，PDML只可能在有位图索引或LOB列的表上执行，而且并行度取决于分区数。在这种情况下，无法在分区内并行执行一个操作，因为每个分区只有一个并行执行服务器来处理。
执行PDML时不支持分布式事务。
PDML不支持聚簇表。
并行DDL
从维护的观点看，以及从管理的角度来说，并行DDL才是Oracle中并行执行最突出的优点。如果认为并行查询主要是为最终用户设计的，那么并行
DDL则是为DBA/开发人员设计的。如果没有并行执行，DBA将很难真正充分利用硬件的全部能力。但如果利用并行执行，则完全可以做到。以下SQL
DDL命令允许“并行化”：
CREATE INDEX：多个并行执行服务器可以扫描表、对数据排序，并把有序的段写出到索引结构。
CREATE TABLE AS SELECT：执行SELECT的查询可以使用并行查询来执行，表加载本身可以并行完成。
ALTER INDEX REBUILD：索引结构可以并行重建。
ALTER TABLE MOVE：表可以并行移动。
ALTER TABLE SPLIT|COALESCE PARTITION：单个表分区可以并行地分解或合并。
ALTER INDEX SPLIT PARTITION：索引分区可以并行地分解。
前4个命令还适用于单个的表/索引分区，也就是说，可以并行地MOVE一个表的单个分区。
并行DDL和使用外部表的数据加载
利用并行DDL，再加上外部表，就能通过一个简单的CREATE TABLE AS SELECT or INSERT /*+ APPEND
*/来实现并行直接路径加载。不用再编写脚本，不必再分解文件，也不用协调要运行的N个脚本。简单地说，通过结合并行DDL和外部表，不仅提供了纯粹的易
用性，而且全无性能损失。
并行DDL和区段截断
并行DDL依赖于直接路径操作。也就是说，数据不传递到缓冲区缓存以便以后写出；而是由一个操作（如CREATE TABLE AS
SELECT）来创建新的区段，并直接写入这些区段，数据直接从查询写到磁盘（放在这些新分配的区段中）。每个并行执行服务器执行自己的部分CREATE
TABLE AS SELECT工作，并且都会写至自己的区段。INSERT /*+ APPEND
*/（直接路径插入）会在一个段的HWM“之上“写，每个并行执行服务器再写至其自己的一组区段，而不会与其他并行执行服务器共享。因此，如果执行一个并
行CREATE TABLE AS
SELECT，并使用4个并行执行服务器来创建表，就至少有4个分区，可能还会更多。每个并行执行服务器会分配其自己的区段，向其写入，等填满时，再分配
另一个新的区段，并行执行服务器不会使用由其他并行执行服务器非品牌的区段。
在数据仓库环境中，执行一个大规模的加载之后，这可能导致“过渡浪费“。假设你想加载1,010MB的数据（大约1GB），而且正在使用一个有
100MB区段的表空间，你决定使用10个并行执行服务器来加载这个数据。每个并行执行服务器先分配其自己的100MB区段（总共会有10个100MB的
区段），并在其中填入数据。由于每个并行执行服务器都要加载101MB的数据，所以它会填满第一个区段，然后再继续分配另一个100MB的区段，但实际上
只会使用这个区段中1MB的空间。现在就有了20区段，其中10个是满的，另外10个则不同，这10个区段中都各有1MB的数据，因此，总共会有
990MB的空间是”已分配但未使用的“。下一次加载是可以使用这个空间，但是对现在来说，你就有了990MB的死空间。此时区段截断（extend
trimming）就能派上用场了。Oracle会试图取每个并行执行服务器的最后一个区段，并将其”截断为“可能的最小大小。
区段截断和字典管理表空间
如果使用传统的字典管理表空间，Oracle可以把只包含1MB数据的各个100MB区段转变或1MB的区段。遗憾的是，（在字典管理的表空间中）
这会留下10个不连续的99MB空闲区段，因为你的分配机制采用的是100MB区段，所以这990MB空间就会用不上！下一次分配100MB时，往往无法
使用现有的这些空间，因为现在的情况是：有99MB的空闲空间，接下来是1MB的已分配空间，然后又是99MB空闲空间，依此类推。
区段截断和本地管理表空间
本地管理表空间有两种类型：UNIFORM SIZE 和AUTOALLOCATE，UNIFORM
SIZE是指表空间中的每个区段大小总是完全相同；AUTOALLOCATE则表示Oracle会使用一种内部算法来确定每个区段应该是多大。这些方法都
能很好地解决上述问题，不过，这两种方法的解决策略截然不同。
在字典管理的表空间中，如果请求一个100MB区段，倘若Oracle只找到了99MB的自由区段，请求还是会失败。与字典管理表空间不同，有AUTOALLOCATE区段的本地管理表空间可以更为灵活。为了试图使用所有空闲空间，它可以减小所请求的空间大小。
随着使用并行直接路径操作向表UNIFORM_TEST加载越来越多的数据，过一段时间后，空间利用情况会变得越来越糟糕。对此，我们可能希望使用
一个更小的统一区段大小，或者使用AUTOALLOCATE。一段时间后，AUTOALLOCATE也可能生成更多的区段，但是由于会发生区段截断，所以
空间利用情况要好得多。
重庆分公司
重庆分公司
