資料庫管理-第119期 記一次遷移和效能最佳化（202301130）

1 遷移

之前因為DV元件沒有遷移成功的那個PDB，後來想著在目標端安裝DV元件遷移，結果目標端裝不上，而且開了SR也沒看出個所以然來。只能換一個方向，嘗試在源端PDB中刪除DV元件，而DV元件的刪除從12cR2開始就是一個老大難問題。最終根據 How To Enable/Install/Uninstall Database Vault in oracle database ? (Doc ID 2112167.1)，發現：

從12.2-19c，DV元件無法在CDB中被解除安裝
20c中也僅僅只能在PDB中解除安裝DV元件
注意：現在提供Patch 29890347補丁包允許在PDB中解除安裝DV元件

有了這個訊息，即可開始檢視 Patch 29890347: ADW18.1CDB: DV UNINSTALL SHOULD BE ALLOWED FROM WITHIN PDBS，這個補丁包比較和一般One-off patch有一點不一樣，一般補丁需要關閉資料庫應用，因為大多數會去影響資料庫的一些執行庫檔案，而這個補丁包僅僅只包含了替換SQL指令碼檔案：

對應README檔案裡面也沒有需要關閉資料庫的操作，因此直接應用補丁即可（其實就是個備份、刪除、複製的作業系統層面的操作）：

然後再在需要操作的PDB中解除安裝DV元件即可：

@?/rdbms/admin/dvremove.sql

指令碼執行完成後檢查，DV元件已被解除安裝：

到這裡後續在目標端的PDB克隆遷移操作就可以一股腦的整出來了（其實以前文章有）：

create pluggable database pdb_xxx from pdb_xxx@xxx_LINK;alter pluggable database pdb_xxx open upgrade;

$ORACLE_HOME/OPatch/datapatch -verbose

@?/rdbms/admin/utl32k.sql
@?/rdbms/admin/utlrp.sqlalter pluggable database close immediate

srvctl add service -db xxdbaas -pdb PDB_XXX -service XXXDB -preferred xxdbaas1,xxdbaas2
srvctl start service -db xxdbaas -s xxxdb

2 效能最佳化

3點過弄完盯了一會兒就睡覺，然後9點過早上另一個業務系統打電話說他們有個需要至少每10分鐘跑一次儲存過程突然變慢了，之前監控是從1分鐘慢慢延長到了5分鐘左右，今天突然來到25-30分鐘才能完成，雖然對業務本身執行影響不大，但是也帶來了一些時效性的問題。沒辦法，強制開機，頂著沉重的眼皮開始最佳化。
首先檢查了儲存過程中涉及的3個基表的情況，統計資訊沒啥問題，count(*)了一下來把資料刷入Exadata儲存快取，效能沒有明顯提升；其次EMCC上盯一下這個儲存過程，發現主要時間耗費在一個CTAS語句中，單獨拎出來跑其中的select語句也很慢，因此在EMCC上把SQL Monitor弄出來並檢查執行計劃，從最耗時的地方開始檢視：

而且從下面的執行計劃中還多次看到在這張FM_xxx_ALL_TEMP表的耗時，與業務方溝通理清了邏輯脈絡：

1. 先用delete命令刪除多張臨時表，其中包含FM_xxx_ALL_TEMP
2. 用insert select的方式向這張表插入資料
3. 在用CTAS新建一張表（就是慢在這個地方，後續做了啥就沒必要操心）

這中間就會有2個問題：

1. delete對錶操作可能會引起該表產生大量碎片，且這是個累積的過程，操作實踐前面是1->5分鐘的緩慢增加當達到一定量後就造成了較大的效能下降，因此建議用truncate來替代delete來清理全表資料
2. 中間表清理重新插入資料後，統計資訊大機率是異常的，因此建議在此操作步驟後新增對這張表的統計資訊收集操作

在業務方根據建議完成操作後，涉及儲存過程的執行時間立即從25-30分鐘下降至了40秒不到，比以前“正常”時候速度還要快一些。至此最佳化完成。（這裡還要感謝Oracle RWP團隊的董志平老師的支援）

總結

老規矩，知道寫了些啥。