重要系统Oracle数据库U2L迁移场景中，如果客户来问我建议，我都会回复说首选就是XTTS，除非XTTS经测试实在是无法满足停机窗口，否则就不要考虑OGG这类方案。

换句话说，选择OGG做迁移的场景，都是没有其他办法时才会选用的方案了。

而在这类XTTS的迁移项目中,我认为bct的技术是至关重要的, 因为这会直接关系到你的迁移项目正式割接阶段能否成功。

有不少人会说元数据才最重要，我能理解这个讲法，的确，元数据在xtts迁移中也是个非常关键的点，但是它占用割接窗口具体多少时间，基本在测试过程中就可以清楚知道，并不会和测试过程中有太大的出入。

而增量备份就不一样，曾遇到有客户日常演练很的很好，每次增量时间也很满意，结果最后割接做最后一次增量时bct突然失效，直接导致全扫，无法满足计划内割接窗口，只能回退再找时间申请割接，导致各方面影响都很大。

最近有个客户的核心系统也是U2L，决定做XTTS迁移测试，因为在前期测试阶段不允许对生产有任何干涉，所以决定建立一个2级备库，以2级备库模拟源端进行XTTS的流程测试。

因为项目比较典型，各方都比较重视，我还专门为此项目搞了套测试环境，方便帮助现场测试人员分析一些遇到的问题。

我的测试环境架构如下：

生产端：主库 -> 备库 -> 2级备库

db11g -> db11gadg -> db11gcas

目标端：RAC

rac1, rac2

1.选定最新XTTS脚本，开启bct
2.ADG备库测试XTTS备份效果
3.总结

1.选定最新XTTS脚本，开启bct

首先我测试模拟的业务用户是JINGYU，表空间是DBS_D_JINGYU, DBS_I_JINGYU，然后对应XTTS的脚本是最新的V4.3：

# @db11g:

select distinct tablespace_name from dba_segments where owner='JINGYU' order by 1;

execute dbms_tts.transport_set_check('DBS_D_JINGYU, DBS_I_JINGYU');

select * from TRANSPORT_SET_VIOLATIONS; 

# @db11gcas, 创建XTTS工作目录

[oracle@db11gcas ~]$

mkdir -p /home/oracle/xtt

unzip rman_xttconvert_VER4.3.zip -d /home/oracle/xtt

cd /home/oracle/xtt

ls -lrth

# @db11g, 源端开启bct（block change tracking）

SQL>

select * from v$block_change_tracking;

Get小知识：db11g开启了bct，但是db11gadg和db11gcas并不会同步开启。

这也说明ADG的同步，bct不会自动同步哦～

以后面试可以问问候选人哪些东西ADG不会同步，哈哈，非常考验候选人功力，看看能说出几个，能说出的估计都是DBA老炮儿了。

现在手工开启，在备库db11gadg和db11gcas也都执行命令：

# @db11gadg, @db11gcas:

alter database enable block change tracking using file '/u01/app/oracle/bct.dbf'; 

alter database disable block change tracking;

# @db11g, @db11gadg, @db11gcas:

CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET;

backup incremental level 0 tablespace DBS_D_JINGYU, DBS_I_JINGYU format '/u01/media/%U.bck';

2.ADG备库测试XTTS备份效果

到这里，我突然想到，其实，现阶段只测试bct的话，没必要搞这么复杂，直接在我的一套ADG环境测试下XTTS备份效果就能得出结论，所以先不折腾全过程了，只关注下我们所关注的bct，我这里的环境是19c多租户的，来看下xtt.properties配置文件内容：

按我测试环境修改的xtt.properties：

使用grep过滤以#号开头的注释行和空行，显示如下：

[oracle@bogon xtt]$ grep -vE '^#|^$' xtt.properties

tablespaces=TEST

platformid=13

src_scratch_location=/u01/media/src_backups

dest_datafile_location=+DATADG

