重要系统Oracle数据库U2L迁移场景中，如果客户来问我建议，我都会回复说首选就是XTTS，除非XTTS经测试实在是无法满足停机窗口，否则就不要考虑OGG这类方案。换句话说，选择OGG做迁移的场景，都是没有其他办法时才会选用的方案了。
而在这类XTTS的迁移项目中,我认为bct的技术是至关重要的, 因为这会直接关系到你的迁移项目正式割接阶段能否成功。有不少人会说元数据才最重要，我能理解这个讲法，的确，元数据在xtts迁移中也是个非常关键的点，但是它占用割接窗口具体多少时间，基本在测试过程中就可以清楚知道，并不会和测试过程中有太大的出入。
(资料图)
而增量备份就不一样，曾遇到有客户日常演练很的很好，每次增量时间也很满意，结果最后割接做最后一次增量时bct突然失效，直接导致全扫，无法满足计划内割接窗口，只能回退再找时间申请割接，导致各方面影响都很大。
最近有个客户的核心系统也是U2L，决定做XTTS迁移测试，因为在前期测试阶段不允许对生产有任何干涉，所以决定建立一个2级备库，以2级备库模拟源端进行XTTS的流程测试。
因为项目比较典型，各方都比较重视，我还专门为此项目搞了套测试环境，方便帮助现场测试人员分析一些遇到的问题。我的测试环境架构如下：
1.选定最新XTTS脚本，开启bct2.ADG备库测试XTTS备份效果3.总结1.选定最新XTTS脚本，开启bct生产端：主库 -> 备库 -> 2级备库db11g -> db11gadg -> db11gcas
目标端：RACrac1, rac2
首先我测试模拟的业务用户是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/xttunzip rman_xttconvert_VER4.3.zip -d /home/oracle/xttcd /home/oracle/xttls -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";到这里，我突然想到，其实，现阶段只测试bct的话，没必要搞这么复杂，直接在我的一套ADG环境测试下XTTS备份效果就能得出结论，所以先不折腾全过程了，只关注下我们所关注的bct，我这里的环境是19c多租户的，来看下xtt.properties配置文件内容：
按我测试环境修改的xtt.properties：使用grep过滤以#号开头的注释行 和 空行，显示如下：
[oracle@bogon xtt]$ grep -vE "^#|^$" xtt.propertiestablespaces=TESTplatformid=13src_scratch_location=/u01/media/src_backupsdest_datafile_location=+DATADGdest_scratch_location=/xttsparallel=3rollparallel=2getfileparallel=4srcconnstr=sys/oracle@jingyudestconnstr=sys/oracle@jingyuallowstandby=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 a20COL STATUS FORMAT a20COL minutes FORMAT 999.999COL Input_mb FORMAT 99,999.99COL Output_mb FORMAT 99,999.99SELECT 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 minutesFROM V$RMAN_BACKUP_JOB_DETAILSORDER 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 3SESSION_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 ONLYSQL> SQL> SQL> select name from v$restore_point;no rows selectedSQL> create restore point before_read_write guarantee flashback database;Restore point created.SQL> select name from v$restore_point;NAME--------------------------------------------------------------------------------BEFORE_READ_WRITESQL> SQL> select CONTROLFILE_TYPE from v$database;CONTROL-------STANDBYSQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;Database altered.SQL> select CONTROLFILE_TYPE from v$database;CONTROL-------CURRENTSQL> 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 WRITESQL> 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文档看整个过程，已经大幅简化了操作，也更加成熟稳定了。
