18 マルチテナント・アーキテクチャの紹介

この章では、Oracleマルチテナント・オプションに固有の情報について説明します。

次のトピックが含まれています:

• マルチテナント・アーキテクチャについて

• マルチテナント・アーキテクチャの利点

• データベース統合の方法

• マルチテナント環境のドキュメント・ロードマップ

マルチテナント・アーキテクチャについて

マルチテナント・アーキテクチャを使用すると、Oracle Databaseをマルチテナント・コンテナ・データベース(CDB)として機能させることができます。

CDBは、顧客が作成した0以上のプラガブル・データベース(PDB)を含みます。PDBは、Oracle Netクライアントに非CDBとして表示されるスキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトの移植可能な集合です。Oracle Database 12cまでのOracle Databaseはすべて非CDBでした。

ビデオ:

Oracle Database 12c: Tom Kyteによるマルチテナント環境の概要説明

CDBのコンテナについて

コンテナは、マルチテナント・アーキテクチャ内のデータまたはメタデータの論理集合です。

次の図は、CDBで使用可能なコンテナを示しています。

図18-1 CDB内のコンテナ

「図18-1 CDB内のコンテナ」の説明

CDBごとに、次のコンテナがあります。

• 1つのみのCDBルート・コンテナ(単純にルートとも呼ばれる)

  CDBルートは、スキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトの集合で、すべてのPDBが属しています(「CDB内のコンテナの概要」を参照)。ルートには、Oracle提供のメタデータおよび共通ユーザーが格納されます。メタデータの例として、Oracle提供のPL/SQLパッケージのソース・コードがあります(「CDBのデータ・ディクショナリ・アーキテクチャ」を参照)。共通ユーザーとは、すべてのコンテナで認識されるデータベース・ユーザーです(「CDBの共通ユーザー」を参照)。ルート・コンテナには、CDB$ROOTという名前が付いています。

• 1つのみのシステム・コンテナ

  システム・コンテナにはルートCDBおよびCDB内のすべてのPDBが含まれます。このように、システム・コンテナはCDB自体の論理コンテナです。

• 0以上のアプリケーション・コンテナ

  アプリケーション・コンテナは1つのアプリケーション・ルートと、このルートに接続しているPDBで構成されます。システム・コンテナにはCDBルートおよびCDB内のすべてのPDBが含まれますが、アプリケーション・コンテナにはアプリケーション・ルートに接続しているPDBのみが含まれます。アプリケーション・ルートはCDBルートに属しており、他のコンテナには属しません。

• 0以上のユーザー作成PDB

  PDBには特定の機能セットに必要なデータおよびコードが格納されています(「PDB」を参照してください)。たとえば、PDBでは、人事管理または販売アプリケーションなど、特定のアプリケーションをサポートできます。CDBの作成時にはPDBは存在しません。ビジネスの要件に基づいてPDBを追加します。

  PDBはゼロまたは1つのアプリケーション・コンテナに属しています。PDBがアプリケーション・コンテナに属す場合、これはアプリケーションPDBになります。たとえば、cust1_pdbおよびcust2_pdbのアプリケーションPDBがsaas_sales_acアプリケーション・コンテナに属す場合、これらは他のアプリケーション・コンテナには属していません。アプリケーション・シードはユーザー作成のPDBテンプレートとして機能するオプションのアプリケーションPDBで、これによって新規のアプリケーションPDBを迅速に作成できます。

• 1つのシードPDB

  シードPDBは、システム提供のテンプレートで、CDBではこれを使用して新しいPDBを作成できます。シードPDBには、PDB$SEEDの名前が付いています。PDB$SEEDでは、オブジェクトの追加や変更はできません。

例18-1 アプリケーション・コンテナを使用しないCDB

この例は、システム・コンテナ(CDB全体)、CDBルート、シードおよび2つのPDBという5つのコンテナがあるシンプルなCDBを示しています。各PDBには、独自の専用アプリケーションがあります。各PDB管理者はそれぞれのPDBを管理します。共有ユーザーは、1つのCDB全体に1つのIDで存在します。この例では、共有ユーザーSYSは、ルートおよびすべてのPDBを管理できます。物理レベルでは、このCDBには、非CDBと同様に、1つのデータベース・インスタンスと複数のデータベース・ファイルがあります。

図18-2 アプリケーション・コンテナを使用しないCDB

