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

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

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

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

CDBのコンテナについて
コンテナは、マルチテナント・アーキテクチャ内のデータまたはメタデータの論理集合です。
マルチテナント・アーキテクチャのユーザー・インタフェースについて
CDBおよび非CDBのどちらにも同じ管理ツールを使用できます。

親トピック: マルチテナント・アーキテクチャの紹介

CDBのコンテナについて

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

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

図1-1 CDB内のコンテナ

「図1-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では、オブジェクトの追加や変更はできません。

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

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

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

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

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

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

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

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

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

CDB管理者はCDB自体を管理します。
アプリケーション・コンテナ管理者は、アプリケーションのインストールおよびアップグレードも含めてsaas_sales_acコンテナを管理します。
アプリケーションPDB管理者は、cust1_pdbおよびcust2_pdbという、saas_sales_acコンテナ内の2つのPDBを管理します。
PDB管理者はhrpdbを管理します。

関連項目:

「マルチテナント環境の構成と管理の概要」

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

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

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

表1-1 マルチテナント環境のツール

インタフェース	説明	関連項目
コマンドライン・アクセス用のSQL*PlusおよびSQL Developer	SQL*Plusは、Oracle Databaseとともにインストールされる対話型のバッチ問合せツールです。	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 Enterprise Manager Database Express (EM Express)	EM Expressは、Oracle Databaseに組み込まれたWebベースの管理製品です。EM ExpressではPDBをプロビジョニングおよび管理でき、次の操作を行うことができます。 PDBの作成および削除 PDBの接続および切断 PDBのクローニング PDBのリソース制限の設定	EM Expressを使用してCDBとPDBを管理する方法についてさらに学習するには、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください
Oracle Database Configuration Assistant(DBCA)	DBCAは、CDBの作成および複製が可能なグラフィカル・ユーザー・インタフェースを備えたユーティリティです。また、PDBを作成、再配置、クローニング、接続および切断することもできます。	DBCAの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Database管理者ガイド』を参照してください

関連項目:

データベース管理者用のツールの詳細は、『Oracle Database概要』を参照してください

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

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

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

非CDBアーキテクチャの課題
大企業では、使用するデータベースが数百または数千にのぼることがあります。多くの場合、これらのデータベースは、多数の物理サーバー上の様々なプラットフォームで実行されます。
マルチテナント・アーキテクチャのデータベース統合に対する利点
データベース統合とは、複数のデータベースから1台のコンピュータ上の1つのデータベースにデータを統合するプロセスです。Oracleマルチテナント・オプションでは、既存のスキーマまたはアプリケーションを変更することなくデータおよびコードを統合できます。
マルチテナント・アーキテクチャの管理性に対する利点
マルチテナント・アーキテクチャのマルチテナント・アーキテクチャには、データベース統合の他にも複数の利点があります。これらの利点は、すべてのディクショナリ・メタデータを1箇所に格納するのではなく、PDB固有のデータおよびメタデータをPDB自体に格納することで得られます。

親トピック: マルチテナント・アーキテクチャの紹介

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

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

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

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

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

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

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

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

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

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

個別のデータベースを使用する場合、オペレーティング・システムのレプリケーションの必要性はなくなりますが、バックグラウンド・プロセス、システムおよびプロセス・メモリーやOracleメタデータは共有されません。データベースを個別に管理する必要があります。
スキーマまたは仮想プライベート・データベース(VPD)にデータを論理的に分割します。

この方法では、技術リソースが効率的に使用されます。複数のスキーマまたはVPDを一括して管理できます。ただし、このモデルは他の方法と比較して機動性が低く、管理、保護および転送に必要な労力が増加します。また、通常、論理モデルには広範囲にわたるアプリケーションの変更が必要となるため、採用はお薦めしません。

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

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

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

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

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

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

図1-5 単一のCDB

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

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

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

コスト削減

ハードウェアおよびデータベース・インフラストラクチャを1つのセットのバックグラウンド・プロセスに統合し、計算リソースおよびメモリー・リソースを効率的に共有することで、ハードウェアおよびメンテナンスのコストを削減できます。たとえば、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つのデータベースをアップグレードする方が簡単です。

関連項目:

「マルチテナント環境の構成と管理の概要」
共通ユーザーについて学習するには、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または非CDBのいずれかです。

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

CDBの作成
CREATE DATABASE ... ENABLE PLUGGABLE DATABASE SQL文で新規のCDBを作成します。
PDBの作成
CREATE PLUGGABLE DATABASE SQL文でPDBを作成します。

親トピック: マルチテナント・アーキテクチャの紹介

CDBの作成

CREATE DATABASE ... ENABLE PLUGGABLE DATABASE SQL文で新規のCDBを作成します。

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

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

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

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

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

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

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

関連項目:

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

親トピック: データベース統合の方法

PDBの作成

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

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

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

