XTTS系列之二：不可忽略的BCT - AlfredZhao
source link: https://www.cnblogs.com/jyzhao/p/17517982.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
XTTS系列之二：不可忽略的BCT - AlfredZhao - 博客园代码改变世界
XTTS系列之二：不可忽略的BCT
2023-06-30 22:50 AlfredZhao 阅读(15) 评论(0) 编辑 收藏 举报
重要系统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
首先我测试模拟的业务用户是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的风险。
- 1）备库测试最后阶段若打开激活备库为读写，那bct会失效；
- 2）建议有规划，不要做太多次增量，以免遇到参数影响或其他bug导致bct失效；
- 3）如果确认选用XTTS迁移，提前适当修改调大_bct_bitmaps_per_file
好多年前给客户做XTTS迁移，那会儿还是用的2.0版本，也遇到不少问题，感兴趣的伙伴也可参见之前的文章《XTTS系列之一：U2L迁移解决方案之XTTS的使用》。
如今最新XTTS 4.3的版本，从MOS文档看整个过程，已经大幅简化了操作，也更加成熟稳定了。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK