近期在某銀行生產環境做的一次PDB遷移，使用的是PDB refresh方式，記錄一下流程及遇到的坑。
推薦視頻：經典知識庫：Oracle PDB Refresh實戰分享 - 李海清
上述視頻詳細介紹了什么是PDB Refresh、使用場景、遷移流程，本文流程也是依照該視頻為主要參考，推薦學習。
一、源庫及目標庫情況
源庫與目標庫情況：
| 源庫 | 目標庫 | |
|---|---|---|
| 系統版本 | REHL 7.6 | RHEL 7.6 |
| 數據庫版本 | 19.11 | 19.11 |
| 數據量 | 7 T | |
| 停機時間 | 2 hour |
二、遷移方式選擇
根據以上的情況，認為DG與PDB refresh方式是比較好的選擇。
- DG相較于PDB refresh配置更麻煩
- PDB refresh的前置條件比DG多
- 停機時間來看，DG略短于PDB refresh
最后還是定的使用PDB refresh，主要是因為沒在生產上做過，積累下經驗，另外也簡單：）
三、什么是PDB Refresh
簡單來說：創建目標端到源端的DBlink，目標端create pluggable database，指向源端PDB，這樣就將源端PDB copy過來，copy過程源端無需停機，再設置refresh刷新，可以將源庫的增量也應用到目標端。切換時源端read only，目標端read write，完事。
注意：
- PDB Refresh支持三種類型的源端數據庫，分別是Local PDB/PDB in a remote CDB/Non-CDB。
- PDB Refresh不支持跨平臺、不支持跨大版本。
四、遷移流程
4.1 準備階段
- 數據庫版本。源庫的版本不能大于目標端,可以同版本遷移或從低版本遷移到高版本，不支持高版本到低版本
sqlplus -v
- 源端和目標端數據庫必須為歸檔模式。源端和目標端數據庫必須為歸檔模式
archive log list
注意：
建議源庫及目標庫設置歸檔路徑使用閃回區，否則刷新時可能會遇到如下BUG，這是我踩到的坑之一！
Bug 33331329 - Intermittent ORA-65345 in Clone PDB When log_archive_dest_n=‘location=use_db_recovery_file_dest’ is Not Set (Doc ID 33331329.8)
Bug 32631551 - Refresh pluggable database fails with ORA-283: recovery session canceled due to errors ORA-65345: cannot refresh pluggable database (Doc ID 32631551.8)
- 字符集。源庫pdb的字符集要和目標CDB的字符集和國家字符集兼容，例如目標庫是AL32UTF8的話，源庫可以是ZHS16GBK，但是反過來就不行
select userenv('language') from dual;
- 字節序。源庫目標庫需要相同
set lines 120
col platform_name for a20
select db.name,db.platform_id,db.platform_name,os.endian_format from v$database db,v$transportable_platform os where db.platform_id=os.platform_id;
- PDB必須使用本地UNDO表空間
col property_name for a30
col property_value for a20
select property_name,property_value from database_properties where property_name='LOCAL_UNDO_ENABLED';
--切換到PDB下查看undo表空間是否存在
select name from v$datafile where name like '%undo%';
參考：Undo Modes in 12.2 Multitenant Databases - Local and Shared Modes (Doc ID 2169828.1)
- 數據庫組件。目標庫的組件要與源庫一致，或者包含源庫的組件，如果源庫安裝的組件比目標庫多，需要在源庫PDB下先刪掉多出的組件，刪除方式參考文章開頭的推薦鏈接查看。這也是個坑，務必提前檢查
select comp_id from dba_registry where status!='REMOVED';
- 確保目標庫庫CDB有足夠的剩余SGA/PGA內存分配給refresh PDB；
- 確保目標庫磁盤組有足夠的剩余可用空間（數據文件物理空間）存放遷移過去的PDB并有適量余量。
- 如果目標cdb中存在users表空間，且被其他c##用戶使用著，需要在源pdb預先創建users表空間。
- 源庫目標庫檢查OMF是否啟用，沒啟用的話，克隆時需要指定filel_name_convert參數
show parameter db_create_file_dest
11.另外參考視頻中還提到：源庫pdb中可能存在目標庫cdb中沒有的c##用戶。需要進行刪除操作。
生產環境不太適合刪除，我是在目標庫創建相同賬戶處理。
4.2 同步階段
- 源庫創建container用戶
create user C##hf_refresh identified by Password123 container=all;
grant create session,sysoper,create pluggable database to c##hf_refresh container=all;
- 目標庫創建dblink連接到源庫CDB
create public database link hf_refresh_dblink connect to c##hf_refresh identified by Password123 using '10.9.xxx.xx:1521/RAP010';
- 目標端創建clone refresh pdb，創建完成為mounted狀態(我實際操作7T，2小時內create完成)
--由于不確定多久能create完成，所以使用腳本后臺執行，這里我們設置create完成后每10分鐘自動刷新
#!/bin/bash
export ORACLE_SID=xxxx
echo $ORACLE_SID;
sqlplus -S / as sysdba<<eof
show pdbs;
create pluggable database xxx from xxx@hf_refresh_dblink refresh mode every 10 minutes;
show pdbs;
eof
關于刷新方式：
--設置手工刷新模式
alter pluggable database xxx refresh mode manual;
--手工刷新，哪怕設置了自動刷新，也可以手動刷
alter pluggable database xxx refresh;
--每小時刷一次
alter pluggable database xxx refresh mode every 1 hours;
此步驟完成，可以正常刷新的話，后面沒發現有什么坑。
- 測試增量傳輸
可以在源庫創建測試表，目標端以read only方式打開查看，測試是否能正常到目標庫
--目標端操作
alter pluggable database xxx open read only instances=all;
alter session set container=xxx;
--檢查測試數據傳輸后恢復到可刷新狀態
alter pluggable database xxx close immediate;
alter pluggable database xxx refresh mode every 10 minutes;
4.3 切換階段
- 應用側關閉所有業務，期間可以手工刷新一次減少增量數據
alter pluggable database xxx refresh;
- 源庫操作：應用關閉后，一致性關閉源庫，再以read only模式打開。（確保無新業務進來，job也不再運行）
alter pluggable database xxx close immediate instances=all;
alter pluggable database xxx open read only instances=all;
- 目標庫最后一次刷新
alter pluggable database xxx refresh;
- 激活目標庫
--設置刷新模式為none（不可逆）
alter pluggable database xxx refresh mode none;
- 打開目標庫
alter pluggable database xxx open instances=all;
- 執行datapatch
$ORACLE_HOME/OPatch/datapatch -pdbs xxx
- 如果此時pdb為受限狀態，需要重啟pdb，兩節點執行
- 創建與源庫同名service。PDB refresh完成需要自己創建服務
--oracle run
srvctl add service -d 實例名 -pdb pdb名 -s 服務名 -r 節點1sid,節點2sid -P BASIC -y automatic -z 10 -w 10 -e select -m basic
- 檢查無問題通知網絡專業，修改域名ip對應關系，或者提供新連接串給應用側
- 可以對比源庫目標庫對象數量，抽取關鍵表對比行數以及檢查失效對象
- 通知應用側起應用測試
完成此步驟，遷移結束。
4.4 異常處理
如果應用測試有問題，則將源庫關閉重新open，應用使用原先連接串即可。
4.5 時間消耗
實際切換用時20分鐘，源庫關閉執行檢查點及目標庫執行datapath稍微耗時多一點。
五、PDB Refresh如何讀取增量數據？
首先讀redo，沒有的話讀歸檔日志，已測試驗證。
另外rac環境切換歸檔，需要使用alter system archive log current;如果用了alter system switch logfile會導致refresh失敗。
六、小結
條件合適的情況下，使用PDB Refresh方式遷移PDB簡單快捷，但是目前感覺坑多一點。