「図18-2 アプリケーション・コンテナを使用しないCDB」の説明

例18-2 アプリケーション・コンテナを使用するCDB

この例では、CDBにsaas_sales_acというアプリケーション・コンテナが含まれます。アプリケーション・コンテナ内で、アプリケーションPDBのcust1_pdbは1人の顧客のアプリケーションをサポートし、アプリケーションPDBのcust2_pdbは別の顧客のアプリケーションをサポートします。CDBにはhrpdbというPDBも含まれており、これはHRアプリケーションをサポートしますが、アプリケーション・コンテナには属していません。

図18-3 アプリケーション・コンテナを使用するCDB

「図18-3 アプリケーション・コンテナを使用するCDB」の説明

この例では、複数のDBAがCDB環境を管理します。

• CDB管理者はCDB自体を管理します。

• アプリケーション・コンテナ管理者は、アプリケーションのインストールおよびアップグレードも含めてsaas_sales_acコンテナを管理します。

• アプリケーションPDB管理者は、cust1_pdbおよびcust2_pdbという、saas_sales_acコンテナ内の2つのPDBを管理します。

• PDB管理者はhrpdbを管理します。

関連項目:

マルチテナント・アーキテクチャの概要は、Oracle Database管理者ガイドを参照してください

マルチテナント・アーキテクチャのユーザー・インタフェースについて

CDBおよび非CDBのどちらにも同じ管理ツールを使用できます。

たとえば、マルチテナント環境で次のツールを使用できます。

• コマンドライン・アクセス用のSQL*Plus

  SQL*Plusユーザーズ・ガイドおよびリファレンスを参照してください。

• Oracle Enterprise Manager Cloud Control (Cloud Control)

  Cloud Controlは、GUIを備えたOracle Databaseの管理ツールです。Cloud Controlでは、Oracle Database 12cのターゲット(PDB、CDBおよび非CDBを含む)をサポートしています。

  Cloud Controlの詳細は、『Oracle Database管理者ガイド』を参照してください。

• Oracle Enterprise Manager Database Express (EM Express)

  EM Expressは、Oracle Databaseに組み込まれたWebベースの管理製品です。EM ExpressではPDBをプロビジョニングおよび管理でき、次の操作を行うことができます。

  • PDBの作成および削除

  • PDBの接続および切断

  • PDBのクローニング

  • PDBのリソース制限の設定

  EM Expressを使用してCDBとPDBを管理する方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

• Oracle Database Configuration Assistant(DBCA)

  DBCAにより、CDBまたは非CDBの作成、およびPDBの作成、接続および切断ができます。DBCAの詳細は、『Oracle Database 2日でデータベース管理者』および『Oracle Database管理者ガイド』を参照してください。

関連項目:

「データベース管理者向けのツール」

マルチテナント・アーキテクチャの利点

マルチテナント・アーキテクチャによって、従来の非CDBアーキテクチャが引き起こす多くの問題が解決されます。

非CDBアーキテクチャの課題

大企業では、使用するデータベースが数百または数千にのぼることがあります。多くの場合、これらのデータベースは、多数の物理サーバー上の様々なプラットフォームで実行されます。

ハードウェア・テクノロジの向上、特にCPU数の増加により、サーバーでは以前より多くのワークロードを処理できるようになりました。1つのデータベースで使用するサーバー・ハードウェアの容量はごく一部です。この方法では、ハードウェアと人事管理の両方が無駄になります。

たとえば、100のサーバーにそれぞれ1つのデータベースがあり、各データベースがハードウェア資源の10%と管理者の時間の10%を使用するとします。DBAのチームは、各データベースのSGA、データベース、データベース・ファイル、アカウント、セキュリティなどを別々に管理する必要がある一方、システム管理者は100台の異なるコンピュータをメンテナンスする必要があります。

この問題を縮小して示すために、図18-4では、それぞれのアプリケーションとサーバーを持つ11のデータベースを表しています。1人の主任DBAが4人のDBAのチームを管理し、各DBAが2つまたは3つのデータベースを担当します。

図18-4 データベース統合前のデータベース環境

「図18-4 データベース統合前のデータベース環境」の説明

一般的な対応策は、次のとおりです。