クローニングによるPDBの作成
PDBを作成する方法として、クローニングと呼ばれる方法があります。
接続によるPDBの作成
切断されたPDBの接続、または非CDBのPDBとしての接続によってPDBを作成できます。
再配置によるPDBの作成
PDBをあるCDBから別のCDBに再配置するには、CREATE PLUGGABLE DATABASE ... RELOCATE文またはDBCAを使用します。
プロキシPDBとしてのPDBの作成
プロキシPDBは、参照先PDBと呼ばれるリモートCDB内の別のPDBへのアクセスを提供します。

関連項目:

「PDBおよびアプリケーション・コンテナの作成および削除」

親トピック: データベース統合の方法

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

PDBを作成する方法として、クローニングと呼ばれる方法があります。

PDB$SEED、アプリケーション・シード、リモートまたはローカルのPDB、あるいは非CDBからPDBをクローニングできます。

シードからのPDBの作成
CREATE PLUGGABLE DATABASE文を使用して、PDBをシードから作成できます。
PDBまたは非CDBのクローニングによるPDBの作成
PDBまたは非CDBをクローニングするには、FROM句とともにCREATE PLUGGABLE DATABASE文を使用します。

親トピック: PDBの作成

シードからのPDBの作成

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

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

シードPDBは次のいずれかです。

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

各CDBにはPDB$SEEDが1つずつあり、これは変更することも削除することもできません。
指定されたアプリケーション・ルート用のユーザー作成PDBである、アプリケーション・シード

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

図1-7 PDB$SEEDからの作成

「図1-7 PDB$SEEDからの作成」の説明

例1-4 PDB$SEEDからのPDBの作成

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

CREATE PLUGGABLE DATABASE hrpdb
 ADMIN USER dba1 IDENTIFIED BY password;

関連項目:

「PDBを最初から作成」

親トピック: クローニングによるPDBの作成

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のクローニングを示します。

図1-8 PDBのクローニング

「図1-8 PDBのクローニング」の説明

Oracle Database 19c以降では、DBCAを使用してリモートPDBをクローニングできます。

例1-5 PDBのクローニング

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

CREATE PLUGGABLE DATABASE salespdb FROM hrpdb;

PDBスナップショットからのクローン
CREATE PLUGGABLE DATABASEコマンドのUSING SNAPSHOT句を指定することで、PDBスナップショットからクローンを作成します。
スナップショット・コピーPDB
スナップショット・コピーPDBは、基礎となるストレージ・システムのコピーに基づいています。スナップショット・コピーPDBを使用すると、テストのために必要な記憶域が削減され、作成時間が大幅に短縮されます。
リフレッシュ可能なクローンPDB
リフレッシュ可能なクローンPDBは、ソースPDBと定期的に同期できる読取り専用クローンです。

関連項目:

親トピック: クローニングによるPDBの作成

PDBスナップショットからのクローン

CREATE PLUGGABLE DATABASEコマンドのUSING SNAPSHOT句を指定することで、PDBスナップショットからクローンを作成します。

SNAPSHOT句の使用によるPDBスナップショットの作成

PDBスナップショットはPDBのPoint-in-Timeコピーです。スナップショットの作成中に、ソースPDBを読取り専用または読取り/書込みでオープンできます。ソースPDBのオープン中に取得されるPDBスナップショットは、ホット・クローンと呼ばれます。PDBスナップショットからクローンを作成できます。これらのクローンPDBは開発やテストで役立ちます。

スナップショットは、CREATE PLUGGABLE DATABASE (またはALTER PLUGGABLE DATABASE)のSNAPSHOT句を使用して手動で作成するか、EVERY interval句を使用して自動的に作成できます。次の文は、pdb1_wed_4_1201というPDBスナップショットを作成します。

ALTER PLUGGABLE DATABASE SNAPSHOT pdb1_wed_4_1201;

ストレージ・システムでスパース・クローンがサポートされる場合、前述のコマンドではスパース・コピーが作成されます。それ以外の場合は、コマンドによって完全なコピーが作成されます。

すべてのPDBスナップショットは、スナップショット名と、スナップショット作成時のSCNおよびタイムスタンプに関連付けられています。

USING SNAPSHOT句の使用によるPDBの作成

PDBスナップショットからのクローンは、完全なスタンドアロンのPDBです。記憶域管理スナップショットに基づいているスナップショット・コピーPDBとは異なり、PDBスナップショットから作成されたクローンをマテリアライズする必要はありません。

PDBスナップショットからクローンを作成するには、CREATE PLUGGABLE DATABASE文のUSING SNAPSHOT句を指定します。たとえば、次の文は、pdb1_wed_4_1201というPDBレベル・スナップショットからpdb1_copyというPDBをクローニングします。

CREATE PLUGGABLE DATABASE pdb1_copy FROM pdb1 
  USING SNAPSHOT pdb1_wed_4_1201;

関連項目:

「PDBスナップショットからのPDBのクローニングについて」
各種エディションおよびサービスでサポートされる機能の詳細は、『Oracle Databaseライセンス情報ユーザー・マニュアル』を参照

親トピック: PDBまたは非CDBのクローニングによるPDBの作成

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

スナップショット・コピーPDBは、基礎となるストレージ・システムのコピーに基づいています。スナップショット・コピーPDBを使用すると、テストのために必要な記憶域が削減され、作成時間が大幅に短縮されます。