dest_scratch_location=/xtts

parallel=3

rollparallel=2

getfileparallel=4

srcconnstr=sys/oracle@jingyu

destconnstr=sys/oracle@jingyu

allowstandby=1

设置TMPDIR目录变量：

export TMPDIR=/home/oracle/xtt/tmp

其实直接写入到环境变量中最方便。

然后开始执行XTTS备份测试：

[oracle@bogon xtt]$

$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

这里需要使用 v$RMAN_BACKUP_JOB_DETAILS 来查看详情：

set lines 180 pages 200

COL INPUT_TYPE FORMAT a20

COL STATUS FORMAT a20

COL minutes FORMAT 999.999

COL Input_mb FORMAT 99,999.99

COL Output_mb FORMAT 99,999.99

SELECT SESSION_KEY, INPUT_TYPE, STATUS,

TO_CHAR(START_TIME,'yyyy-mm-dd hh24:mi') start_time,

TO_CHAR(END_TIME,'yyyy-mm-dd hh24:mi') end_time,

INPUT_BYTES/1024/1024 Input_mb,

OUTPUT_BYTES/1024/1024 Output_mb,

ELAPSED_SECONDS/60 minutes

FROM V$RMAN_BACKUP_JOB_DETAILS

ORDER BY SESSION_KEY;

INPUT_BYTES

NUMBER

Sum of all input file sizes backed up by this job

OUTPUT_BYTES

NUMBER

Output size of all pieces generated by this job

从官方文档解释来看，INPUT_BYTES 实际上就是指备份时读取的文件大小，而 OUTPUT_BYTES 指的是备份实际备份出来的文件大小。

如果不看文档说明，这两个参数很容易误会给搞反了。

先看不开启BCT时，实际是这样的效果：

SESSION_KEY INPUT_TYPE           STATUS               START_TIME       END_TIME           INPUT_MB  OUTPUT_MB  MINUTES

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

       4891 DATAFILE FULL        COMPLETED            2023-06-30 14:51 2023-06-30 14:51     100.00     100.00     .050

       4894 DATAFILE FULL        COMPLETED            2023-06-30 15:23 2023-06-30 15:23      97.00        .05     .033

       4896 DATAFILE FULL        COMPLETED            2023-06-30 15:30 2023-06-30 15:30      97.00        .05     .067

       4898 DATAFILE FULL        COMPLETED            2023-06-30 15:31 2023-06-30 15:31      97.00        .05     .133

每次备份都读取了接近100M的文件大小。

这里把xtts的tmp整个干掉，重测下bct的效果。

注意：实际测试不能轻易删除整个tmp目录，里面的文件没有了，XTTS脚本就不知道数据文件该从哪开始恢复了。

[oracle@bogon xtt]$

$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

SESSION_KEY INPUT_TYPE           STATUS               START_TIME       END_TIME           INPUT_MB  OUTPUT_MB  MINUTES

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

       4900 DATAFILE FULL        COMPLETED            2023-06-30 15:34 2023-06-30 15:34     100.00     100.00     .033

       4903 DATAFILE FULL        COMPLETED            2023-06-30 15:36 2023-06-30 15:36        .00        .00     .000

看见没？这就是bct的魅力所在，4903这一行，INPUT_MB直接近似为0，因为我这里除了SCN变化，数据一点没变。

但没有bct，就还是像之前那样读取接近整个数据文件的大小，比如上面测试的4894、4896、4898那些。

再测两把，依然是很小的INPUT_MB：

SESSION_KEY INPUT_TYPE           STATUS               START_TIME       END_TIME           INPUT_MB  OUTPUT_MB  MINUTES

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

       4905 DATAFILE FULL        COMPLETED            2023-06-30 15:40 2023-06-30 15:40        .01        .05     .067

       4907 DATAFILE FULL        COMPLETED            2023-06-30 15:41 2023-06-30 15:41        .01        .05     .133

