暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

[译文] Oracle:使用 GoldenGate 实现近乎零停机的迁移和故障恢复

原创 Lazhar Felahi 2022-04-24
976

Oracle GoldenGate 允许以接近零停机时间和故障恢复功能迁移 Oracle 数据库。

接近零停机时间迁移意味着应用程序切换停机时间非常短。

故障回复包括将迁移从 19c 回滚到 12c。

本博客的目的是描述如何通过 Oracle GoldenGate 将 Oracle 数据库从 12c 迁移到 19c,停机时间接近零并具有故障恢复功能。

 

第 1 步 – 检查 GOLDENGATE 同步

Oracle GoldenGate 进程必须启动并运行(源上的 EXTRACT 和 PUMP,目标上的 REPLICAT)并且源和目标数据库必须同步(源和目标之间的数据相同)。

由于 GoldenGate 是一种逻辑复制,因此必须通过 Oracle Veridata(在许可下)或手动(我的首选方法)定期进行数据比较:

  • 通过sql函数COUNT(*)比较Source和Target的行数——>必须返回相同的行数
  • 通过 sql 函数 MINUS 比较 Source 和 Target 之间的数据 -> 必须返回“No rows selected”
    • MINUS 不支持 CLOB/BLOB 列
  • 通过 dbms_lob.compare 在 Source 和 Target 之间比较 CLOB/BLOB 的数据 –> 必须返回“0”
--COMPARE NB OF ROWS
SQL>
select count(*) from TABLE_A@dblink_source
union all
select count(*) from TABLE_A;
 
COUNT(*)
----------
3754
3754
 
--COMPARE DATA BETWEEN SOURCE AND TARGET
SQL>
select * from TABLE_A@dblink_source
minus
select * from TABLE_A;
 
no rows selected
 
--COMPARE DATA BETWEEN TARGET AND SOURCE
SQL>
select * TABLE_A
minus
select * from TABLE_A@dblink_source;
 
no rows selected
 
--COMPARE DATA FOR CLOB/BLOB COLUMNS
CREATE OR REPLACE FUNCTION compare_clob(clob_src IN clob, clob_trg IN clob)
RETURN NUMBER
IS v_result number;
clob_src1 long;
clob_trg1 long;
BEGIN
clob_src1 := dbms_lob.substr( clob_src, 32000, 1 );
clob_trg1 := dbms_lob.substr( clob_trg, 32000, 1 );
 
select dbms_lob.compare(clob_src1,clob_trg1)
into v_result
from dual;
 
RETURN(v_result);
END;
/



第 2 步 – 停止源应用程序

在这一步,停机时间开始……

  • 停止源数据库上的应用程序 (12c)
  • 如果应用程序无法停止:
    • 锁定应用程序模式
    • 检查没有更多的交易 int v$transaction/gv$transaction
    • 杀死会话
  • 停止监听器
  • 保存 job_queue_processes 值(稍后我们将在 19c 上启动应用程序时需要)
  • 禁用job_queue_processes(“alter system set job_queue_processes = 0 scope = both)

为了确保没有事务在运行,在 12c 数据库上创建一个虚拟表并插入 1 行,稍后我们将检查 GoldenGate 跟踪文件,该事务是最后一个事务,这将确保我们不会丢失“真实”事务从切换前的源数据库。

SQL> create table source_schema.zz_dummy2 (SCN varchar2(100), d date, comment_txt varchar2(50));
 
Table created.
 
SQL>
 
--on target
SQL> desc source_schema.zz_dummy2
Name Null? Type
----------------------------------------- -------- ----------------------------
SCN VARCHAR2(100)
D DATE
COMMENT_TXT VARCHAR2(50)
 
SQL>
alter session set nls_date_format='dd.mm.yyyy hh24:mi:ss';
insert into source_schema.zz_dummy2 select (select to_char(current_scn) from v$database),sysdate, 'RECORD TEST' from dual;
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> select * from source_schema.zz_dummy2;
 
SCN
--------------------------------------------------------------------------------
D
-------------------
COMMENT_TXT
--------------------------------------------------------------------------------
3386436290352
13.04.2022 14:36:41
RECORD TEST
 
SQL>



检查表是否由 GoldenGate 在目标数据库上同步 (19c)。

第 3 步 – 创建还原点

在源数据库上,创建一个还原点:

SQL> CREATE RESTORE POINT rp_before_switch GUARANTEE FLASHBACK DATABASE;
 