• 仮想マシン(VM)を使用します。

  このモデルでは、物理サーバーのオペレーティング・インフラストラクチャ(オペレーティング・システムとデータベース)を仮想マシンにレプリケートします。VMは機動的であるものの、技術リソースが非効率的に使用され、個別の管理が必要となります。仮想スプロールは、管理にかかるコストは同様で、既存の物理スプロールに置き換わるものです。

• 各サーバーに複数のデータベースを配置します。

  複数のデータベースによって、オペレーティング・システムのレプリケーションは排除されますが、バックグラウンド・プロセス、システムおよびプロセス・メモリー、またはOracleメタデータは共有されません。データベースは個別に管理する必要があります。

• データを論理的に複数のスキーマまたは仮想プライベート・データベース(VPD)に分割します。

  この方法では、技術的リソースが効率よく使用されます。複数のスキーマまたはVPDを1つにまとめて管理できます。ただし、このモデルは他に比べて機動性が低く、管理、保護および移植により多くの労力を必要とします。また、この論理的なモデルでは、一般にアプリケーションの大規模な変更が必要であり、それが採用の妨げになっています。

マルチテナント・アーキテクチャのデータベース統合に対する利点

データベース統合とは、複数のデータベースから1台のコンピュータ上の1つのデータベースにデータを統合するプロセスです。Oracleマルチテナント・オプションでは、既存のスキーマまたはアプリケーションを変更することなくデータおよびコードを統合できます。

PDB/非CDB互換性保障とは、Oracle Netで接続しているクライアントから、PDBと非CDBの動作が同じように見えることです。非CDBに対して実行されるアプリケーション定義(たとえば、表とPL/SQLパッケージ)のインストール体系は、PDBに対して同じように実行され、同じ結果が生成されます。また、アプリケーション定義を格納するPDBに接続するクライアント・コードの実行時の動作も、このアプリケーション定義を格納する非CDBに接続されるクライアント・コードの動作と同じです。

完全な非CDBで動作する操作は、完全なCDBの場合と同様に動作します(Oracle Data Guardとデータベースのバックアップおよびリカバリの使用時など)。したがって、非CDBのユーザー、管理者および開発者は、データベースの統合後に実質的に同じ経験をします。

次の図に、図18-4のデータベースを1台のコンピュータに統合した後の状態を示します。DBAチームは5人から3人に縮小され、1人のCDB管理者でCDBを管理する一方、2人のPDB管理者はPDBの管理を分担します。

図18-5 単一のCDB

「図18-5 単一のCDB」の説明

Oracle Database 12cリリース2 (12.2)以降では、アプリケーションPDBを含むアプリケーション・コンテナを作成できます。この方法により、このコンテナの中でアプリケーションを作成および管理できます。CDBへの統合に当てはまる利点の多くは、アプリケーション・コンテナでの統合にも当てはまります。

データベース統合のためにマルチテナント・アーキテクチャを使用すると、次のような利点があります。

• コスト削減

  ハードウェアとデータベース・インフラストラクチャを単一のバックグラウンド・プロセス・セットに統合し、計算リソースとメモリー・リソースを効率的に共有することで、ハードウェアとメンテナンスのコストが削減されます。たとえば、1つのサーバー上の100個のPDBが1つのデータベース・インスタンスを共有します。

• より簡単かつ高速なデータおよびコードの移動

  計画的に、PDBを素早くCDBに接続し、そのPDBをCDBから切断して、別のCDBに接続できます。PDBが使用可能な間にそれをクローニングすることもできます。任意のキャラクタ・セットを使用してPDBに接続して、キャラクタ・セットを変換せずにアクセスすることができます。CDBのキャラクタ・セットがAL32UTF8であれば、異なるデータベース・キャラクタ・セットを使用するPDBが同じCDB内に存在する可能性があります。

• 物理データベースの容易な管理および監視

  CDB管理者は、ホストされているすべてのテナントとCDBルートに対して1つの操作(パッチ適用やRMANバックアップの実行など)を実行することにより、環境を1つの集合体として管理できます。バックアップ計画および障害回復が簡単になります。

• データおよびコードの分離

  1つの物理データベースに統合しても、PDBは非CDBと似た動作をします。たとえば、ユーザーのエラーにより重大なデータが失われた場合、PDB管理者はOracle FlashbackまたはPoint-in-Timeリカバリを使用して、他のPDBに影響を及ぼすことなく、失われたデータを回復できます。

