extract进程 oracle,Oracle GoldenGate 系列：Extract 进程遇长事务执行 Forcestop 引发的惨案...

最新推荐文章于 2021-04-11 06:32:10 发布

不哭的阿木木

最新推荐文章于 2021-04-11 06:32:10 发布

阅读量212

点赞数

文章标签： extract进程 oracle

2、XX2库分析

停止XX2库 Extract进程时正在处理的长事务为

select t.addr,t.XIDUSN,t.XIDSLOT,t.XIDSQN,t.START_DATE from gv$transaction t;

ADDR XIDUSN XIDSLOT XIDSQN START_DAT

---------------- ---------- ---------- ---------- ---------

0700000405B10488 173 30 6643 10-APR-13

截止目前该事务在数据库中仍在进行：

SQL> selectt.SID,t.SERIAL#,t.SCHEMA#,t.SCHEMANAME,t.OSUSER,t.MACHINE,t.PORT,t.TERMINAL,t.PROGRAMfrom gv$session t where taddr='0700000405B10488';

SID SERIAL# SCHEMA# SCHEMANAMEOSUSER MACHINE PORT TERMINAL PROGRAM

---------- -------------------- ---------- ---------- -------------------- ---------------------------------------- ------------------------------

2520 19683 98 SJCK Oracle bjschxdbcx03 0 UNKNOWN oracle@bjschxdbcx03(J000)

通过该事务正在进行的 sql以及上一个 sql语句推测，该事务可能由于 Oracle 自动刷新物化视图的内部job发起，不会带来业务数据变化。

SQL> selectt.PREV_SQL_ID,t.SQL_ID from gv$session t where taddr='0700000405B10488';

PREV_SQL_ID SQL_ID

--------------------------

76cckj4yysvua6x5246x8jk7wj

SQL> select sql_textfrom gv$sqltext t where t.SQL_ID = '76cckj4yysvua' order by t.PIECE;

SQL_TEXT

----------------------------------------------------------------

select time_mp, scn,num_mappings, tim_scn_map from smon_scn_tim

e where scn = (select max(scn) from smon_scn_time wherescn

<= :1)

SQL_TEXT

----------------------------------------------------------------

<= :1)

select sql_text fromgv$sqltext t where t.SQL_ID = '6x5246x8jk7wj' order by t.PIECE;

/* MV_REFRESH (MRG) */MERGE INTO "SJCK"."SE_GES_NSDSEWYYS2" "SN

A$" USING ( WITH"TMPDLT$_SE_GES_NSDSEWYYS1" AS ( SELECT /*+ RE

SULT_CACHE(LIFETIME=SESSION)*/ "MAS$"."RID$" "RID$" ,"MAS$"."N

SDEHJ","MAS$"."SDNF", "MAS$"."ZRRDZDAH", DECODE("MAS$".

"OLD_NEW",′N′,′I′,′D′)"DML", "MAS$"."OLD_NEW$$"

"OLD_NEW","MAS$"."TIME" "TIME","MAS$"."DMLTYPE" "DMLTY

PE"FROM(SELECT"MAS$".∗,MIN("MAS$"."SEQ") OVER(PARTIT

ION BY"MAS$"."RID$") "MINSEQ",MAX("MAS$"."SEQ") OVER(PA

RTITION BY"MAS$"."RID$") "MAXSEQ$$" FROM (SELECT CHARTOROWID

("MAS$"."M_ROW$$")RID$ , "MAS$"."NSDEHJ", "MAS$"."SDNF","MAS

$"."ZRRDZDAH" , DECODE("MAS$".OLD_NEW,′N′,′I′,′D′)DML,

"MAS$"."DMLTYPE""DMLTYPE", "MAS$"."SEQUENCE""SEQ","MA

S$"."OLD_NEW""OLDNEW", "MAS$"."SNAPTIME""TIME" FROM

"SJCK"."MLOG$_SE_GES_NSDSEWYYS1""MAS$" WHERE"MAS$".SNAPTIME$

恢复该数据库上的 Extract 进程需要用到归档日志 thread 3, seq 5862-6105,从 5862 开始的相当一部分归档日志已被删除，因此会报找不到归档。

Recovery Checkpoint (position of oldest unprocessed transaction in thedata source):

Thread #: 3

Sequence #: 5862

RBA: 18504720

Timestamp: 2013-04-10 01:00:18.000000

SCN: 3098.1717076309 (13307525759317)

Redo File: Not Available

Current Checkpoint (position of last recordread in the data source):

Thread #: 3

Sequence #: 6105

RBA: 39127568

Timestamp: 2013-04-14 11:58:38.000000

SCN: 3099.2202080974 (13312305731278)

Redo File: +DATA/bjschxcx/onlinelog/redo12b

问题原因总结：

目前生产环境所有数据库的 Extract 进程已经按照 Oracle 的建议统一关闭 Bounded Recovery 功能，关闭该功能的后果是，每当 Extract 进程强制停止时，如果进程正在处理既未提交也未回滚的长时间运行事务(无论事务长短)，则重启 Extract 进程后，都必须进行 Normal Recovery，必须从这些既未提交也未回滚的事务中最早开始的事务在 Redo 或 Archived log 中的起点位置开始进行 Recovery。

如果未关闭Bounded Recovery，则 Extract 进程会对任何运行时间超过一个 BR 检查点间隔(默认4小时)的事务每隔一个 BR 间隔执行一个检查点，将事务相关的状态和数据写入 BR 检查点文件，这样当 Extract 进程强行终止重启后就会从上一个有效的 BR 检查点或上个 BR 间隔内最早的既未提交也未回滚的事务的起点在日志文件中开始进行 Recovery，通过该功能可以保证 Extract 进程恢复的时间永远不会超过 2 倍的 BR 间隔。

因此，导致本次问题的原因有：

1、GoldenGateExtract 的 Bounded Recovery 功能关闭，该功能官方的 Reference 推荐在未经Oracle Support 推荐情况下，不应对该功能做任何改动。

2、版本升级时在停止 Extract 进程时存在长事务，执行了 forcestop 操作

3、归档日志被删除

4、数据库中存在不正常的长事务

5、数据运维不规范

三、解决方案：

1、重新初始化，能够彻底解决问题，但是存在业务停机时间不可控风险。

2、恢复归档，能够彻底解决问题，存在一定的同步延迟等待。

3、按照抽取时间点跳过该事务，可能存在丢失事务的风险，概率很低但却是存在。

四、处理过程：

对于XX2库因找不到归档挂起的 Extract 进程，通过恢复归档日志，重启 Extract 进程，等待延迟解决。