Oracle 12c:非CDBデータベースをマルチテナント・プラガブル・データベース(PDB)に変換する方法
初出:TriCore、2017年8月29日
Oracle® Database 12cでは、マルチテナント・アーキテクチャを採用することで、1つのコンテナ・データベース(CDB)で複数のプラガブル・データベース(PDB)をホストできます。運用の中には、既存の非CDBデータベースをCDBに接続可能なPDBへ変換したいケースがあります。本記事では、非CDBデータベースをCDBのプラガブル・データベースへ変換する具体的な手順を解説します。
検証環境の構成
今回の検証シナリオでは、サーバー ABC123.xyz.com 上で稼働している非CDBインスタンス noncdb12c を出発点とし、同じマシン上にCDB cdb12c を作成して変換を行います。変換後のCDBデータベースを格納できる十分なディスク容量を確保しておいてください。
- ホストサーバー:ABC123.xyz.com
- 非CDBデータベース:noncdb12c
- Oracleバージョン:12.1.0.2
以下の図は、この検証シナリオの構成を示したものです。
変換手順
ここからは、非CDBデータベースをCDBデータベースへ変換するための手順を段階的に説明します。
ステップ1:クリーンシャットダウンの実行
まず、非CDBデータベースを正常にシャットダウンします。
- 環境を
noncdb12cに設定します。 - 次のコマンドを実行します:
sqlplus / as sysdba - SQLプロンプトで以下を実行します:
shutdown immediate
ステップ2:読み取り専用モードでのデータベース起動
シャットダウン完了後、データベースを排他モードでマウントし、読み取り専用モードでオープンします。
- 環境を
noncdb12cに設定します。 - 次のコマンドを実行します:
sqlplus / as sysdba - SQLプロンプトで以下を実行します:
startup mount exclusive alter database open read only;
ステップ3:PDBマニフェストファイルの生成
非CDBからPDBマニフェストファイル(XML)を生成します。このファイルが、後続のプラグ操作における重要な定義情報となります。
- 環境を
noncdb12cに設定します。 - 次のコマンドを実行します:
sqlplus / as sysdba - SQLプロンプトで以下を実行します:
exec dbms_pdb.describe (pdb_descr_file=>'/tmp/noncdb12c_manifest_file.xml');
ステップ4:非CDBのシャットダウン
ステップ3が完了したら、非CDBデータベースを再度シャットダウンします。
- 環境を
noncdb12cに設定します。 - 次のコマンドを実行します:
sqlplus / as sysdba - SQLプロンプトで以下を実行します:
shutdown immediate
ステップ5:CDBの起動と互換性チェック
CDBがまだ起動していない場合は、以下の手順で起動し、プラグインの互換性を確認します。
- 環境を
cdb12cに設定します。 - 次のコマンドを実行します:
sqlplus / as sysdba - SQLプロンプトで以下を実行します:
startup SET SERVEROUTPUT ON; DECLARE Compatible CONSTANT VARCHAR2(3) :=CASE DBMS_PDB.CHECK_PLUG_COMPATIBILITY (pdb_descr_file => '/tmp/noncdb12c_manifest_file.xml') WHEN TRUE THEN 'YES' ELSE 'NO' END; BEGIN DBMS_OUTPUT.PUT_LINE(compatible); END; /
ステップ6:エラーの確認
CDBの起動完了後、PDB_PLUG_IN_VIOLATIONS ビューを参照してエラーがないか確認します。
- 環境を
cdb12cに設定します。 - 次のコマンドを実行します:
sqlplus / as sysdba - SQLプロンプトで以下を実行します:
SELECT name, cause, type, message, status FROM PDB_PLUG_IN_VIOLATIONS WHERE name='NONCDB12C';
注意:エラーが検出された場合は、次のステップに進む前に必ず解消してください。
ステップ7:CDBへの接続とPDBのプラグイン
マニフェストファイルを使用して、CDBに接続し、PDBとしてプラグインします。
- 環境を
cdb12cに設定します。 - 次のコマンドを実行します:
sqlplus / as sysdba - SQLプロンプトで以下を実行します:
CREATE PLUGGABLE DATABASE pdb12c USING '/tmp/noncdb12c_manifest_file.xml' COPY FILE_NAME_CONVERT = ('<Datafile_Location_for_noncdb>', 'Datafile_Location_for_pdb');
注意:プラグイン時には以下の3つのオプションが利用でき、環境に応じて選択できます。
- COPY:元のnon-CDBのデータファイルはそのまま残し、新しい場所にコピーしてPDBを作成します。元のデータファイルが保持されるため、PDB作成後も元のnon-CDBデータベースは引き続き利用可能です。
- MOVE:non-CDBのデータファイルを新しい場所へ移動してPDBを作成します。この場合、PDB作成後に元のnon-CDBデータベースは使用できなくなります。
- NOCOPY:non-CDBのデータファイルをそのまま同じ場所で使用してPDBを作成します。この場合も、PDB作成後に元のnon-CDBデータベースは使用できなくなります。
COPY または MOVE オプションを使用する場合は、FILE_NAME_CONVERT パラメータでデータファイルの新しい配置先を指定できます。
ステップ8:変換スクリプトの実行
ステップ7が正常に完了したら、PDBコンテナに切り替えて、変換スクリプト $ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql を実行します。このスクリプトにより、非CDB由来のディクショナリ情報がPDB用に適切に変換されます。
- 環境を
cdb12cに設定します。 - 次のコマンドを実行します:
sqlplus / as sysdba - SQLプロンプトで以下を実行します:
alter session set container=pdb12c @$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
ステップ9:PDBの起動と状態確認
PDBを起動し、ステータスが OPEN(読み書き可能) になっていることを確認します。
- 環境を
cdb12cに設定します。 - 次のコマンドを実行します:
sqlplus / as sysdba - SQLプロンプトで以下を実行します:
alter pluggable database open; SELECT name, open_mode FROM v$pdbs;
まとめ:オプション選択のポイント
非CDBデータベースをCDBのプラガブル・データベースへ変換する際は、データベースのサイズに応じて最適なオプションを選択することが重要です。
データベースが非常に大きい場合は NOCOPY オプションが有効です。追加のディスク容量を最小限に抑えられ、変換にかかる時間も短縮できます。ただし、NOCOPYでは元のデータベースファイルが保持されないため、変換前の状態へ戻す必要が生じた場合には、変換作業前に取得したバックアップからのリストアが必要になる点に注意してください。
一方、データベースサイズが小さい場合は COPY オプションの使用を推奨します。元のファイルが常に保持されるため、問題が発生しても旧非CDB環境への切り戻しが容易になります。
ご意見やご質問がある場合は、フィードバックタブからお知らせください。Rackspaceのアプリケーションサービスについて詳しくは、公式サイトをご覧ください。
-
SYSAUX表領域を管理する:Oracleデータベースの監視と対処ガイド
Oracle® 10gでは、PERMANENT、READ WRITE、EXTENT MANAGEMENT LOCAL、SEGMENT SPACE MANAGEMENT AUTOといった必須属性を持つ新しい必須表領域「SYSAUX」が導入されました。本記事では、SYSAUX表領域が成長した際の管理方法について詳しく解説します。 はじめに SYSAUX表領域を活用することで、以下のようなメリットが得られます。 オプション機能のインストール・アンインストールに起因するSYSTEM表領域の断片化を防止できる。 SYSTEM表領域の破損や容量不足のリスクを回避できる。 データベース管理者(DBA)の保
-
MongoDBの実験的なプラガブルストレージエンジンをRocksDBで試してみた
先月開催されたMongoDB Worldにおいて、MongoDBの創業者でありCTOであるEliot Horowitz氏が、バージョン2.8リリースに向けて「プラガブルストレージエンジン」への対応を発表しました。これは非常に注目すべきニュースです。ユーザーは自身のワークロードに最適なストレージエンジンを選択できるようになり、そのAPIはMongoDBの全機能を完全にサポートする計画であるため、現在享受している機能を犠牲にすることなく利用できるからです。さらに興味深いのは、同じレプリカセット内のノードそれぞれが異なるストレージエンジンを使用できるという点です。これにより、用途に応じた多彩な構成が