• 管理業務の安全な分担

  共通ユーザーは十分な権限を持つどのコンテナにも接続できますが、ローカル・ユーザーは特定のPDBに制限されます。管理者は業務を次のように分担できます。

  • 管理者は、共通アカウントを使用してCDBまたはアプリケーション・コンテナを管理します。権限は付与先のコンテナに含まれているため、1つのPDBのローカル・ユーザーには、同じCDB内の他のPDBに対する権限はありません。

  • 管理者は、ローカル・アカウントを使用して個々のPDBを管理します。

• 容易なパフォーマンス・チューニング

  複数のデータベースより1つのデータベースのパフォーマンス・メトリックを収集する方が簡単です。100のSGAより1つのSGAのサイズを変更する方が容易です。

• データベース・パッチおよびアップグレードの削減

  100のデータベースよりも1つのデータベースにパッチを適用する方が簡単であり、100のデータベースよりも1つのデータベースをアップグレードする方が簡単です。

関連項目:

• CDBおよびPDBの管理の詳細は、Oracle Database管理者ガイドを参照してください
• 共通ユーザーの詳細は、Oracle Databaseセキュリティ・ガイドを参照してください

マルチテナント・アーキテクチャの管理性に対する利点

マルチテナント・アーキテクチャには、データベース統合の他にも次のような利点があります。これらの利点は、すべてのディクショナリ・メタデータを1箇所に格納するのではなく、PDB固有のデータおよびメタデータをPDB自体に格納することで得られます。

独自のディクショナリ・メタデータを格納することにより、PDBを別個の構成単位として管理しやすくなります。この利点は、CDBにPDBが1つしかなくても得られます。別個に管理されるアプリケーション・コンテナ内にPDBをグループ化することで、管理性がさらに向上します。

CDBでは、データ・ディクショナリ・メタデータは、ルートとPDBの間で分割されています。データ・ディクショナリの分離には、次の利点があります。

• データおよびコードのアップグレードの簡略化

  たとえば、あるデータベース・リリースから別のリリースにCDBをアップグレードするかわりに、PDBを既存のCDBから迅速に切断し、より新しいリリースから新たに作成されたCDBに接続することができます。

• サーバー間の移行の簡略化

  ロード・バランシングの実行やSLAの遵守を目的として、オンプレミスのデータ・センターからクラウドへ、または同じ環境内の2つのサーバー間で、アプリケーション・データベースを移行できます。

• PDB内のデータ破損の防止

  他のPDBに影響を及ぼさずに、SCNまたはPDB固有のリストア・ポイントまでPDBをフラッシュ・バックできます。この機能は非CDB用のフラッシュバック・データベース機能に類似しています。

• アプリケーション固有のデータおよびメタデータを1つの場所でインストール、管理およびアップグレードする機能

  アプリケーション固有のPDBのセットを、アプリケーション・コンテナと呼ばれる単一のコンポーネントとして定義できます。そして1つ以上のアプリケーションをこのコンテナ内で定義できます。各アプリケーションはこのアプリケーション・コンテナ内で共有される、共通メタデータおよびデータの名前付けおよびバージョニングされたセットです。

  たとえば、SaaSベンダーの各顧客は独自のアプリケーションPDBを所有できます。各アプリケーションPDBは、各PDBには異なるデータがある、sales_mltという同一に定義された表が存在する場合があります。PDBはcountries_oltというデータリンク共通オブジェクトを共有し、各PDBで同一のデータを保持できます。アプリケーション管理者としてマスター・アプリケーション定義を管理することで、すべての新規顧客が同じオブジェクトを使用するPDBを取得したり、既存のスキーマへのすべての変更(新規表の追加や、表の定義内の変更など)がアプリケーションを共有するすべてのPDBに適用されるようにできます。

• Oracle Database Resource Managerとの統合

  マルチテナント環境では、同じサーバーで稼働するPDBでのシステム・リソースの競合が問題です。もう1つの問題は、より一貫性があり、予測可能なパフォーマンスを実現するために、リソースの使用が制限されることです。このようなリソースの競合、使用方法および監視の問題に対処するには、Oracle Database Resource Managerを使用します(「CDBでのOracle Resource Managerの概要」を参照)。

関連項目:

• 「CDBのデータ・ディクショナリ・アーキテクチャ」

• アプリケーション・コンテナの管理の詳細は、『Oracle Database管理者ガイド』を参照