那现在来测试下一个场景：

我这里是备库角色，我要激活打开，看BCT是否会失效？

该备库环境已经开启了数据库闪回，新建一个还原点：

create restore point before_read_write guarantee flashback database;

然后置换读写的参考命令：

select database_role, open_mode from v$database;

select name from v$restore_point;

create restore point before_read_write guarantee flashback database;

select name from v$restore_point;

select CONTROLFILE_TYPE from v$database;

ALTER DATABASE ACTIVATE STANDBY DATABASE;

select CONTROLFILE_TYPE from v$database;

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

ALTER DATABASE OPEN;

select database_role, open_mode from v$database;

alter pluggable database all open;

实际操作如下：

SQL> select database_role, open_mode from v$database;

DATABASE_ROLE    OPEN_MODE

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

PHYSICAL STANDBY READ ONLY

SQL>

SQL>

SQL> select name from v$restore_point;

no rows selected

SQL> create restore point before_read_write guarantee flashback database;

Restore point created.

SQL> select name from v$restore_point;

NAME

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

BEFORE_READ_WRITE

SQL>

SQL> select CONTROLFILE_TYPE from v$database;

CONTROL

-------

STANDBY

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

Database altered.

SQL> select CONTROLFILE_TYPE from v$database;

CONTROL

-------

CURRENT

SQL>

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

Database altered.

SQL> ALTER DATABASE OPEN;

Database altered.

SQL>

SQL> select database_role, open_mode from v$database;

DATABASE_ROLE    OPEN_MODE

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

PRIMARY          READ WRITE

SQL> 

SQL> alter pluggable database all open;

Pluggable database altered.

之后再次进行测试，也就是模拟XTTS在备库测试，需要打开读写后做最后一次增量测试：

SESSION_KEY INPUT_TYPE           STATUS               START_TIME       END_TIME           INPUT_MB  OUTPUT_MB  MINUTES

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

       4900 DATAFILE FULL        COMPLETED            2023-06-30 15:34 2023-06-30 15:34     100.00     100.00     .033

       4903 DATAFILE FULL        COMPLETED            2023-06-30 15:36 2023-06-30 15:36        .00        .00     .000

       4905 DATAFILE FULL        COMPLETED            2023-06-30 15:40 2023-06-30 15:40        .01        .05     .067

       4907 DATAFILE FULL        COMPLETED            2023-06-30 15:41 2023-06-30 15:41        .01        .05     .133

       4909 DATAFILE FULL        COMPLETED            2023-06-30 15:56 2023-06-30 15:56     100.00        .05     .033

看到没，最新的4909就是模拟的最后一次增量，INPUT_MB读取了整个数据文件的大小。

重现了测试问题，也就是bct失效的确是由于置换成读写导致的。

那如果数据库就是读写状态（模拟主库场景），后续bct会不会一直不失效呢？我记着之前有同事曾遇到过超过8次失效的问题，验证下：

SESSION_KEY INPUT_TYPE           STATUS               START_TIME       END_TIME           INPUT_MB  OUTPUT_MB  MINUTES

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

       4909 DATAFILE FULL        COMPLETED            2023-06-30 15:56 2023-06-30 15:56     100.00        .05     .033

       4911 DATAFILE FULL        COMPLETED            2023-06-30 15:59 2023-06-30 15:59        .01        .05     .033

       4913 DATAFILE FULL        COMPLETED            2023-06-30 16:00 2023-06-30 16:00        .01        .05     .033

       4915 DATAFILE FULL        COMPLETED            2023-06-30 16:00 2023-06-30 16:00        .01        .05     .033

       4917 DATAFILE FULL        COMPLETED            2023-06-30 16:01 2023-06-30 16:01        .01        .05     .017

       4919 DATAFILE FULL        COMPLETED            2023-06-30 16:01 2023-06-30 16:01        .01        .05     .017

       4921 DATAFILE FULL        COMPLETED            2023-06-30 16:01 2023-06-30 16:01        .01        .05     .033

       4923 DATAFILE FULL        COMPLETED            2023-06-30 16:02 2023-06-30 16:02        .01        .05     .033

       4925 DATAFILE FULL        COMPLETED            2023-06-30 16:02 2023-06-30 16:02        .01        .05     .033

       4927 DATAFILE FULL        COMPLETED            2023-06-30 16:02 2023-06-30 16:02        .01        .05     .033

       4929 DATAFILE FULL        COMPLETED            2023-06-30 16:02 2023-06-30 16:02        .01        .05     .033

       4931 DATAFILE FULL        COMPLETED            2023-06-30 17:38 2023-06-30 17:38        .01        .05     .033

