從12c版本12.1開始，就有了新特性——Pluggable Database，相比較之前通過schema的管理方式實現多使用者管理，Pluggable Database實現了進一步的隔離，其中包含如下特點：

1. 將業務使用者元資料和資料庫本身的元資料進行分離，減少核心資料字典的效能衰減，增加管理便捷性。
   
2. sga統一分配，各PDB通過各自的標識進行空間管理。
   

但在12.1中，PDB的字符集與root容器必須保持一致，這樣無形中造成了PDB遷移或者克隆的限制性。從12.2開始，同一個cdb中的各個PDB字符集可以不相同。

對於最新版本12.2.0.1，在新建立PDB時並沒有辦法指定PDB 的字符集，因此只能和root容器字符集相同，而不同PDB可以使用hot clone,或Relocate PDB online 方式直接plug-in，還可使用internal_use進行轉換

測試環境

環境：Oracle 12.2.0.1 （REL 6.9 x86-64）

目標端資料庫使用dbca建立容器資料庫，預設cdb預設字符集是AL32UTF8:

PDB字符集：

源端資料庫使用dbca建立容器資料庫，預設CDB預設字符集是ZHS16GBK，同時自帶ZHS16GBK的PDB，測試通過HOTCLONE PDB 和RELOCATE PDB插入到原字符集為AL32UTF8的CDB。

測試條件確認

1.源環境與目標環境平臺有相同的位元組序（endianness）

2.目標庫是AL32UTF8，源庫能為任意字符集（見環境準備）

3.對於options可選元件，源庫安裝的必須是目標庫的子集或相同

4.源庫和目標庫都為歸檔模式 

5.源庫和目標庫都使用LOCAL UNDO

6、步驟5滿足源端PDB在read write 狀態下進行克隆或relocate

注：如一開始並未使用LOCAL UNDO和歸檔模式，則通過如下方式開啟

確認當前操作會話為cdb，或者進行切換

熱克隆驗證

1.源庫CDB$ROOT建立common user

2.建立public dblink，連線到源庫

3.目標庫測試dblink

4.修改FILE_NAME_CONVERT

5.通過dblink克隆PDB

6.檢查克隆PDB

此時仍然是mount狀態，open開啟PDB

relocate原理

• 熱克隆+redo應用
  
• 準備條件同熱克隆
  
• 克隆時源庫可處於read write狀態
  
• 目標庫Create PDB完成，源庫dml事務仍可繼續
  
• 目標PDB open時源庫中止會話並同步redo（或歸檔資料）
  
• 源端應用undo資料回滾
  
• 源庫PDB會話自動切換到目標端
  
• 克隆語句使用AVALIABLITY選項nomal|high|max（見測試過程）

如有條件，還可以驗證應用連線自動切換到relocate目標端。

relocate測試

使用PDB relocate(PDB hot move)，條件、步驟基本與hot clone相同，且都可沿用Hot Clone的保留配置。

1.目標庫引數轉換

2.relocate

#在relocate過程中，理論上連線原庫PDBGBK的dml事務並不中斷。

3.relocate操作完成

4.此時源庫庫狀態（仍然承載連線和應用）：

通過v$diag_info檢視獲取12c alert日誌的位置：

其中從Diag Trace的位置中能夠找到alert裡記錄關於relocate的操作內容：

5.目標CDB中開啟PDB，切換PDB

SQL> alter pluggable database PDBGBK open;
Pluggable database altered.

當目標庫PDBGBK開啟，如應用連線配置沒有到目標庫，則直接連線原來源庫的連線會斷開且dml事務直接中斷。如有條件配置應用連線可以嘗試配置並驗證源庫和目標端的記錄條數和目標端。

另外注意監聽裡已經註冊上了pdbgbk的服務（instance屬於目標庫）

open過程中記錄操作：

目標庫中，relocate過來的庫狀態正常:

在目標庫的PDB open時候，源庫的alert記錄relocate結束，源PDB刪除操作：

內部轉換字符集

使用internal_use：

直接修改字符集報錯，說明新設字符集必須是老字符集的超集

使用INTERNAL_USE：

需要變更為限制會話模式再進行修改：