重要系統Oracle資料庫U2L遷移場景中，如果客戶來問我建議，我都會回覆說首選就是XTTS，除非XTTS經測試實在是無法滿足停機視窗，否則就不要考慮OGG這類方案。
換句話說，選擇OGG做遷移的場景，都是沒有其他辦法時才會選用的方案了。
而在這類XTTS的遷移專案中,我認為bct的技術是至關重要的, 因為這會直接關係到你的遷移專案正式割接階段能否成功。
有不少人會說後設資料才最重要，我能理解這個講法，的確，後設資料在xtts遷移中也是個非常關鍵的點，但是它佔用割接視窗具體多少時間，基本在測試過程中就可以清楚知道，並不會和測試過程中有太大的出入。
而增量備份就不一樣，曾遇到有客戶日常演練很的很好，每次增量時間也很滿意，結果最後割接做最後一次增量時bct突然失效，直接導致全掃，無法滿足計劃內割接視窗，只能回退再找時間申請割接，導致各方面影響都很大。
最近有個客戶的核心繫統也是U2L，決定做XTTS遷移測試，因為在前期測試階段不允許對生產有任何干涉，所以決定建立一個2級備庫，以2級備庫模擬源端進行XTTS的流程測試。
因為專案比較典型，各方都比較重視，我還專門為此專案搞了套測試環境，方便幫助現場測試人員分析一些遇到的問題。
我的測試環境架構如下：
生產端：主庫 -> 備庫 -> 2級備庫
db11g -> db11gadg -> db11gcas目標端：RAC
rac1, 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/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';
到這裡，我突然想到，其實，現階段只測試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的風險。
好多年前給客戶做XTTS遷移，那會兒還是用的2.0版本，也遇到不少問題，感興趣的夥伴也可參見之前的文章《XTTS系列之一：U2L遷移解決方案之XTTS的使用》。
如今最新XTTS 4.3的版本，從MOS檔案看整個過程，已經大幅簡化了操作，也更加成熟穩定了。