Restore point created.



如果我们想回滚迁移,我们将通过 GoldenGate 从 19c 数据库复制 12c 数据库(自 19c 上的应用程序启动以来存在新事务)。如果使用 GoldenGate 回滚失败(出于任何原因),此还原点将允许及时还原数据库。

第 4 步 – 检查提取没有更多交易

检查 EXTRACT 进程没有要处理的记录。

GGSCI (source_server as ggadmin@db_source) 42> send extract e1 logend
 
Sending LOGEND request to EXTRACT E1 ...
YES
 
GGSCI (source_server) 8> send extract e1 showtrans
 
Sending SHOWTRANS request to EXTRACT E1...
No transactions found.
 
GGSCI (source_server) 16> send extract e1 logend
    Sending LOGEND request to EXTRACT E1 ...
    YES



命令“send extract e1 logend”转到当前跟踪文件的末尾并检查最后一个事务。

如果命令“send extract e1 logend” send YES,则表示最后一条记录已被处理。

如果命令“send extract e1 logend”发送NO,则表示总有记录要由EXTRACT进程处理。

如果 GoldenGate 不再需要管理事务,我们准备停止 EXTRACT 进程:

GGSCI (source_server) 9> stop extract e1
Sending STOP request to EXTRACT E1...
Request processed.
 
GGSCI (source_server) 9> info all
 
Program Status Group Lag at Chkpt Time Since Chkpt
 
MANAGER RUNNING
EXTRACT STOPPED E1 00:00:02 00:00:02


第 5 步 - 检查副本没有更多交易

检查 REPLICAT 进程没有要处理的记录:

GGSCI (target_server) 32> send replicat R1 logend
 
Sending LOGEND request to REPLICAT R1...
YES


命令“send replicat R1 logend”必须返回“YES”

第 6 步 – 将最后一笔交易检查到跟踪文件中

如果最后一个事务涉及插入到虚拟表中(记住第 2 步),则从 logdump 实用程序检查当前跟踪文件(EXTRACT 或 REPLICAT 使用的最后一个跟踪文件):

--got the trail file name with the command “view report E1”
Logdump 25 >ghdr on
detail data
ggstoken detailLogdump 26 >Logdump 27 >
Logdump 28 >
Logdump 28 >
Logdump 28 >open /u01/xs/ogg/xs000000000
Current LogTrail is /u01/xs/ogg/xs000000000
Logdump 29 >pos last
Reading forward from RBA 348547
Logdump 30 >pos rev
Reading in reverse from RBA 348547
Logdump 31 >n
___________________________________________________________________
Hdr-Ind    :     E  (x45)     Partition  :     .  (x0c)
UndoFlag   :     .  (x00)     BeforeAfter:     A  (x41)
RecLength  :    65  (x0041)   IO Time    : 2022/04/13 14:36:44.000.000
IOType     :     5  (x05)     OrigNode   :   255  (xff)
TransInd   :     .  (x03)     FormatType :     R  (x52)
SyskeyLen  :     0  (x00)     Incomplete :     .  (x00)
AuditRBA   :      61367       AuditPos   : 522820
Continued  :     N  (x00)     RecCount   :     1  (x01)
 
2022/04/13 14:36:44.000.000 Insert Len 65 RBA 348360
Name: SOURCE_SCHEMA.ZZ_DUMMY2 (TDR Index: 3)
After Image: Partition x0c G s
0000 1100 0000 0d00 3333 3836 3433 3632 3930 3335 | ........338643629035
3201 0015 0000 0032 3032 322d 3034 2d31 333a 3134 | 2......2022-04-13:14
3a33 363a 3431 0200 0f00 0000 0b00 5245 434f 5244 | :36:41........RECORD
2054 4553 54 | TEST
Column 0 (x0000), Len 17 (x0011)
0000 0d00 3333 3836 3433 3632 3930 3335 32 | ....3386436290352
Column 1 (x0001), Len 21 (x0015)
0000 3230 3232 2d30 342d 3133 3a31 343a 3336 3a34 | ..2022-04-13:14:36:4
31 | 1
Column 2 (x0002), Len 15 (x000f)
0000 0b00 5245 434f 5244 2054 4553 54 | ....RECORD TEST
 
GGS tokens:
TokenID x52 'R' ORAROWID Info x00 Length 20
4141 4347 5159 4141 4541 4141 4154 4d41 4141 0001 | AACGQYAAEAAAATMAAA..
TokenID x4c 'L' LOGCSN Info x00 Length 13
3333 3836 3433 3632 3930 3336 36 | 3386436290366
TokenID x36 '6' TRANID Info x00 Length 15
302e 3130 2e31 392e 3437 3631 3931 39 | 0.10.19.4761919
TokenID x69 'i' ORATHREADID Info x01 Length 2
0001 | ..
 
Logdump 32 >



最后一个事务必须是 INSERT INTO SOURCE_SCHEMA.ZZ_DUMMY2。如果是这种情况,请停止 REPLICAT PROCESS:

GGSCI (target_server) 2> stop replicat R1
 
Sending STOP request to REPLICAT R1...
Request processed.
 
GGSCI (target_server) 3> info all
 
Program Status Group Lag at Chkpt Time Since Chkpt
 
MANAGER RUNNING
REPLICAT STOPPED R1 00:00:00 00:00:11



步骤 7 – 禁用自动启动/自动重启进入管理器参数文件

将 AUTOSTART/AUTORESTART 参数删除到源和目标上的 MANAGER 参数文件中:

--FOR EXTRACT
AUTORESTART EXTRACT E1, RETRIES 3, WAITMINUTES 1, RESETMINUTES 60
AUTOSTART EXTRACT E1
 
--FOR REPLICAT
AUTORESTART EXTRACT R1, RETRIES 3, WAITMINUTES 1, RESETMINUTES 60
AUTOSTART EXTRACT R1



第 8 步 - 创建反向提取(在故障时需要)

如果我们想在切换后回滚迁移,则需要此步骤。回滚是指在不丢失数据的情况下返回到 12c 数据库。

因为新事务在切换后在目标数据库中创建了新行,所以我们必须从 19c 数据库上的第一个事务重新同步 12c 数据库。如果我们回滚迁移并且应用程序返回到 12c,则不会丢失任何事务。

将 19c 数据库配置为准备好通过 REVERSE EXTRACT 捕获数据:

  • 在要复制的架构上添加 schematransdata

注册反向提取:

GGSCI (target_server) 10> alter credentialstore add user gg_admin@db_target alias target
Password:
 
Credential store altered.
 
GGSCI (target_server) 11> dblogin useridalias target
Successfully logged into database db_target.
 
GGSCI (target_server as gg_admin@db_target) 2>
 
GGSCI (target_server as gg_admin@db_target) 2>
register extract E2 database
 
2022-04-13 18:31:19 INFO OGG-02003 Extract E2 successfully registered with database at SCN 3386436450080


保存与“REGISTER EXTRACT”命令相关的 SCN 并创建 REGISTER EXTRACT :

[oracle@target_server:/u01/app/oracle/product/19.1.0.0.4/gg_1]$ mkdir -p /u01/gs_x/ogg/
 
GGSCI (target_server) 7> add extract E2, integrated tranlog, begin now
EXTRACT (Integrated) added.
 
GGSCI (target_server) 8> INFO ALL
 
Program Status Group Lag at Chkpt Time Since Chkpt
 
MANAGER RUNNING
EXTRACT STOPPED E2 00:00:02 00:00:08


提取 E2 从 19c 数据库中捕获数据,并且必须将参数文件配置为从 19c 数据库上的模式中提取数据。

GGSCI (target_server as gg_admin@db_target) 13> edit param e2 
Extract E2 
useridalias target 
Exttrail /u01/gs_x/ogg/gz
LOGALLSUPCOLS 
UPDATERECORDFORMAT COMPACT 
DDL & INCLUDE MAPPED OBJNAME target_schema.* 
Sequence target_schema.*; 
Table target_schema.* ;


使用 REGISTER EXTRACT 步骤后获得的 SCN 启动 EXTRACT:

GGSCI (target_server as gg_admin@db_target) 12> 
START EXTRACT E2 atcsn 3386436450080
 
Sending START request to MANAGER ...
EXTRACT E2 starting
 
GGSCI (TARGET_SERVER as gg_admin@target_db) 15> info all
 
Program Status Group Lag at Chkpt Time Since Chkpt
 
MANAGER RUNNING
EXTRACT RUNNING E2 00:00:05 00:00:03


第 9 步 – 在 19C 数据库上启动应用程序

将参数 job_queue_processes 更改为我们在 12c 数据库中的值(步骤 2)。

