專案測試組又反饋一個問題，XTTS執行全量備份速度慢，影響測試進度。
實際算了下，平均速度才150MB/s..
這個速度在客戶生產環境的確是不夠看，首先詢問是否開了並行，開了多少？
回覆是說有開32個並行，在xtt.properties組態檔中指定的。
另外也注意在RMAN中show all的設定是預設沒有指定的。
同時有個重要的現象，在備份過程中，每次只生成一個資料檔案，按照順序寫的。
這個現象一描述出來，就嚴重懷疑是並行沒生效，懷疑是xtt.properties組態檔單獨設定那個並行不生效。
用我自己的測試環境直接驗證下吧，然後再給專案測試組去看到底該如何設定並行。
這裡模擬3個場景：
先做下準備工作：
在我的測試環境準備兩個表空間TEST、JINGYU，
其中TEST表空間有2個資料檔案，JINGYU表空間有1個資料檔案，每個資料檔案大小設定為1G（之前初始設定100M，結果發現太小的話不好觀察且時間誤差大）；
測試XTTS指令碼全量備份階段的實際效率。
sqlplus sys/oracle@jingyu as sysdba
SQL>
select FILE_NAME, bytes/1024/1024 "MB" from dba_data_files where TABLESPACE_NAME in ('TEST','JINGYU');
FILE_NAME MB
---------------------------------------------------------------------------------------- ----------
/flash/oradata/DEMO/fb6d1d5d4f0a245be0530b01a8c024da/datafile/jingyu1.dbf 1024
/flash/oradata/DEMO/fb6d1d5d4f0a245be0530b01a8c024da/datafile/test.308.1140833299 1024
/flash/oradata/DEMO/fb6d1d5d4f0a245be0530b01a8c024da/datafile/test1.dbf 1024
這也就是專案測試組目前的設定情況：
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
grep -vE '^$|^#' xtt.properties
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
[oracle@bogon xtt]$ grep -vE '^$|^#' xtt.properties
tablespaces=TEST,JINGYU
platformid=13
src_scratch_location=/xtts
dest_datafile_location=+DATADG
dest_scratch_location=/xtts
parallel=3
rollparallel=2
getfileparallel=4
srcconnstr=sys/oracle@jingyu
destconnstr=sys/oracle@jingyu
allowstandby=1
[oracle@db01rac1 xtt]$
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3
注意：有個小技巧，為了反覆全新測試這個XTTS第一次全備場景，在每次執行前可直接刪除TMPDIR下的臨時檔案以及src_scratch_location下面備份出來的檔案。
建議TMDIR設定在xtts指令碼中的一個單獨目錄，這樣好做清理。
比如我這裡是：TMPDIR=/home/oracle/xtt/tmp
同時注意tmp目錄下面的檔案刪除，tmp目錄本身不能刪除。
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:ss') start_time,
TO_CHAR(END_TIME,'yyyy-mm-dd hh24:mi:ss') end_time,
INPUT_BYTES/1024/1024 Input_mb,
OUTPUT_BYTES/1024/1024 Output_mb,
ELAPSED_SECONDS Seconds
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;
本次測試結果：
SESSION_KEY INPUT_TYPE STATUS START_TIME END_TIME INPUT_MB OUTPUT_MB SECONDS
----------- -------------------- -------------------- ------------------- ------------------- ---------- ---------- ----------
5073 DATAFILE FULL COMPLETED 2023-07-04 12:33:19 2023-07-04 12:33:50 2,048.00 2,048.00 31
5075 DATAFILE FULL COMPLETED 2023-07-04 12:33:52 2023-07-04 12:34:07 1,024.00 1,024.00 15
可以看到，在xtt.properties組態檔中指定了3個並行度，rman組態檔預設為1的情況下：
TEST表空間2個資料檔案，從2023-07-04 12:33:19 到 2023-07-04 12:33:50，耗時31秒。
JINGYU表空間1個資料檔案，從2023-07-04 12:33:52 到 2023-07-04 12:34:07，耗時15秒。
整個任務共耗時46秒。整體平均速度68MB/s。
從這個資料判斷，這種設定組合下並沒有用到並行。
那如果換過來測試呢？只在RMAN設定並行，xtt組態檔中不指定並行：
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
grep -vE '^$|^#' xtt.properties
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
using target database control file instead of recovery catalog
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters are successfully stored
[oracle@bogon xtt]$ grep -vE '^$|^#' xtt.properties
tablespaces=TEST,JINGYU
platformid=13
src_scratch_location=/xtts
dest_datafile_location=+DATADG
dest_scratch_location=/xtts
parallel=1
rollparallel=2
getfileparallel=4
srcconnstr=sys/oracle@jingyu
destconnstr=sys/oracle@jingyu
[oracle@db01rac1 xtt]$
rm -rf ./tmp/*
rm -rf /xtts/*.tf
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3
結果如下：
SQL> /
SESSION_KEY INPUT_TYPE STATUS START_TIME END_TIME INPUT_MB OUTPUT_MB SECONDS
----------- -------------------- -------------------- ------------------- ------------------- ---------- ---------- ----------
5078 DATAFILE FULL COMPLETED 2023-07-04 12:44:23 2023-07-04 12:44:49 3,072.00 3,072.00 26
[oracle@bogon xtts]$ ls -lrth
total 3.1G
drwx------. 2 root root 64K Jun 1 14:31 lost+found
-rw-r-----. 1 oracle oinstall 1.1G Jul 4 12:44 TEST_35.tf
-rw-r-----. 1 oracle oinstall 1.1G Jul 4 12:44 TEST_34.tf
-rw-r-----. 1 oracle oinstall 1.1G Jul 4 12:44 JINGYU_36.tf
可以看到，在xtt.properties組態檔中指定了1個並行度，rman組態檔設定為3的情況下：
TEST表空間2個資料檔案和JINGYU表空間1個資料檔案，作為一個任務跑，從2023-07-04 12:44:23 到 2023-07-04 12:44:49，耗時26秒。
從這個資料判斷，這種設定組合下用到了並行。
整個過程耗時也是26秒。整體平均速度118MB/s。
這裡均指定並行度3:
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters are successfully stored
[oracle@bogon xtt]$ grep -vE '^$|^#' xtt.properties
tablespaces=TEST,JINGYU
platformid=13
src_scratch_location=/xtts
dest_datafile_location=+DATADG
dest_scratch_location=/xtts
parallel=3
rollparallel=2
getfileparallel=4
srcconnstr=sys/oracle@jingyu
destconnstr=sys/oracle@jingyu
[oracle@db01rac1 xtt]$
rm -rf ./tmp/*
rm -rf /xtts/*.tf
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3
結果如下：
SQL> /
SESSION_KEY INPUT_TYPE STATUS START_TIME END_TIME INPUT_MB OUTPUT_MB SECONDS
----------- -------------------- -------------------- ------------------- ------------------- ---------- ---------- ----------
5081 DATAFILE FULL COMPLETED 2023-07-04 12:57:16 2023-07-04 12:57:42 2,048.00 2,048.00 26
5083 DATAFILE FULL COMPLETED 2023-07-04 12:57:45 2023-07-04 12:58:00 1,024.00 1,024.00 15
這個結果感覺是有點兒問題，但可以肯定TEST和JINGYU這兩個表空間是序列執行的，可是TEST表空間內部的資料檔案看起來有用到並行，但效果非常不好，為了排除掉我測試環境本身效能不穩定導致，所以清空環境重測一遍：
SQL> /
SESSION_KEY INPUT_TYPE STATUS START_TIME END_TIME INPUT_MB OUTPUT_MB SECONDS
----------- -------------------- -------------------- ------------------- ------------------- ---------- ---------- ----------
5085 DATAFILE FULL COMPLETED 2023-07-04 13:01:26 2023-07-04 13:01:42 2,048.00 2,048.00 16
5087 DATAFILE FULL COMPLETED 2023-07-04 13:01:45 2023-07-04 13:02:01 1,024.00 1,024.00 16
嗯，這次結果就非常清晰好看了：
TEST和JINGYU這兩個表空間是序列執行的，然後TEST表空間內部的資料檔案確認有用到並行。
可以看到，在xtt.properties組態檔中指定了3個並行度，rman組態檔也設定為3的情況下：
TEST表空間2個資料檔案，從2023-07-04 13:01:26 到 2023-07-04 13:01:42，耗時16秒。這一階段平均速度128MB/s。
JINGYU表空間1個資料檔案，從2023-07-04 13:01:45 到 2023-07-04 13:02:01，耗時16秒。這一階段平均速度64MB/s。
總耗時32秒。
按照我測試環境的驗證結果：
1.RMAN未設定並行，只在xtt組態檔中指定並行
不同表空間是序列執行，表空間內部的資料檔案也是序列。
也就是說全部序列操作，效率最差！
總耗時46秒。整體平均速度68MB/s。
2.RMAN設定並行，xtt組態檔中不指定並行
有用到並行。
總耗時26秒。整體平均速度118MB/s。
3.RMAN和xtt組態檔均指定並行
不同表空間是序列執行，表空間內部的資料檔案有用到並行。
第一階段：平均速度128MB/s。
第二階段：平均速度64MB/s。
總耗時32秒。整體平均速度96MB/s。
實踐出真知，目前現象可以肯定的是，RMAN未設定並行肯定是不行的。
然後看起來xtt組態檔是否指定並行，對結果關係並不大？
因為XTTS指令碼是MOS提供的，我們需要實際去看下這個指令碼的說明檔案，
看看有關這個並行到底是咋描述的？
parallel
Defines the degree of parallelism used in copying (prepare phase), converting. Incremental backup creation parallelism is defined by RMAN configuration for DEVICE TYPE DISK PARALLELISM.
呵呵噠，增量備份（第一次0級備份也算增量備份）的並行度，人家檔案說了要在RMAN設定的。
而這個xtts指令碼中的並行，有點兒像是要把備份分成幾批的感覺，完成一批就可以先做這部分的拷貝。
比如上面我測試場景2，不指定，兩個表空間共3個檔案就一個任務備份的，指定後，就拆分開來了。
我這裡測試檔案少就不展開了，如有興趣可自行測試下。
總之，做XTTS測試時，這個RMAN並行度一定設定好，具體設定多少取決於你的儲存IO能力、可用能力以及...你懂的。