データベース統合の方法

存在期間中、データベースはCDBまたは非CDBのいずれかです。非CDBをCDBに、またはCDBを非CDBに変換することはできません。データベースを作成時にCDBとして定義してから、このCDB内にPDBおよびアプリケーション・コンテナを作成する必要があります。

データベース統合の基本的な方法は、次のとおりです。

1. CDBの作成

2. PDBの作成

CDBの作成

CREATE DATABASE ... ENABLE PLUGGABLE DATABASE SQL文で新規のCDBを作成します。ENABLE PLUGGABLE DATABASE句を指定しない場合、新規に作成されたデータベースは非CDBで、PDBを含めることはできません。

ルート・コンテナ(CDB$ROOT)とともに、Oracle Databaseでは自動的にシードPDB (PDB$SEED)が作成されます。次の図に、新規に作成されたCDBを示します。

図18-6 シードPDBが含まれるCDB

「図18-6 シードPDBが含まれるCDB」の説明

例18-3 データベースがCDBであるかどうかの判断

次の簡単な問合せでは、管理ユーザーが現在接続しているデータベースが非CDBか、それともCDB内のコンテナかを確認します。

SQL> SELECT NAME, CDB, CON_ID FROM V$DATABASE;
 
NAME      CDB     CON_ID
--------- --- ----------
CDB1      YES          0

関連項目:

• DBCAまたはCREATE DATABASE文を使用したCDBの作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

• CREATE DATABASE文で指定できる句およびパラメータ値の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

PDBの作成

CREATE PLUGGABLE DATABASE SQL文でPDBを作成します。

次の各項では、PDBの様々な作成方法について説明します。

• クローニングによるPDBの作成

• 切断されたPDBの接続によるPDBの作成

• 再配置によるPDBの作成

• プロキシPDBとしてのPDBの作成

関連項目:

PDBの作成方法の詳細は、Oracle Database管理者ガイドを参照してください

PDBの作成の概要

CDBは、複数のPDB作成方法をサポートしています。

作成されたPDBでは、メタデータとシステム提供オブジェクトへの内部リンクをはじめとする完全なデータ・ディクショナリが、CDBルートに自動的に含まれます。すべてのPDBを単一のルート(CDBルートまたはアプリケーション・ルート)から定義する必要があります。

次の図に、PDB作成のオプションを示します。

図18-7 PDBの作成

「図18-7 PDBの作成」の説明

各PDBにはグローバル一意識別子(GUID)があります。PDB GUIDは、PDBのファイルを格納するディレクトリ(Oracle Managed Filesディレクトリおよび非Oracle Managed Filesディレクトリの両方を含む)の名前を生成するために主に使用されます。

例18-4 異なる手法を使用して作成されたPDB

次の図は、6つのPDBが含まれるサンプルCDBを示しています。

図cncpt381.epsの説明

PDBは次のように作成されました。

• hrpdbは、シードPDBから作成(クローニング)された新しいPDBです。

• salespdbはリモートCDBに存在するPDBのクローンです。

• test1はhrpdbというローカルPDBのクローンです。

• test2は非CDBの接続によって作成されたPDBです。

• test3は切断されたPDBの接続によって作成されたPDBです。

• test4は、別のPDBを参照するPDBである、プロキシPDBです。この場合、プロキシPDBはローカルですが、参照先PDBは別のCDB内にあります。test4で発行する文はすべて、リモートPDBで実行されます。

クローニングによるPDBの作成

PDBを作成する方法として、クローニングと呼ばれる方法があります。PDB$SEED、アプリケーション・シード、リモートまたはローカルのPDB、あるいは非CDBからPDBをクローニングできます。

この項では、次の項目について説明します。

• シードからのPDBの作成

• PDBまたは非CDBのクローニングによるPDBの作成

シードからのPDBの作成

CREATE PLUGGABLE DATABASE文を使用して、PDBをシードから作成できます。

シードは、別のPDBの作成用テンプレートとして機能するPDBです。シードからの作成では、PDBの内容の一部または全部がコピーされ、新しい一意識別子が割り当てられます。

シードPDBは次のどちらかです。

• PDB作成用のシステム提供のテンプレートである、CDBシード(PDB$SEED)

  各CDBにはCDBシードが1つずつあり、これは変更することも削除することもできません。