通过更改 DNS 别名在 19c 数据库上启动应用程序。

在这一步,停机时间结束……

第 10 步 – 在 19C 数据库上进行第一笔交易

查看与 REVERSE EXTRACT 相关的报告文件:

GGSCI (target_server as gg_admin@db_target) 71> 
view report e2
 
. . .
2022-04-13 18:38:40 INFO OGG-01872 Transaction delivery commencing with Transaction ID 482517513.14.30.1073,
CSN 3386436508051, 0 transaction(s) skipped.
 
. .
 
SCN --> CSN 3386436508051


切换后第一笔交易相关的SCN为3386436508051

第 11 步 - 创建反向副本 - (在发生故障时需要)

REVERSE REPLICAT 从 19c 数据库上发生的第一个事务将数据从 19c 数据库复制到 12c 数据库。

SCN 值非常重要,因为:

  • 在 SCN 3386436508051 之前,我们会在 12c 数据库上有重复数据
  • 在 SCN 3386436508051 之后,我们冒着在 12c 数据库上丢失数据的风险


GGSCI (source_server as ggadmin@source_db) 7> 
edit param r2
 
Replicat R2
DBOPTIONS INTEGRATEDPARAMS ( parallelism 6 )
DISCARDFILE /u01/app/oracle/product/19.1.0.0.4/gg_1/dirrpt/R2_discard.txt, append, megabytes 10
USERIDALIAS ggsource
MAP target_schema.*, TARGET source_schema.*;
 
add replicat R2 integrated exttrail /u01/gs_x/ogg/gz
 
GGSCI (source_server as ggadmin@source_db) 6>
add replicat R2 integrated exttrail /u01/gs_x/ogg/gz
REPLICAT (Integrated) added.
 
GGSCI (source_server as ggadmin@source_db) 7> info all
 
Program Status Group Lag at Chkpt Time Since Chkpt
 
MANAGER RUNNING
EXTRACT STOPPED E1 00:00:02 00:00:02
EXTRACT STOPPED P1 00:00:02 00:00:02
EXTRACT STOPPED R2 00:00:02 00:00:02


启动反向副本:

GGSCI (source_server as gg_admin@db_source) 52> 
start replicat r2 atcsn 3386436508051
 
GGSCI (source_server as gg_admin@db_source) 57> info all
 
Program Status Group Lag at Chkpt Time Since Chkpt
 
MANAGER RUNNING
EXTRACT STOPPED E1 00:00:02 00:00:00
EXTRACT STOPPED P1 00:00:02 00:00:00
REPLICAT RUNNING R2 00:00:02 00:00:00


从现在开始,12c 数据库从 19c 数据库同步

第 12 步 – 检查同步 – 19C –> 12C

像我们在步骤 1 中那样比较行。

第 13 步 – 移除或不移除所有 GOLDENGATE 流程

如果迁移已经过验证(应用程序在 19c 上按预期工作),请删除源服务器和目标服务器上的所有 GoldenGate 进程。

如果迁移尚未验证(应用程序未按预期工作),并且您想要回滚迁移,请重播步骤 1 中的所有步骤,但方向为 19c –> 12c,并在 12c 上启动应用程序。

 

结论

接近零停机时间迁移意味着应用程序切换停机时间非常短,因此从 1 到 9 的步骤必须尽可能快地完成,以最大限度地减少应用程序停机时间。

很难估计停机时间,因为它取决于应用程序的复杂性,并且在数据库之外和 GoldenGate 之外有很多组件会增加停机时间(jdbc/odbc 驱动程序兼容性、依赖应用程序、LDAP 连接配置……)

使用 GoldenGate 在几乎零停机时间内迁移 Oracle 数据库意味着几个非常重要的步骤:

  • 在切换之前检查没有更多的事务在运行,否则我们将丢失 19c 数据库中的数据
  • 在回滚的情况下,在我们创建 REVERSE EXTRACT(SCN 在 19c 上 REGISTER REVERSE EXTRACT 之后得到)和 REVERSE REPLICAT(19c 上第一个事务的 SCN)时选择正确的 SCN
  • 如果我们想要最少的停机时间,当然这个过程必须在尽可能接近 PROD 的非生产环境中进行测试,以便在您在 PROD 上执行它时做好准备。


文章来源:Lazhar Felahi

https://blog.dbi-services.com/near-zero-downtime-migration-and-failback-with-goldengate/

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论