OGG-Oracle 集成模式抽取进程，REGISTER DATABASE都做了什么？
一、学习目标
有同事问OGG技术问题，OGG软件，在oracle数据库中，集成模式抽取进程REGISTER DATABASE，都做了什么操作？ 有什么风险？
并且提到了一个抽取进程注册，在瞬时间并发占用了大量的进程process,并且当时某DB process剩余不足，最终导致DB的process占满，影响了DB系统！
那么带来一些疑问：
1） 集成模式抽取进程REGISTER DATABASE，做了哪些操作？
2） REGISTER DATABASE 会在数据库中产生大量的并发会话吗？ 具体会产生大概多少会话？
3） REGISTER DATABASE 为什么会在数据库中占用大量的并发？
4）根据上述疑问进行测试，根据测试结果进行反思，REGISTER DATABASE 时，是否需要注意哪些内容？
*补充，同事林大佬遇到一个Bug-会导致集成抽取时产生大量并发！ 可能会影响生产环境业务连接！！！ 把连接数占满了！！！
https://www.modb.pro/db/78475
Bug 19587324 - Logminer starts up too many parallel query servers to gather statistics (Doc ID 19587324.8)
二、测试
2.1 REGISTER DATABASE，做了什么？
思路是对OGG用户的会话，开启10046，并进行汇总；
dblogin xx 的时候对于DB就是一个session的连接!
> register extract ext_tb database CONTAINER(pdbodb) 2021-04-13 15:42:35 INFO OGG-02003 Extract EXT_TB successfully registered with database at SCN 5881819. [oracle@19test2:/home/oracle]$ cat 888.trc|grep -A3 'SQL ID'|grep SELECT |wc -l 219 [oracle@19test2:/home/oracle]$ cat 888.trc|grep -A3 'SQL ID'|grep INSERT |wc -l 99 [oracle@19test2:/home/oracle]$ cat 888.trc|grep -A3 'SQL ID'|grep UPDATE |wc -l 16 [oracle@19test2:/home/oracle]$ cat 888.trc|grep -A3 'SQL ID'|grep DELETE |wc -l 0 [oracle@19test2:/home/oracle]$ cat 888.trc|grep -A3 'SQL ID'|grep CREATE |wc -l 30 [oracle@19test2:/home/oracle]$ cat 888.trc|grep -A3 'SQL ID'|grep ALTER |wc -l 5 [oracle@19test2:/home/oracle]$ cat 888.trc|grep -A3 'SQL ID'|grep DROP |wc -l 0 可以说往SYS用户下的很多基表insert，update了数据，创建的基本上是C##OGG用户下的表、索引、视图，在SYS用户创建了个视图，
ALTER的操作就是对C##OGG用户下的基表新建主键索引！
2.2 REGISTER DATABASE 时创建了多少个session?
注册会产生多少个Session SYS@odb>select * from GV$RESOURCE_LIMIT where RESOURCE_NAME in('processes','sessions'); RESOURCE_N CURRENT MAX INITIAL_ALLOCATION LIMIT_VALUE CON_ID ---------- ------------------- --------------- -------------------- -------------------- ---------- processes 79 93 300 300 1 sessions 118 130 472 472 1 > dblogin userid C##OGG@T2CDB ,password SGcc_osgsac01 > register extract ext_tb database CONTAINER(pdbodb) RESOURCE_N CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALU CON_ID ---------- ------------------- --------------- -------------------- ---------- ---------- processes 63 93 300 300 1 sessions 86 130 472 472 1
GV$RESOURCE_LIMIT自实例启动以来的可以观测session,process的信息，本次测试前重启库！ 因此如果有较大的并发是可以较为明显观察到的！
那么可以说本次测试并没有看到明显变化！ 也就是说这种问题不是百分比能模拟重现！
2.3 REGISTER DATABASE 为什么会在数据库中占用大量的并发？
同事说的案例肯定说明存在大量的并发情况？ 那么是什么原因？
继续观察上述的10046.trc日志，观测parallel相关的等待事件关联的SQL信息
SQL ID: brwf9ntmf46t0 Plan Hash: 3344361896 INSERT /*+ APPEND DISABLE_PARALLEL_DML */ INTO SYS.LOGMNRG_CDEF$ (···) SELECT ··· FROM SYS.CDEF$ AS OF SCN 5881819 CD ------- ------ -------- ---------- ---------- ---------- ---------- ---------- db file parallel read 19 0.00 0.00 direct path write 2 0.00 0.00 direct path sync 1 0.00 0.00 INSERT /*+ APPEND DISABLE_PARALLEL_DML */ INTO SYS.LOGMNRG_TABPART$ (··· FROM SYS.TYPE$ AS OF SCN 5881819 TY Rows (1st) Rows (avg) Rows (max) Row Source Operation ---------- ---------- ---------- --------------------------------------------------- 0 0 0 LOAD AS SELECT LOGMNRG_TYPE$ (cr=4594 pr=4591 pw=60 time=212985 us starts=1) 4560 4560 4560 TABLE ACCESS BY INDEX ROWID BATCHED TYPE$ (cr=4594 pr=4590 pw=0 time=824302 us starts=1
cost=4591 size=387600 card=4560) 4560 4560 4560 INDEX FULL SCAN I_TYPE2 (cr=32 pr=30 pw=0 time=1115 us starts=1 cost=30 size=0 card=4560)
(object id 742) Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ db file sequential read 33 0.00 0.00 db file parallel read 35 0.04 0.17 direct path write 2 0.00 0.00 db file scattered read 1 0.00 0.00 direct path sync 1 0.00 0.00 ******************************************************************************** 也就是说，OGG在注册的时候，需要内部进行执行大量的insert附加的select基表的操作！
并且使用了禁止dml并行，单个进程append的方式进行写入！ 在索引回表查询数据的时候是并行查询，因此如果并行度过高的情况下！
并且session不够用的情况下，会造成OGG用户注册DB后，占用大量的session 甚至占满，导致DB业务受到影响！
说到底，原因就是 register database 的时候，Oracle后台执行了很多的SQL,SQL涉及使用了并行！
并行的进程达到一定的程度，并且正好占用了DB FREE PROCESS,就产生比较大的影响了！
挑选sql并行event 2个基表,10046中没有发现alter session,table parallel hint 这个涉及Oracle内部执行，无法探索！ 常规执行查询基表是不产生并行的！
select OWNER,TABLE_NAME,DEGREE from dba_tables where table_name in('LOGMNRG_COLTYPE$' ,'COLTYPE$');
OWNER TABLE_NAME DEGREE
-------------------- ------------------------------ ----------------------------------------
SYS COLTYPE$ 1
SYS LOGMNRG_COLTYPE$ 1
select OWNER,index_name,TABLE_NAME,DEGREE from dba_indexes where table_name in('LOGMNRG_COLTYPE$' ,'COLTYPE$');
OWNER INDEX_NAME TABLE_NAME DEGREE
-------------------- ------------------------------ ------------------------------ ----------------------------------------
SYS I_COLTYPE1 COLTYPE$ 1
SYS I_COLTYPE2 COLTYPE$ 1
2.4 反思
既然是oracle parallel的问题，那么我们再次重新梳理一下oracle并行的相关参数！
PARALLEL_DEGREE_LIMIT
PARALLEL_DEGREE_LIMIT 限制了优化器使用的并行度，以确保并行服务器进程不会淹没系统。
Syntax PARALLEL_DEGREE_LIMIT = { CPU | IO | integer }
Default value CPU
CPU 最大并行度受系统中CPU数量的限制。用于计算限制的公式是PARALLEL_THREADS_PER_CPU* CPU_COUNT*可用的实例数（默认情况下，群集上所有打开的实例，但可以使用PARALLEL_INSTANCE_GROUP或服务规范加以限制）。这是默认值。
IO 根据IO容量进行限制，并且需要运行DBMS_RESOURCE_MANAGER.CALIBRATE_IO，才能使用IO设置;
integer
A numeric value for this parameter specifies the maximum degree of parallelism the optimizer can choose for a SQL statement when automatic degree of parallelism is active. Automatic degree of parallelism is only enabled if PARALLEL_DEGREE_POLICY is set to ADAPTIVE, AUTO, or LIMITED.
PARALLEL_DEGREE_POLICY
PARALLEL_DEGREE_POLICY specifies whether automatic degree of parallelism, statement queuing, and in-memory parallel execution will be enabled.
Syntax PARALLEL_DEGREE_POLICY = { MANUAL | LIMITED | AUTO | ADAPTIVE }
Default value MANUAL
MANUAL 禁用自动并行，需要手工指定使用并行才可以
LIMITED Enables automatic degree of parallelism for some statements but statement queuing and in-memory Parallel Execution are disabled
启用并行，并行不允许排队！以及内存中不允许并行
当设置为该属性时，自动并行特性将关闭，部分sql语句仍然可用使用，如表和索引的degree大于1的情况。
AUTO
启用自动并行度，语句排队和内存中并行执行。
ADAPTIVE
This value enables automatic degree of parallelism, statement queuing and in-memory parallel execution, similar to the AUTO value. In addition, performance feedback is enabled. Performance feedback helps to improve the degree of parallelism automatically chosen for repeated SQL statements. After the initial execution of a statement, the degree of parallelism chosen by the optimizer is compared to the degree of parallelism computed based on the actual execution performance. If they vary significantly, then the statement is marked for re-parse and the initial execution performance statistics (for example, CPU-time) are provided as feedback for subsequent executions. The optimizer uses the initial execution performance statistics to better determine a degree of parallelism for subsequent executions.
PARALLEL_EXECUTION_MESSAGE_SIZE
指定用于并行执行的消息的大小（以前称为并行查询，PDML，并行恢复，复制）。
Range of values
Minimum: 2148
Maximum: 65536, but some operating systems may have a smaller value
On most platforms, the default value is as follows:
16384 bytes if COMPATIBLE is set to 11.2.0 or higher
2148 bytes if COMPATIBLE is less than 11.2.0
The default value is adequate for most applications. Larger values require a larger shared pool. Larger values result in better performance at the cost of higher memory use. For this reason, replication gets no benefit from increasing the size.
https://www.modb.pro/db/42407，这个参数还有什么用呢？ DG追归档日志应用慢，可以加大这部分的区域！ 链接中提示要加大shared pool的问题可以通过如下参数处理！
_PX_use_large_pool
FALSE
Use Large Pool as source of PX buffers
如果没有设置大型池，则在共享池内分配空间！！！ 建议设置为True
这句话杀伤性极大！ 并行进程占用较多的内存 >，导致占用shared pool空间，最终导致shared pool其它组件回收内存，导致内存栓锁争用严重！
内存使用
PARALLEL_FORCE_LOCAL 建议设置为 true
默认FORCE，就是可以使用其他节点的CPU，并不是说在其他节点执行SQL，执行SQL还是本节点（即PX在本节点），但是可以使用其他节点的资源做coordinator process即QC（就是管理下面这些并行度的一个进程，一个个的并行程序叫parallel execution servers即PX），此参数最好设置为TRUE
PARALLEL_MAX_SERVERS
PARALLEL_MAX_SERVERS specifies the maximum number of parallel execution processes and parallel recovery processes for an instance. As demand increases, Oracle Database increases the number of processes from the number created at instance startup up to this value.
Default value PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5
Range of values 0 to 32767
PARALLEL_MIN_SERVERS is the number of parallel execution processes Oracle creates when the instance is started. These processes will be kept alive to service parallel statements.
Range of values Default value to the value of PARALLEL_MAX_SERVERS
PARALLEL_MIN_SERVERS指定实例的最小并行执行进程数。 该值是在实例启动时由Oracle创建的并行执行进程的数量
PARALLEL_MIN_DEGREE
控制通过自动并行度计算的最小并行度。 默认1
PARALLEL_MIN_PERCENT
Range of values 0 to 100
使您可以指定并行执行所需的并行执行过程请求数量的最小百分比。
并行语句队列未启用时(PARALLEL_DEGREE_POLICY设置为manual or limited)，此参数控制并行操作的行为。
比如80个CPU、现在已经使用了60个，剩下20个（PARALLEL_SERVERS_TARGET），现在来了一个60个并行度的查询，怎么办？
如果PARALLEL_MIN_PERCENT=10，就是10%可以用，就是最少使用60*10%=6个并行度，6<20,可以使用
如果PARALLEL_MIN_PERCENT=50，就是使用60*50%=30，30>20，如果PARALLEL_DEGREE_POLICY=MANUAL，则不够，直接报错，如果PARALLEL_DEGREE_POLICY=AUTO，则进入队列。
parallel_min_time_threshold
sql语句执行的最小时间（在使用了该特性时），换句话说，也就是只有当parallel_degree_policy参数设置为auto或limited时，该参数默认值为auto，即是默认为10s。
当自动并行参数为非Manual的情况下,部分的SQL语句可能执行10s后，可能自动使用并行！
By default, this parameter is set to 10 seconds. Automatic degree of parallelism is only enabled if PARALLEL_DEGREE_POLICY is set to ADAPTIVE, AUTO, or LIMITED.
If all tables referenced by a SQL statement use In-Memory Column Store (IM column store), then PARALLEL_MIN_TIME_THRESHOLD defaults to 1.
PARALLEL_SERVERS_TARGET specifies the number of parallel server processes allowed to run parallel statements before statement queuing will be used. When the parameter PARALLEL_DEGREE_POLICY is set to AUTO, Oracle will queue SQL statements that require parallel execution, if the necessary parallel server processes are not available.
PARALLEL_SERVERS_TARGE指定在使用语句排队之前允许运行并行语句的并行服务器进程的数量。当参数PARALLEL_DEGREE_POLICY设置为AUTO时，如果必需的并行服务器进程不可用，Oracle将对需要并行执行的SQL语句进行排队
The degree of parallelism used for a SQL statement can be specified at three different levels:
■Statement level - Using hints such as PARALLEL or the PARALLEL clause
■Object level - Found in the definition of the table, index, or other object. See: PARALLEL clause
■Instance level - Using default values for the instance. See: parallel_threads_per_cpu x cpu_count
The Cost-Based Optimizer determines whether to parallelize a statement and the degree of paralleism applied for a SQL statement by checking each item in this list in the order shown. Oracle first checks for a degree of parallelism specification at the statement level. If none is found, the table or index definitions are checked. If the table or index definition does not explicitly specify values for DEGREE and INSTANCES, then the default values established for the instance are used.
对于default 的情况，参考如下说明！
ALTER TABLE sales PARALLEL;
Default parallelism uses a formula to determine the DOP based on the system configuration, as in the following:
For a single instance, DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT
For an Oracle RAC configuration, DOP = PARALLEL_THREADS_PER_CPU x sum(CPU_COUNT)
By default, sum(CPU_COUNT) is the total number of CPUs in the cluster. However, if you have used Oracle RAC services to limit the number of nodes across which a parallel operation can execute, then sum(CPU_COUNT) is the total number of CPUs across the nodes belonging to that service. For example, on a 4-node Oracle RAC cluster, with each node having 8 CPU cores and no Oracle RAC services, the default DOP would be 2 x (8+8+8+8) = 64.
You can also request the default DOP by using statement level or object level parallel hints.
The default DOP specified in the PARALLEL clause of a table or an index takes effect only when PARALLEL_DEGREE_POLICY is set to MANUAL.
The default DOP algorithm is designed to use maximum resources and assumes that the operation finishes faster if it can use more resources. Default DOP targets the single-user workload and it is not recommended in a multiuser environment.
The actual runtime DOP of a SQL statement can be limited by Oracle Database Resource Manager.
默认情况下，sum(CPU_COUNT)是群集中的CPU总数。但是，如果您已使用Oracle RAC服务来限制可在其中执行并行操作的节点数，则sum(CPU_COUNT)该数是属于该服务的节点之间的CPU总数。例如，在一个4节点的Oracle RAC集群上，每个节点具有8个CPU内核，并且没有Oracle RAC服务，默认DOP为2 x（8 + 8 + 8 + 8）= 64。
上面是学习并行的相关参数的解释说明，来点干货！
1.并行可能引发的内存争用问题
未设置并行参数，导致占用shared pool,引发内存严重的栓锁争用，处理方法：
_PX_use_large_pool = true ，配置使用大池内存组件，并行申请内存从large pool申请
2.SQL语句或者对象执行，涉及表、索引等对象使用太多的并行！ 并行数量过高！
建议
PARALLEL_DEGREE_POLICY 设置为手工管理模式，NOT AUTO
PARALLEL_MAX_SERVERS 2倍CPU ，临时管制 -- 不建议随意调整，可以考虑高危操作低峰期执行，但是业务高峰期必须执行可以考虑设置限制process数量
Default value PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5
Range of values 0 to 32767
PARALLEL_FORCE_LOCAL true 禁止节点并行！
对于TABLE|INDEX的对象，将default设置为1 or 指定的并行度，不要使用oracle 默认的并行度计算方法！可能并行度过高！
3.操作前检查一下可用的process,session的数量！
进程数量限制如果仅剩余少量session还是调参数！ 有个千儿八百的 OGG 注册没啥问题！ 这个要看Oracle自动对其使用的并行度！
processes ||sessions， v$process,v$session
--参考链接
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/vldbg/degree-parallel.html#GUID-7D86C1A1-58B2-4D66-B7EF-A5B82BADF40F
https://blog.csdn.net/iteye_4537/article/details/82132628
其它！舍弃的参数
有的时候确实佩服oracle,推出的功能你可能还没用上，以及被它自行舍弃了，这说明在功能上有推出其它很多很多的可能性，最终有市场和用户选择合适的进行保留。 PARALLEL_ADAPTIVE_MULTI_USER Note: The PARALLEL_ADAPTIVE_MULTI_USER initialization parameter is deprecated in Oracle Database 12c Release 2 (12.2.0.1)
and may be removed in a future release. Oracle recommends that you use the parallel statement queuing feature instead. 该算法根据查询启动时的系统负载自动降低请求的并行度。有效的并行度是基于默认的并行度，即表或提示中的度，再除以缩减因子。
关于并行的其它方面，网上有很多资料可以检索，书本基于Oracle的SQL优化，
墨天伦，云和恩墨-专家-杨廷琨，可以看看杨长老分享的
《并行不悖——Oracle数据库并行的是是非非》