• 指定されたアプリケーション・ルート用のユーザー作成PDBである、アプリケーション・シード

  アプリケーション・コンテナ内で、CREATE PLUGGABLE DATABASE AS SEED文を使用してアプリケーション・シードを作成してから、それを使用して新規アプリケーションPDBの作成を促進できます。

図18-8 PDB$SEEDからの作成

「図18-8 PDB$SEEDからの作成」の説明

例18-5 PDB$SEEDからのPDBの作成

次のSQL文は、Oracle Managed Filesを使用してCDBシードからhrpdbという名前のPDBを作成します。

CREATE PLUGGABLE DATABASE hrpdb
 ADMIN USER dba1 IDENTIFIED BY password;

関連項目:

この方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

PDBまたは非CDBのクローニングによるPDBの作成

PDBまたは非CDBをクローニングするには、FROM句とともにCREATE PLUGGABLE DATABASE文を使用します。

この方法では、ソースは非CDB、あるいはローカルまたはリモートのCDB内のPDBです。ターゲットはソースからコピーされるPDBです。クローニング操作により、ソースに関連付けられているファイルが新しい場所にコピーされ、PDBを作成するために新しいGUIDが割り当てられます。

この手法は、テストおよび開発用にPDBを短時間で作成する場合に便利です。たとえば、新しいアプリケーションまたは変更されたアプリケーションを、本番PDBにデプロイする前に、クローニングPDBでテストできます。PDBがローカルUNDOモードの場合、ソースPDBを操作中に読取り/書込みモードでオープンできます。これは、ホット・クローニングと呼ばれます。

注意:

リモートCDBからPDBをクローニングする場合は、データベース・リンクを使用する必要があります。

CREATE PLUGGABLE DATABASE文をアプリケーション・ルートで実行する場合、クローニングされたPDBはアプリケーション・コンテナ内に作成されます。この場合、アプリケーション名およびソースPDBのバージョンはアプリケーション・コンテナのアプリケーション名およびバージョンと互換性がある必要があります。

次の図に、ソースおよびターゲットの両方が同じCDB内にある場合のPDBのクローニングを示します。

図18-9 PDBのクローニング

「図18-9 PDBのクローニング」の説明

例18-6 PDBのクローニング

次のSQL文は、hrpdbという名前のプラグインPDBからsalespdbという名前のPDBのクローンを作成します。

CREATE PLUGGABLE DATABASE salespdb FROM hrpdb;

関連項目:

• 「CDBの表領域およびデータベース・ファイルの概要」

• "アプリケーション・メンテナンス"

• 既存のPDBまたは非CDBをクローニングしてPDBを作成にする方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

スナップショット・コピーPDB

基礎になるファイル・システムでストレージ・スナップショットがサポートされている場合、SNAPSHOT COPY句を指定することで、スナップショットを使用できます。スナップショットのコピーにより、ほとんど瞬時にクローンが作成されます。

スナップショット・コピーPDBを作成する際、Oracle Databaseはソース・データ・ファイルの完全なコピーを作成するわけではありません。かわりに、Oracle Databaseでは基礎となるファイル・システムの記憶域レベルのスナップショットを作成し、そのスナップショットを使用してPDBのクローンを作成します。標準のクローンPDBとは異なり、スナップショット・コピーPDBはCDBルートまたはアプリケーション・ルートから切断することができません。

注意:

SNAPSHOT COPY句を使用したPDBのクローニング方法の詳細は、『Oracle Database管理者ガイド』を参照

リフレッシュ可能クローンPDB

リフレッシュ可能クローンPDBは、ソースPDBと定期的に同期できる、ソースPDBの読取り専用クローンです。REFRESH MODE句で指定した値に応じて、同期は自動的に、または手動で行われます。

たとえば、hrpdb_devをhrpdbからクローニングする場合、hrpdbに含まれる変更済データによって毎月、hrpdb_devを手動で更新できます。あるいは、24時間ごとにhrpdbが自動的に変更をhrpdb_devに伝播するように指定することもできます。

注意:

REFRESH MODE句を使用したPDBのクローニング方法の詳細は、Oracle Database管理者ガイドを参照してください

接続によるPDBの作成

切断されたPDBの接続、または非CDBのPDBとしての接続によってPDBを作成できます。

この項では、次の項目について説明します。

• 切断されたPDBの接続によるPDBの作成

