Oracle 12c多租戶特性詳解：PDB 的建立、克隆與維護

PDB 的建立和訪問

在使用 dbca 建庫時，建立資料庫之前，可以儲存一下建立指令碼，分析其具體執行過程。以自定義方式建立名稱為julia的資料庫為例，其主要指令碼 julia.sql 中包含如下指令碼呼叫：

在第一個指令碼 CreateDB.sql 中的末尾部分包含了 Pluggable Database 的變化，這段命令啟用了插接式資料庫，並且初始化了種子 PDB，儲存目錄位於資料庫目錄下的 pdbseed 子目錄。

注意以下語句，種子資料庫的檔案都來自於當前建立的 CDB 資料庫，這些檔案被複制到 PDBSEED 目錄下，這也是建立 PDB 的第一種方式：

當然我們也可以通過模板方式建立 PDBSEED，此時檔案將來自於軟體包中的 pdbseed.tar.gz 壓縮包。相應的，建立指令碼也會有所不同，在模板方式下增加了一個 plugDatabase.sql 指令碼，包含以下主要內容：

指令碼中的 null 目錄最終會被替換為實際目錄，其執行過程就是解壓縮拷貝檔案。

 

在使用自定義方式建立資料庫時，觀察指令碼的執行過程，可以看到種子資料庫的 SYSTEM 和 SYSAUX 表空間初始大小完全一致：

以下查詢顯示當前的 PDB$SEED 種子資料庫以只讀方式開啟：

接下來以這個種子資料庫為模版，建立第一個 PDB，首先設定一個建立目錄：

然後通過如下命令建立 PDB：

查詢一下，顯示當前新建立的資料庫狀態為 Mount：

使用如下語句開啟 PDB：

當開啟 PDB 之後，在日誌中可以看到如下一行：

資料庫在 PDB 開啟後，自動增加一個服務名，註冊到監聽器，然後就可以接受外部的連線請求了。

 

在測試環境中，配置了以下本地網路服務名：

接下來就可以通過如下方式連線到 PDB 資料庫，可以檢視歸屬於 PDB 的資料檔案：

也可以查詢資料庫中的使用者，可以看到 EYGLE 使用者已經被建立：

接下來就可以通過 EYGLE 這個 PDB 資料庫使用者連線訪問這個資料庫，通過如下方式連線：

也可以通過 SYS 使用者連線 PDB，如下使用 EZCONNECT 方式連線到資料庫，查詢 v$datafile 檢視，可以看到當前 PDB 有三個資料檔案，其中 UNDO 表空間共享的全域性資料檔案，其餘兩個為 SYSTEM 和 SYSAUX 表空間檔案：

查詢 v$tempfile 檢視，可以看到 PDB 的獨立臨時檔案：

控制檔案屬於共享範疇，在 PDB 級別查詢可見：

在 DBA 等高階許可權的使用者下，可以通過 ALTER 命令進行會話級別的容器切換，訪問不同容器下的物件：

注意，如果 PDB 的服務名沒有自動新增，可以通過手工配置實現：

在完成測試之後，通過以下命令可以刪除一個 PDB：

由現有 PDB 建立新的 PDB

 

除了通過種子 PDB 建立新的空 PDB 之外，還可以通過一個現有的使用者PDB克隆建立新的 PDB 資料庫。以下詳細記錄一個 PDB 的建立與訪問過程。

 

建立 PDB 的源需要置於只讀模式：

隨後可以開啟這個新建立的 PDB：

檢查資料庫的告警日誌檔案，可以看到，新建立的資料庫，其服務名已經被自動新增到資料庫的服務名配置中：

檢查資料庫監聽器，可以看到 PDB 都已經被監聽器監聽服務：

在12c 的建庫過程中，引入了 Perl 指令碼的呼叫方式，以下是在建立過程中跟蹤到的指令碼呼叫，在資料庫建立的日誌中也可以觀察這種方式：

這個過程完成之後，會在告警日誌檔案中記錄如下資訊：

在 tnsnames.ora 檔案中，增加相應的配置，就可以通過服務名連線資料庫了，以下是兩個 PDB 的本地網路服務名配置：

對於 PDB 的一些更改操作不能在 CDB 級別進行，CDB 級操作會提示不能在 PDB 之外執行，如以下更改 GLOBAL_NAME 的操作：

連線到 PDB 以 RESTRICTED 模式可以進行這些修改：

PDB 的使用與維護

在 PDB 建立完成之後，可以通過 SYSDBA 連線到 PDB，執行維護操作，這和常規的 Non-CDB 資料庫沒有差別，在 PDB 中，只要具備足夠的許可權，可以建立表空間、資料檔案、使用者和資料物件等。

以下通過 SYS 使用者連線到一個名為 ENMO 的 PDB 資料庫：

在 PDB 中執行使用者及表空間建立命令：

執行使用者管理，分配空間、更改預設表空間等：

通過指定使用者連線，可以建立資料物件，以下測試以 SCOTT 使用者指令碼為例建立：

檢視這些資訊：

這些資訊在 CDB 級別的資料庫中是不可見的：

跨資料庫的資料訪問，需要通過 DB Link 進行，如以下測試範例：

種子資料庫的隱藏和保護

 

在資料庫建立的最後過程，可以在告警日誌中觀察到，資料庫最後調整了檔案號的順序，如下日誌顯示，原有2號檔案和4號檔案被刪除，並增加了7號和8號檔案：

檢查底層 file$ 字典表，確實可以發現檔案號2和檔案號4 已經被刪除：

而通過 v$datafile 檢視可以查詢到來自控制檔案的資訊，2號和4號檔案是 PDBSEED 中的兩個檔案：

從資料字典中隱藏了檔案號，就徹底遮蔽了對於種子資料庫的操作，該 PDB 就只能以只讀的方式開啟。

 

在日誌中可以看到，資料庫建立完成之前，pdb$seed 可以被開啟和關閉，但是建立完成，刪除檔案號之後，則被保護了起來：

在資料庫啟動過程中，如嘗試 Offline 的操作，就會收到2號檔案不存在的提示（雖然在 v$datafile 中可以看到這個檔案）：

CDB 與 PDB 的起停管理

 

首先 PDB 的訪問依賴於 CDB，必須啟動 CDB 之後，才能夠對 PDB 進行操作。當 CDB 開啟訪問時，PDB 處於 Mount 狀態，需要進一步的操作開啟 PDB。下圖描述了在 PDB 的模式下，資料庫的啟動過程和步驟：

接下來通過測試來驗證一下這個過程。以下首先啟動 CDB 到 NOMOUNT 狀態，可以看到 v$pdbs 檢視是不能訪問任何 PDB 資訊的：

當 MOUNT 資料庫之後，PDB 隨之被 MOUNT，以下查詢顯示當前資料庫中包含三個 PDB，一個種子庫，兩個使用者庫：

在 CDB 開啟之前，PDB 不能夠執行 Open 操作：

當 CDB 開啟之後，可以看到種子庫被以只讀方式開啟，其他使用者 PDB 資料庫未自動開啟：

可以通過獨立的 PDB 命令，執行資料庫 OPEN 操作，可以通過 ALL 關鍵字同時開啟或關閉所有 PDB：

如果需要在資料庫啟動之後，自動開啟全部的 PDB 資料庫，可以建立一個觸發器，用於在資料庫開啟後自動執行資料庫讀寫開啟：

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/196700/viewspace-2133430/，如需轉載，請註明出處，否則將追究法律責任。