看来这里并没有出现8次后失效的现象，这个所谓8次对应了一个隐藏参数：_bct_bitmaps_per_file

NAME                                DESCRIPTION                                                        VALUE

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

_bct_bitmaps_per_file               number of bitmaps to store for each datafile                       8

不过，保险起见，如果你可能要做超过8次的增量备份，还是建议将这个参数设置大一些。或者干脆避免超过8次引发bct失效问题，做得太多也会增大遇到bug的风险。

3.总结

1）备库测试最后阶段若打开激活备库为读写，那bct会失效；
2）建议有规划，不要做太多次增量，以免遇到参数影响或其他bug导致bct失效；
3）如果确认选用XTTS迁移，提前适当修改调大_bct_bitmaps_per_file

好多年前给客户做XTTS迁移，那会儿还是用的2.0版本，也遇到不少问题，感兴趣的伙伴也可参见之前的文章《XTTS系列之一：U2L迁移解决方案之XTTS的使用》。

如今最新XTTS 4.3的版本，从MOS文档看整个过程，已经大幅简化了操作，也更加成熟稳定了。

XTTS系列之二：不可忽略的BCT的更多相关文章

当我们说线程安全时，到底在说什么——Java进阶系列（二）
原创文章,同步发自作者个人博客,转载请以超链接形式在文章开头处注明出处http://www.jasongj.com/java/thread_safe/ 多线程编程中的三个核心概念原子性这一点,跟数 ...
《sed的流艺术之一》-linux命令五分钟系列之二十一
本原创文章属于<Linux大棚>博客,博客地址为http://roclinux.cn.文章作者为rocrocket. 为了防止某些网站的恶性转载,特在每篇文章前加入此信息,还望读者体谅. ...
Wix打包系列（二）用户界面和本地化操作
原文:Wix打包系列(二)用户界面和本地化操作上一章节,我们已经大概知道如何对文件进行打包安装,不过我们也注意到,通过对Sample.wxs的编译链接,生成的msi安装包没有任何用户界面,只有一个安 ...
Alamofire源码解读系列(十二)之请求(Request)
本篇是Alamofire中的请求抽象层的讲解前言在Alamofire中,围绕着Request,设计了很多额外的特性,这也恰恰表明,Request是所有请求的基础部分和发起点.这无疑给我们一个Req ...
Hadoop 系列（二）安装配置
Hadoop 系列(二)安装配置 Hadoop 官网:http://hadoop.apache.or 一.Hadoop 安装 1.1 Hadoop 依赖的组件 JDK :从 Oracle 官网下载,设 ...
Zookeeper 系列（二）安装配制
Zookeeper 系列(二)安装配制一.Zookeeper 的搭建方式 Zookeeper 安装方式有三种,单机模式和集群模式以及伪集群模式. 单机模式 :Zookeeper 只运行在一台服务器上 ...
分布式理论系列（二）一致性算法：2PC 到 3PC 到 Paxos 到 Raft 到 Zab
分布式理论系列(二)一致性算法:2PC 到 3PC 到 Paxos 到 Raft 到 Zab 本文介绍一致性算法: 2PC 到 3PC 到 Paxos 到 Raft 到 Zab 两类一致性算法(操作原 ...
C#基础拾遗系列之二：使用ILSpy探索C#7.0新增功能点
C#基础拾遗系列之二:使用ILSpy探索C#7.0新增功能点第一部分: C#是一种通用的,类型安全的,面向对象的编程语言.有如下特点: (1)面向对象:c# 是面向对象的范例的一个丰富实现, 它 ...
SQL Sever 学习系列之二
SQL Sever 学习系列之二 SQL Server 学习系列之一(薪酬方案+基础) 四.有关时间输出问题 select GETDATE() 日期时间 ----显示为:2013-07 ...
【疯狂造轮子-iOS】JSON转Model系列之二
[疯狂造轮子-iOS]JSON转Model系列之二本文转载请注明出处 —— polobymulberry-博客园 1. 前言上一篇<[疯狂造轮子-iOS]JSON转Model系列之一> ...

随机推荐

Springboot集成MyBatis进行开发
引入相关的依赖 <dependency> <groupId>junit</groupId> <artifactId>junit</artifact ...
CommunityToolkit.Mvvm8.1 消息通知(4)
本系列文章导航 https://www.cnblogs.com/aierong/p/17300066.html https://github.com/aierong/WpfDemo (自我Demo地址 ...
【Vue】一
Vue简介 el和data的两种写法 const v = new Vue({ el: '#root', data: { name: '123' } }) 动态指定el容器 console.log(v) ...
RabbitMQ详解（上）
一:MQ的相关概念 MQ(message queue),从字面意思上看,本质是个队列,FIFO 先入先出,只不过队列中存放的内容是message 而已,还是一种跨进程的通信机制,用于上下游传递消息.在 ...
【深入浅出Spring原理及实战】「源码调试分析」深入源码探索Spring底层框架的的refresh方法所出现的问题和异常
学习Spring源码的建议阅读Spring官方文档,了解Spring框架的基本概念和使用方法. 下载Spring源码,可以从官网或者GitHub上获取. 阅读Spring源码的入口类,了解Sprin ...
2022-03-26：给定一个无向图，从任何一个点x出发，比如有一条路径: x -＞ a -＞ b -＞ c -＞ y，这条路径上有5个点并且5个点都不一样的话，我们说(x,a,b,c,y)是一条
2022-03-26:给定一个无向图, 从任何一个点x出发,比如有一条路径: x -> a -> b -> c -> y, 这条路径上有5个点并且5个点都不一样的话,我们说(x ...
vue一直处在2.9.6版本卸载不了升级不了解决方案
直接 win+R打开cmd窗口运行命令: 输入where vue,找到vue安装位置,把找到的文件删掉再执行一次npm uninstall vue-cli -g, vue -V,已经没有版本号了此 ...
structed streaming 触发器trigger
structed streaming的执行批次,较spark streaming有所改变.更加灵活.总结下来,可大白话地分为三类: 1尽可能快的执行,不定时间 2按固定间隔时间执行 3仅执行一次详情 ...
2013年蓝桥杯C／C++大学A组省赛真题（高斯的日记）
题目描述: 大数学家高斯有个好习惯:无论如何都要记日记. 他的日记有个与众不同的地方,他从不注明年月日,而是用一个整数代替,比如:4210 后来人们知道,那个整数就是日期,它表示那一天是高斯出生后的第 ...
linux ssh远程登录
目录一.ssh概念二.配置文件三.ssh组成结构四.远程控制过程五.远程复制六.配置密钥七.wraooers防火墙一.ssh概念 ssh:一种安全通道协议功能:1.实现字符界面远程登 ...

XTTS系列之二：不可忽略的BCT

1.选定最新XTTS脚本，开启bct

2.ADG备库测试XTTS备份效果

3.总结

XTTS系列之二：不可忽略的BCT的更多相关文章

随机推荐

热门专题