• 非CDBからのPDBの作成

切断されたPDBの接続によるPDBの作成

切断されたPDBは、自己完結型のデータ・ファイルのセットと、PDBファイルの場所を指定するXMLメタデータ・ファイルです。切断されたPDBを接続するには、USING句を使用してCREATE PLUGGABLE DATABASE文を使用します。

切断されたPDBを接続する際、次のようなオプションがあります。

• PDBと、そのPDBに関連付けられたファイルが記述されるXMLメタデータ・ファイルを指定します。

• XMLファイルおよびPDBデータ・ファイルの両方が含まれる圧縮されたファイルである、PDBアーカイブ・ファイルを指定します。アーカイブ・ファイルを指定することでPDBを作成し、その結果、XMLファイルおよびデータ・ファイルを別々にコピーすることを回避できます。

次の図に、XMLファイルを使用した切断されたPDBの接続を示します。

図18-10 切断されたPDBの接続

「図18-10 切断されたPDBの接続」の説明

例18-7 PDBの接続

次のSQL文は、指定したXMLファイルに格納されているメタデータに基づき、salespdbという名前のPDBに接続し、切断されたPDBのファイルは新しい場所に移動する必要がないため、NOCOPYを指定します。

CREATE PLUGGABLE DATABASE salespdb USING '/disk1/usr/salespdb.xml' NOCOPY;

関連項目:

この方法を実行する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

非CDBからのPDBの作成

非CDBをPDBに移動できます。

このタスクは、次の方法で実行できます。

• Oracle Database 12cで非CDBに対してDBMS_PDB.DESCRIBEを実行する

  非CDBをトランザクション的に一貫した状態にし、DBMS_PDB.DESCRIBEファンクションを実行して、このデータベースに関するXMLメタデータを生成します。CDBのルートに接続中に、CREATE PLUGGABLE DATABASE文を実行して、既存の非CDBからPDBを作成します。最後に、PDBのデータ・ディクショナリ内の定義をCDB$ROOT内のオブジェクトへの参照に変換するため、PDBにログインしてnoncdb_to_pdb.sqlスクリプトを実行します。

  この方法の実行方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

• トランスポータブル表領域の有無にかかわらず、Oracle Data Pumpを使用する

  Oracle Data Pumpを使用して、非CDBでデータ・セットを定義できます。この非CDBは、現行または以前のOracle Databaseリリース(Oracle Database 10gなど)のどちらにあるものでもかまいません。既存のCDB内に空のPDBを作成し、Oracle Data Pumpを使用して、このPDBにデータ・セットをインポートします。

  Oracle Data Pumpを使用した完全トランスポータブル・エクスポートにより、データベースの完全なコピーの作成に必要なすべてのオブジェクトとデータをエクスポートします。Oracle Data Pumpにより、ダイレクト・パス・アンロードと外部表を使用してオブジェクトをエクスポートしてから、ダイレクト・パスのINSERTと外部表を使用してオブジェクトをインポートします。完全トランスポータブル・ダンプ・ファイルには、表関連オブジェクトばかりでなく、データベース内のすべてのオブジェクトが含まれます。完全トランスポータブル・エクスポートは、Oracle Database 11gリリース2(11.2.0.3)から、Oracle Database 12cへのインポートに使用できます。

  この方法の実行方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

• Oracle GoldenGateレプリケーションを使用する

  非CDBのデータをPDBにレプリケートします。PDBのデータが非CDBにあわせて最新になったら、PDBに切り替えます。

  この方法の実行方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

次の図に、非CDBでDBMS_PDB.DESCRIBEファンクションを実行してから、非CDBファイルを使用してPDBを作成する方法を示します。

図18-11 非CDBからのPDBの作成

「図18-11 非CDBからのPDBの作成」の説明

関連項目:

• 「Oracle GoldenGate」

• PDB作成方法の概要は、『Oracle Database管理者ガイド』を参照してください

再配置によるPDBの作成

PDBをあるCDBから別のCDBに再配置するには、FROM句およびRELOCATEキーワードを使用してCREATE PLUGGABLE DATABASE文を使用します。

この方法には次のメリットがあります。

• 再配置が最小の停止時間内で行われます。

• この手法によって再配置中のPDBは再配置の間は読取り/書込みモードで開かれたままになり、その新しい場所ではPDBがオンラインに戻されます。

