1、报告概述
本篇文档对OracleOGG进程与数据库session对应关系做了较为详细的测试。
首先我们要了解什么是进程？什么是session。
进程是什么？进程就是一个执行中程序的实例，即一个正在执行的程序。我更喜欢将进程理解为分配系统资源的一个单位。那什么是session呢？将session和connection放在一起讲就更好理解了。session顾名思义，会话。意思是用户和服务器建立连接时的逻辑会话。而connection是用户与服务器的物理通信链路。简单来说connection为连接两地的桥梁，而session是通过桥梁给两地运送物资的卡车。
那做这个测试的目的是解决在OGG复制进程出现异常的时候，不知如何定位问题的情况。
我们知道定位问题的最终目标是要找到造成该问题的SQL或者event事务。那我们又知道通过该session信息，可以得到ash视图。而ash视图可以查询一段时间内某进程session都在执行什么SQL。
由此我们知道，如果OGG进程出现异常，如果弄清楚OracleOGG进程与数据库session对应关系，即可以快速通过ash视图定位到故障问题。
该文档不仅仅讲解了OracleOGG进程与数据库session之间的对应关系，还对OGG复制进程参数parallelism x做了一个补充学习。了解了这个参数的含义，作用，使用方法和一些可能造成的副作用。
2、环境准备
源库：oracle 11g rac
目标库：oracle 19c rac
ogg版本：ogg 19.1.0.0.4
3、问题测试
3.1.OGG进程与操作系统进程，与数据库session的管理关系
首先在OGG执行info 复制进程名称查询该复制进程的Process ID，
GGSCI (oel7n01) 107> info REPDEMO
REPLICAT REPDEMO Last Started 2022-08-02 10:20 Status RUNNING
INTEGRATED
Checkpoint Lag 00:00:00 (updated 00:00:03 ago)
Process ID 58335
Log Read Checkpoint File /ogg/dirdat/lt000000033
2022-08-02 09:53:27.208488 RBA 1566
得到了该复制进程的Process ID后，在Oracle数据库内根据v$ session视图查询该复制进程具体信息，即得到OracleOGG进程与数据库session之间的对应关系。（v$session中的process字段代表操作系统客户端进程 ID。）
SQL> select SID,SERIAL#,USERNAME,STATUS,PROCESS,PROGRAM,MODULE from v$session where process='58335';
SID SERIAL# USERNAME STATUS PROCESS PROGRAM MODULE
------ -------- ---------- -------- -------------- ------------------------------ ----------
315 24494 OGG INACTIVE 58335 replicat@oel7n01 (TNS V1-V3) GoldenGate
看完这个方法，那如果在操作系统ps -ef|grep 复制进程名查询呢，看看会得到什么结果？
[oracle@oel7n01 ~]$ ps -ef|grep REPDEMO
oracle 58335 13402 0 10:20 ? 00:00:01 /ogg/replicat PARAMFILE /ogg/dirprm/repdemo.prm REPORTFILE /ogg/dirrpt/REPDEMO.rpt PROCESSID REPDEMO
oracle 90003 85042 0 10:46 pts/3 00:00:00 grep --color=auto REPDEMO
我们可以知道ps -ef|grep复制进程名查询到的的进程对应的是OGG复制进程
那，该进程可不可以在V$PROCESS中查询到呢？
答案是否定的。因为V$PROCESS是显示有关当前活动进程的信息，但由上述表述可知该进程状态STATUS为INACTIVE，所以并不能在V$PROCESS中查询到。
那除了这个方法外，还有没有办法能够得到OGG进程与数据库session对应关系呢？
答案是有的，可以通过v$session中username字段值等于OGG来查询。
SQL> select SID,SERIAL#,USERNAME,STATUS,PROCESS,PROGRAM,MODULE from v$session where USERNAME= 'OGG';
SID SERIAL# USERNAME STATUS PROCESS PROGRAM MODULE
---------- ---------- ---------- -------- ---------- -------------------- --------------------
69 6024 OGG ACTIVE 58350 oracle@oel7n01 (AS02 GoldenGate
)
75 50126 OGG ACTIVE 58348 oracle@oel7n01 (AS01 GoldenGate
)
106 4139 OGG ACTIVE 58352 oracle@oel7n01 (AS03 GoldenGate
)
109 64175 OGG ACTIVE 58360 oracle@oel7n01 (AS07 GoldenGate
)
356 39224 OGG INACTIVE 58335 replicat@oel7n01 (TN GoldenGate
S V1-V3)
361 19510 OGG ACTIVE 58354 oracle@oel7n01 (AS04 GoldenGate
)
392 32134 OGG ACTIVE 58358 oracle@oel7n01 (AS06 GoldenGate
)
393 39260 OGG ACTIVE 58356 oracle@oel7n01 (AS05 GoldenGate
)
8 rows selected.
3.2.OGG性能分析,当前session和历史session mode的性能分析
我们已经在3.1学习了解了OracleOGG进程与数据库session之间的对应关系，那现在我们来模拟一下目标库OGG复制进程Lag at Chkpt过高的情况，看能不能成功定位到故障问题。
首先制造同步数据量150w条，模拟OGG复制进程Lag at Chkpt过高现象：
源库创建表t_parallel：
SQL> create table t_parallel(a int,b int);
然后插入数据，模拟处理数据量过大的情况：
SQL> insert into t_parallel select level,level from dual connect by level<=5e5;
SQL> commit;
SQL> insert into t_parallel select level+500000,level+500000 from dual connect by level<5e5;
SQL> commit;
SQL> insert into t_parallel select level+1000000,level+1000000 from dual connect by level<=5e5;
SQL> commit;
我们去目标库OGG查询下进程信息，发现复制进程Lag at Chkpt确实异于正常值
GGSCI (oel7n01) 89> !
info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT STOPPED EXTPDB 312:21:17 08:04:51
EXTRACT STOPPED PUMPPDB 00:00:00 08:04:43
REPLICAT RUNNING REPDEMO 00:00:38 00:00:06
根据3.1我们知道该如何通过OGG复制进程定位数据库session。
首先查询复制进程信息，找到复制进程的Process ID
GGSCI (oel7n01) 97> info REPDEMO
REPLICAT REPDEMO Last Started 2022-07-26 16:35 Status RUNNING
INTEGRATED
Checkpoint Lag 00:01:12 (updated 00:00:32 ago)
Process ID 104409
Log Read Checkpoint File /ogg/dirdat/lt000000029
2022-07-26 16:37:33.498043 RBA 476690848
然后在数据库内定位session
SQL> select SID,SERIAL#,USERNAME,STATUS,PROCESS,PROGRAM,MODULE from v$session where process='104409';
SID SERIAL# USERNAME STATUS PROCESS PROGRAM MODULE