ファイル・システムで記憶域スナップショットがサポートされている場合は、CREATE PLUGGABLE DATABASE ... FROM ... SNAPSHOT COPYでは、ソースPDBからPDBがコピーされます。この操作中の読取り/書込みは可能です。スナップショット・コピーPDBファイルには、copy-on-writeテクノロジが使用されます。ディスク上の記憶域がさらに必要になるのは、変更されたブロックのみとなります。ファイル・システムで記憶域スナップショットがサポートされていないか、Oracle Exadataスパース・ファイルが使用されている場合、CLONEDB初期化パラメータはtrueである必要があり、スナップショット・コピーPDBが存在するかぎりソースPDBは読取り専用である必要があります。

スナップショット・コピーPDBは記憶域管理スナップショットに依存しているため、スナップショット・コピーPDBをCDBルートまたはアプリケーション・ルートから切断することはできません。スナップショット・コピーPDBの基となっている記憶域スナップショットは削除できません。

スパース・ファイルを使用するスナップショット・コピーPDBを完全PDBに変換できます。このプロセスは、スナップショット・コピーPDBのマテリアライズと呼ばれます。マテリアライズされたPDBはソースPDBに依存しないため、削除できます。ALTER PLUGGABLE DATABASE MATERIALIZEコマンドを実行することでPDBをマテリアライズします。

ノート:

USING SNAPSHOT句を使用して作成されたPDBとSNAPSHOT COPY句を使用して作成されたPDBのプロパティは異なります。1つのCREATE PLUGGABLE DATABASEコマンドに両方の句を指定することはできません。CREATE PLUGGABLE DATABASE … FROM … USING SNAPSHOT句では、マテリアライズする必要がない完全なスタンドアロンPDBが作成されます。CREATE PLUGGABLE DATABASE … FROM … SNAPSHOT COPY句は、基となる記憶域レベルのスナップショットを削除する場合にマテリアライズする必要があるスパースPDBを作成します。

ノート:

スナップショット・コピーPDBの作成とマテリアライズ

親トピック: PDBまたは非CDBのクローニングによるPDBの作成

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

リフレッシュ可能なクローンPDBは、ソースPDBと定期的に同期できる読取り専用クローンです。

REFRESH MODE句に指定された値に応じて、同期は自動的に、または手動で行われます。たとえば、hrpdb_re_cloneがhrpdbのクローンである場合は、hrpdbによる変更でhrpdb_re_cloneを毎月手動でリフレッシュできます。あるいは、24時間ごとにhrpdb_re_cloneに変更が自動的に伝播されるようにhrpdbを構成できます。

ソースPDBとそのリフレッシュ可能なクローンのロールを切り替えることができます。このスイッチオーバーは、CDB間のロード・バランシングや、ソースPDBに障害が発生した場合に役立ちます。

ノート:

REFRESH MODE句を使用したPDBのクローニング方法を学習するには、「PDBまたは非CDBのクローニングについて」を参照

親トピック: PDBまたは非CDBのクローニングによるPDBの作成

接続によるPDBの作成

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

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

親トピック: PDBの作成

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

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

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

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

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

図1-9 切断されたPDBの接続

「図1-9 切断されたPDBの接続」の説明

例1-6 PDBの接続

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

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

関連項目:

「切断されたPDBの接続」

親トピック: プラグインによるPDBの作成

非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 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 GoldenGateレプリケーションを使用します。

非CDBからPDBにデータをレプリケートします。PDBが非CDBと同じ最新の状態になったら、PDBにスイッチオーバーします。

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

図1-10 非CDBからのPDBの作成

「図1-10 非CDBからのPDBの作成」の説明

関連項目:

「非CDBからPDBを作成するためのオプション」
Oracle GoldenGateの詳細は、『Oracle Database概要』を参照してください

親トピック: プラグインによるPDBの作成

再配置によるPDBの作成

PDBをあるCDBから別のCDBに再配置するには、CREATE PLUGGABLE DATABASE ... RELOCATE文またはDBCAを使用します。

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

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

ターゲットCDB(再配置されたPDBが含まれるCDB)では、データベース・リンクを作成する必要があります。また、ソースPDBはローカルUNDOデータを使用する必要があります。

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

図1-11 PDBの再配置

「図1-11 PDBの再配置」の説明

Oracle Database 19c以降では、サイレント・モードでDBCAを使用してリモートPDBを再クローニングできます。

例1-7 PDBの再配置

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

CREATE PLUGGABLE DATABASE hrpdb FROM hrpdb@lnk_to_source RELOCATE;

関連項目:

親トピック: PDBの作成

プロキシ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の作成方法を示します。

図1-12 プロキシPDBの作成

「図1-12 プロキシPDBの作成」の説明

例1-8 プロキシPDBの作成

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

CREATE PLUGGABLE DATABASE pdb1 AS PROXY FROM pdb1@pdb1_link;

ノート:

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

親トピック: PDBの作成

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

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

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

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

親トピック: マルチテナント・アーキテクチャの紹介