宛先CDBで作成されたデータベース・リンクが必要になります。また、ソースPDBはローカルUNDOデータを使用する必要があります(「CDBの表領域およびデータベース・ファイルの概要」を参照)。

次の図は、PDBの再配置を示しています。

図18-12 PDBの再配置

「図18-12 PDBの再配置」の説明

例18-8 PDBの再配置

宛先CDBで発行される次の文によって、hrpdbがソースCDBから宛先CDBに再配置されます。

CREATE PLUGGABLE DATABASE hrpdb FROM hrpdb@lnk_to_source RELOCATE;

関連項目:

PDBの再配置方法の詳細は、Oracle Database管理者ガイドを参照してください

プロキシPDBとしてのPDBの作成

プロキシPDBは、参照先PDBと呼ばれるリモートCDB内の別のPDBへのアクセスを提供します。

プロキシPDBによって複数のソースからデータを集約することができます。プロキシPDBで実行のために発行されたSQL文は、参照先PDB内で実行されます。

一般的なユースケースは、アプリケーション・ルート・レプリカを参照するプロキシPDBです。複数のCDBに同じアプリケーション定義(たとえば、同じ表とPL/SQLパッケージ)がある場合、マスター・アプリケーション・ルートのアプリケーション・コンテナでプロキシPDBを作成できます。プロキシPDBに対する参照先PDBは、異なるCDB内のアプリケーション・ルートです。インストール・スクリプトをマスター・ルートで実行することで、他のCDB内のアプリケーション・ルートがマスター・アプリケーション・ルートのレプリカになります。

プロキシPDBを作成するには、FROM句(リモートCDB内の参照先PDBへのデータベース・リンクを指定する必要があります)およびAS PROXY句とともにCREATE PLUGGABLE DATABASE文を使用します。

注意:

プロキシPDBをCDB$ROOTに直接接続する場合は、CDB$ROOTにプロキシを作成しておく必要があります。アプリケーションPDBのプロキシも、アプリケーション・ルートに接続されている必要があります。

次の図に、リモートCDB内のPDBを参照するプロキシPDBの作成方法を示します。

図18-13 プロキシPDBの作成

「図18-13 プロキシPDBの作成」の説明

例18-9 プロキシPDBの作成

この例では、pdb1というプロキシPDBを作成します。参照先PDBは、データベース・リンクを使用して指定されます。

CREATE PLUGGABLE DATABASE pdb1 AS PROXY FROM pdb1@pdb1_link;

注意:

プロキシPDBとしてのPDBの作成方法の詳細は、『Oracle Database管理者ガイド』を参照

マルチテナント環境のドキュメント・ロードマップ

このトピックに、CDBの理解および使用にとって最も重要なトピックと、該当するドキュメントへの相互参照を示します。

表18-1 マルチテナント・アーキテクチャ・ドキュメントのロードマップ

カテゴリ	トピック	ドキュメント
概念	CDBおよびPDBの概要	Oracle Database概要に関する章および『Oracle Database管理者ガイド』
管理	CDBの作成および構成	Oracle Database管理者ガイド
管理	CDBの管理	Oracle Database管理者ガイド
管理	PDBの作成および構成	Oracle Database管理者ガイド
管理	PDBの管理	Oracle Database管理者ガイド
管理	アプリケーション・コンテナの作成および削除	Oracle Database管理者ガイド
管理	アプリケーション・コンテナの管理	Oracle Database管理者ガイド
パフォーマンス	PDBのトラブルシューティング	Oracle Databaseパフォーマンス・チューニング・ガイド
監視	CDBおよびPDBに関する情報の表示	Oracle Database管理者ガイド
バックアップおよびリカバリ	CDBでのバックアップおよびリカバリの実行	『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』
セキュリティ	CDBでの共通ユーザー、ロールおよび権限の管理	『Oracle Databaseセキュリティ・ガイド』
その他	CDBまたはPDBの管理、Oracle RACのインクルード、リソース管理、データ転送などに関連するその他すべてのタスク	Oracle Database管理者ガイドは、CDB管理用の主要なタスク本位の中級および上級ドキュメントです。このガイドには、様々なCDBのトピックを取り上げている書籍への参照リンクも含まれています。たとえば、『Oracle Databaseユーティリティ』では、Oracle Data Pumpを使用する際のPDB固有の概念およびタスクについて説明しています。