マルチテナント管理の概要

1 マルチテナント管理の概要

マルチテナント・コンテナ・データベース(CDB)、プラガブル・データベース(PDB)およびアプリケーション・コンテナを作成および管理できます。

1.1 『Oracle Multitenant管理者ガイド』のOracle Databaseリリース20cでの変更点

このリリースの新機能は次のとおりです。

注意:

マルチテナント・コンテナ・データベースは、Oracle Database 20cでサポートされる唯一のアーキテクチャです。ドキュメントが改訂されている間は、従来の用語が残っている可能性があります。ほとんどの場合、「データベース」と「非CDB」は、コンテキストに応じてCDBまたはPDBを指しています。アップグレードなどの一部のコンテキストでは、「非CDB」が以前のリリースの非CDBを指しています。

Oracle Multitenant管理者ガイドの対象範囲の変更

Oracle Database 20c (20.3)以降、このマニュアルでは、コンテナをコンテナとして管理する方法(CDBおよびPDBの作成、それらの起動および停止、コンテナ間操作の実行など)について説明します。Oracle Database管理者ガイドでは、既存のコンテナ内で実行する通常の管理タスク(データベース記憶域、スキーマ・オブジェクト、リソースおよびタスク・スケジュールの管理など)について説明しています。Oracle Databaseセキュリティ・ガイドでは、マルチテナント・データベースを保護する方法について説明しています。
リプレイ・アップグレードを使用した、PDBとしての非CDBの採用

以前のリリースの非CDBをOracle Database 20cのCDB内のPDBとして採用する場合、そのPDBが通常どおりにオープンされるときに、アップグレードが自動的に行われます。リプレイ・アップグレード機能では、必要なCREATE OR REPLACE文が自動的に取得され、変更されたオブジェクトに対する文のみがリプレイされ、データ・ディクショナリが変換されます。リプレイ・メカニズムは、アプリケーションの同期で使用されるものと同じです。

リプレイ・アップグレードを使用して非CDBをPDBとして採用する方法については、Oracle Databaseアップグレード・ガイドを参照してください。
PDBオープン時のリプレイ・アップグレード

PDBのオープン時に、PDBとCDBルートの間でバージョンの不一致があった場合は、自動的にアップグレードされます。PDBオープン時のリプレイ・アップグレードの最適化(デフォルト)により、取得表に格納されている文を再実行することによって、手動のエラー修正を回避できます。このメカニズムは、アプリケーションの同期で使用されるものと同じです。Oracle Database 20cでは、次のシナリオでPDBオープン時のリプレイ・アップグレードが使用されます。
- 以前のリリースのCDBから切断されたPDBを接続する。PDBがオープンされると、データベースでリプレイ・アップグレードが自動的に実行されます。
- 以前のリリースのCDBはOracle Database 20cにアップグレードされたが、CDB内のPDBはアップグレードされていない。OPEN UPGRADEオプションを指定せずにこのPDBをオープンすると、CDBはPDBのリプレイ・アップグレードを自動的に実行します。
PDBのオープン時の互換性チェックおよび切断されたPDBの接続を参照してください。
Oracle Databaseとのネームスペース統合

DbNestでは、PDBについて、オペレーティング・システム・リソースの分離と管理、ファイル・システムの分離、およびセキュアなコンピューティングが提供されます。DbNestが有効にされている場合、データベース・インスタンスのプロビジョニングはネスト内で行われます。ネストは、分離された階層型のコンテナの一種です。データベース・インスタンスのシステム・リソースは、他のインスタンスから分離されます。ファイルおよびディレクトリには、それらが構成されているCDBまたはPDBのみからアクセスできます。

DbNestの詳細は、Oracle Databaseセキュリティ・ガイドを参照してください。
Oracle Cloudでの透過的アプリケーション・コンティニュイティ

計画メンテナンスの間に、データベースによって、セッションは排出期間内に排出する見込みがないと判断される場合があります。そのような場合は、データベースによってアプリケーション・コンティニュイティが起動され、セッションが自動的にフェイルオーバーされます。

PDBの再配置または停止時のサーバー・セッションの排出を参照してください。
CPU_MIN_COUNT初期化パラメータの機能拡張

CPU_MIN_COUNTは、PDBまたはCDBで必要なCPUスレッドの最小数を表します。CPUリソース・マネージャでは、PDBレベルのCPU_MIN_COUNT値を使用して、リソース・プラン内のPDB共有が設定されます。CPUリソース・マネージャにより、各PDBは、CPUに公平にアクセスできるようになり、最小CPUが保証され、最大CPUが強制適用されます。
JOB_QUEUE_PROCESSES初期化パラメータの機能拡張

すべてのコンテナにわたるJOB_QUEUE_PROCESSESのデフォルト値は、4000から、セッション数とCPUスレッド数に応じた自動値に変更されました。
MAX_IDLE_BLOCKER_TIME初期化パラメータの機能拡張

MAX_IDLE_BLOCKER_TIMEには、必要なリソースを保持しているセッションがアイドル状態になってから終了候補になるまでの時間(分数)を設定します。
アプリケーションの同期のための拡張構文

ALTER PLUGGABLE DATABASE APPLICATION ... SYNC文は、複数のアプリケーション名を受け取ります。たとえば、アプリケーションPDBで発行される1つの文で、apexappとordsappを同期したり、ordsapp以外のすべてのアプリケーションを同期できます。

アプリケーションが相互に依存している場合は、機能の正確性のために、単一の文でアプリケーションを同期する必要があります。apexappを1.0から2.0にアップグレードし、ordsappを1.0から2.0にアップグレードしてから、apexappを3.0.にアップグレードするとします。ALTER PLUGGABLE DATABASE APPLICATION apexapp, ordsapp SYNC文は、アップグレードを順番にリプレイします。apexappを2.0にアップグレードし、ordsappを2.0にアップグレードしてから、apexappを3.0.にアップグレードします。個別の文でapexappを同期してからordsappを同期しても、アップグレードの順序は維持されません。

アプリケーションの同期およびアプリケーションPDB内のアプリケーションの同期を参照してください。

1.2 マルチテナント・アーキテクチャ

マルチテナント・アーキテクチャによって、OracleデータベースをCDBにすることができます。

すべてのOracleデータベースは、別のデータベースを格納しているか、別のデータベースに格納できる必要があります。たとえば、CDBにはPDBが格納され、アプリケーション・コンテナにはアプリケーションPDBが格納されます。PDBはCDBまたはアプリケーション・コンテナに格納され、アプリケーション・コンテナはCDBに格納されます。

Oracle Database 20c以降では、マルチテナント・コンテナ・データベースはサポートされる唯一のアーキテクチャです。以前のリリースでは、非コンテナ・データベース(非CDB)がサポートされていました。

1.2.1 CDB

CDBには、ユーザーが作成した1つ以上のPDBおよびアプリケーション・コンテナが格納されています。

物理レベルでは、CDBは、制御ファイル、オンラインREDOログ・ファイルおよびデータ・ファイルの一連のファイルです。データベース・インスタンスは、CDBを構成しているファイルを管理します。

次の図に、CDBおよび関連付けられているデータベース・インスタンスを示します。

図1-1 データベース・インスタンスとCDB

「図1-1 データベース・インスタンスとCDB」の説明

1.2.2 PDB

PDBは、アプリケーションに個別のデータベースとして表示されるスキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトのポータブル・コレクションです。

物理レベルでは、各PDBには、そのPDBのデータを格納する固有の一連のデータ・ファイルがあります。CDBには、それに格納されるPDBのすべてのデータ・ファイル、およびCDB自体のメタデータを格納する一連のシステム・データ・ファイルが含まれています。

PDBを移動またはアーカイブするには、PDBを切断できます。切断されたPDBは、PDBのデータ・ファイルおよびメタデータ・ファイルで構成されています。切断されたPDBは、CDBに接続されるまで使用できません。

次の図に、MYCDBという名前のCDBを示します。

図1-2 CDB内のPDB

「図1-2 CDB内のPDB」の説明

物理的に、インスタンスに関連付けられている一連のデータ・ファイルという意味では、MYCDBはOracleデータベースです。MYCDBには、1つのデータベース・インスタンス(ただし、Oracle Real Application Clustersでは複数のインスタンスが可能)と、1つのデータベース・ファイル・セットがあります。

MYCDBには2つのPDB、hrpdbとsalespdbが含まれます。図1-2に示すように、これらのPDBは、それぞれのアプリケーションにとっては別個の独立したデータベースとして認識されます。アプリケーションは、CDBとPDBのどちらに接続しているのかを認識しません。

CDB自体またはその中のPDBを管理するために、CDBルートに接続できます。ルートは、スキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトの集合で、すべてのPDBおよびアプリケーション・コンテナはこれに属します。

1.2.3 アプリケーション・コンテナ

アプリケーション・コンテナは、オプションのCDB内のユーザー作成のコンテナで、1つ以上のアプリケーションのデータおよびメタデータが格納されます。

このコンテキストでは、アプリケーション(マスター・アプリケーション定義とも呼ばれる)は、アプリケーション・ルートに格納される共通データおよびメタデータの名前付けおよびバージョニングされたセットです。たとえば、アプリケーションには一連のPDBに共通の表、ビュー、ユーザー・アカウント、PL/SQLパッケージの定義を含めることができます。

アプリケーション・コンテナはある意味で、CDB内のアプリケーション固有CDBとして機能します。アプリケーション・コンテナにはCDB自身のように複数のアプリケーションPDBが含まれ、これらのPDBはメタデータおよびデータを共有できます。物理レベルでは、アプリケーション・コンテナには、PDBと同様に固有の一連のデータ・ファイルがあります。

たとえば、SaaSデプロイメントでは、個々が別の顧客用で、アプリケーションのメタデータおよびデータを共有する複数のアプリケーションPDBを使用できます。たとえば次の図では、sales_appはアプリケーション・ルート内のアプリケーション・モデルです。cust1_pdbというアプリケーションPDBには顧客1用の販売データのみが含まれる一方、cust2_pdbというアプリケーションPDBには顧客2用の販売データのみが含まれます。接続、切断、クローニングおよびその他のPDBレベルの操作を、個々の顧客PDBで使用できます。

図1-3 SaaSのユースケース

「図1-3 SaaSのユースケース」の説明

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

1つのCDB内に個々のPDBおよびアプリケーション・コンテナを作成すると、管理性とパフォーマンスの面で利点があります。

1.3.1 データを1つのCDBに統合する利点

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

データを1つのCDBに統合することには、次の利点があります。

コスト削減

ハードウェアおよびデータベース・インフラストラクチャを1つのセットのバックグラウンド・プロセスに統合し、計算リソースおよびメモリー・リソースを効率的に共有することで、ハードウェアおよびメンテナンスのコストを削減できます。たとえば、1つのホスト上の1つのCDB内にある100個のPDBが、1つのデータベース・インスタンスを共有できます。
より簡単かつ高速なデータおよびコードの移動

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

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

1つの物理CDBに統合しても、アプリケーションではPDBを個別のデータベースとして認識します。たとえば、ユーザーのエラーにより単一のPDBの重要なデータが失われた場合、PDB管理者はOracle FlashbackまたはPoint-in-Timeリカバリを使用して、他のPDBに影響を及ぼすことなく、失われたデータを回復できます。
管理業務の安全な分担
共通ユーザー・アカウントは十分な権限を持つどのコンテナにも接続できますが、ローカル・ユーザー・アカウントは特定のPDBに制限されます。管理者は業務を次のように分担できます。
- 管理者は、共通ユーザー・アカウントを使用してCDBまたはアプリケーション・コンテナを管理します。
- PDB管理者は、ローカル・ユーザー・アカウントを使用して、個々のPDBを管理します。権限は付与先のコンテナに含まれているため、1つのPDBのローカル・ユーザーには、同じCDB内の他のPDBに対する権限はありません。
容易なパフォーマンス・チューニング

複数のホスト上の複数のデータベースのパフォーマンス・メトリックを収集するより、1つのホスト上の1つのCDBで収集する方が簡単です。たとえば、100のSGAより1つのSGAのサイズを変更する方が容易です。
データベース・パッチおよびアップグレードの削減

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

関連項目:

マルチテナント管理の概要
共通ユーザー・アカウントの詳細は、Oracle Databaseセキュリティ・ガイドを参照してください

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

マルチテナント・アーキテクチャでは、PDB自体に固有のデータおよびメタデータを格納することによって、管理性が向上します。

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

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

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

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

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

他のPDBに影響を及ぼさずに、SCNまたはPDB固有のリストア・ポイントまでPDBをフラッシュ・バックできます。
アプリケーション固有のデータおよびメタデータを1つの場所でインストール、管理およびアップグレードする機能

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

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

マルチテナント環境では、PDBは共有リソースで競合します。リソースの競合、使用方法および監視の問題に対処するには、リソース・マネージャを使用します。

関連項目:

アプリケーション・コンテナの管理
リソース・マネージャの詳細は、『Oracle Database管理者ガイド』を参照
データ・ディクショナリの分離の詳細は、Oracle Database概要を参照してください

1.4 マルチテナント管理の概要

マルチテナント環境の構成と管理に関する基本的な概念を理解します。

1.4.1 マルチテナント環境でのユーザー、ロールおよびオブジェクト

コンテナ・アーキテクチャを使用すると、データベース管理者は異なるロールを保持することができます。職責の分離で重要となるのは、共通ユーザーとローカル・ユーザー、ロールおよびオブジェクトの区別です。

1.4.1.1 CDBの共通性の概要

CDBまたはアプリケーション・ルートで定義された共通現象は、このルートに接続されたすべてのコンテナで同じになります。

1.4.1.1.1 共通性の原則

CDBでは、ある現象はシステム・コンテナ(CDB自体)内または特定のアプリケーション・コンテナ内のいずれにも共通します。

たとえば、CDB$ROOTへの接続中に共通ユーザー・アカウントを作成した場合、このユーザー・アカウントはCDB内のすべてのPDBおよびアプリケーション・ルートにも共通です。しかし、アプリケーション・ルートへの接続中にアプリケーション共通ユーザー・アカウントを作成した場合、このユーザー・アカウントはこのアプリケーション・コンテナ内のPDBのみに共通です。

CDB$ROOTまたはアプリケーション・ルートのコンテキストにおける共通性の原則は、次のとおりです。

共通現象は、既存および将来のすべてのコンテナで同じになります。

したがって、CDBルートで定義された共通ユーザーはCDBルートに接続しているすべてのPDBで同じIDを持ち、アプリケーション・ルートで定義された共通ユーザーはこのアプリケーション・ルートに接続しているすべてのアプリケーションPDBで同じIDを持ちます。一方、ローカル現象は、厳密に既存の1つのコンテナをスコープとしています。
共通ユーザーのみが共通現象の存在を変更できます。

もっと正確に言えば、CDBルートまたはアプリケーション・ルートのいずれかにログインした共通ユーザーのみが、現在のコンテナに共通のユーザー、ロールまたはオブジェクトの属性を作成、無効化または変更できます。

1.4.1.1.2 CDBのネームスペース

CDBでは、すべてのオブジェクトのネームスペースはそのオブジェクトのコンテナをスコープとしています。

次の原則は、スコープ指定のルールをまとめたものです。

アプリケーションの観点では、PDBは他のPDBとは異なる個別のデータベースです。
ローカル現象は、1つのコンテナの内部で作成され、1つのコンテナに制限されます。

注意:

このトピックでは、「現象」という用語は「ユーザー・アカウント、ロールまたはデータベース・オブジェクト」を意味します。
共通現象は、CDBルートまたはアプリケーション・ルートで定義され、このルートに接続されている(または今後接続される)すべてのPDBに存在します。

前述の原則は、ローカル現象および共通現象に影響します。

ローカル現象

ローカル現象は、コンテナの内部で一意の名前を付ける必要がありますが、CDBのコンテナ全体ではその必要はありません。異なるコンテナに含まれる同じ名前を持つローカル現象は、別個のものです。たとえば、あるPDBのローカル・ユーザーshは、別のPDBのローカル・ユーザーshと競合しません。

CDB$ROOTの共通現象

CDB$ROOTで定義された共通現象は、複数のコンテナに存在し、それらのネームスペースのそれぞれで一意である必要があります。たとえば、CDBルートにはSYSTEMやSYSなどの事前定義された共通ユーザーが含まれています。Oracle Databaseでは、ネームスペースを確実に分離するため、別のコンテナ内でSYSTEMユーザーを作成できません。

ネームスペースを確実に分離するため、CDBルートでユーザーが作成する共通現象の名前は、COMMON_USER_PREFIX初期化パラメータによって指定された値で始まる必要があります。デフォルトの接頭辞はc##またはC##です。ユーザーが作成する他の現象にc##およびC##で始まる名前を付けることはできません。たとえば、hrpdbでc##hrという名前のローカル・ユーザーを作成したり、CDBルートでhrという名前の共通ユーザーを作成することはできません。

アプリケーション共通現象

アプリケーション・コンテナ内で、ローカルおよびアプリケーション共通の現象の名前が競合することはできません。

アプリケーション共通ユーザーおよびロール

CDB共通ユーザーに対する同じ原則がアプリケーション共通ユーザーにも適用されます。違いは、CDB共通ユーザーの場合、共通ユーザー接頭辞のデフォルト値はc##またはC##であるのに対し、アプリケーション・ルートでは、共通ユーザー接頭辞のデフォルト値は空の文字列であることです。

マルチテナント・アーキテクチャでは、アプリケーション・ルートからアプリケーションPDBを作成するか、シングルテナント・アプリケーションをマルチテナント・アプリケーションに変換することが想定されています。
アプリケーション共通オブジェクト

マルチテナント・アーキテクチャでは、アプリケーション・ルートでアプリケーション共通オブジェクトを作成することが想定されています。その後、アプリケーションPDBの内部でローカルにデータを追加します。ただし、Oracle DatabaseではアプリケーションPDB内でのローカル・テーブルの作成がサポートされています。この場合、ローカル表はアプリケーションPDB内のアプリケーション共通オブジェクトと同じネームスペースに存在します。

関連項目:

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

1.4.1.2 共通ユーザー・アカウントおよびローカル・ユーザー・アカウントについて

データベース・ユーザー・アカウントには、パスワードおよび特定のデータベース権限があります。

ユーザー・アカウントおよびスキーマ

各ユーザー・アカウントは、ユーザーと同じ名前が付いた単一のスキーマを所有します。スキーマには、スキーマを所有するユーザーのデータが含まれています。たとえば、hrユーザー・アカウントはhrスキーマを所有し、このスキーマにemployees表などのスキーマ・オブジェクトが含まれます。通常、本番データベースでは、スキーマ所有者は人ではなく、データベース・アプリケーションを表します。

スキーマ内の特定のタイプの各スキーマ・オブジェクトには、一意の名前が付きます。たとえば、hr.employeesはhrスキーマ内のemployees表を指します。次の図に、hrという名前のスキーマ所有者とhrスキーマ内のスキーマ・オブジェクトを示します。

図1-4 HRスキーマ

「図1-4 hrスキーマ」の説明

共通ユーザー・アカウントとローカル・ユーザー・アカウント

ユーザー・アカウントがデータベースを定義するオブジェクトを所有する場合、このユーザー・アカウントは共通です。Oracle提供ではないユーザー・アカウントはローカルまたは共通のいずれかです。CDB共通ユーザーは、CDBルートで作成される共通ユーザーです。アプリケーション共通ユーザーはアプリケーション・ルートで作成されるユーザーで、このアプリケーション・コンテナ内のみで共通です。

次の図は、CDBで使用可能なユーザー・アカウント・タイプを示しています。

図1-5 CDBのユーザー・アカウント

「図1-5 CDBのユーザー・アカウント」の説明

CDB共通ユーザーは、十分な権限を持つCDB内の任意のコンテナに接続できます。対照的に、アプリケーション共通ユーザーは(権限に応じて)そのユーザーが作成されたアプリケーション・ルートまたはこのアプリケーション・ルートに接続しているPDBのみに接続できます。

1.4.1.2.1 共通ユーザー・アカウント

システム・コンテナ(CDB)またはアプリケーション・コンテナのいずれかのコンテキスト内で、共通ユーザーは、ルートとこのコンテナ内の既存と将来のすべてのPDBにおいて同じIDを持つデータベース・ユーザーです。

どの共通ユーザーも、そのコンテナのルートに接続し、ルート内および十分な権限を持つすべてのPDB内で操作を実行できます。一部の管理タスクは、共通ユーザーによって実行される必要があります。例として、PDBの作成やPDBの切断などがあります。

たとえば、SYSTEMはDBA権限を持つCDB共通ユーザーです。したがって、SYSTEMはCDBルートおよびデータベース内の任意のPDBに接続できます。saas_salesアプリケーション・コンテナでsaas_sales_admin共通ユーザーを作成する場合があります。この場合、saas_sales_adminユーザーが接続できるのはsaas_salesアプリケーション・ルートか、saas_salesアプリケーション・コンテナ内のアプリケーションPDBのみです。

すべての共通ユーザーは、Oracle提供またはユーザー作成のいずれかです。Oracle提供の共通ユーザーの例は、SYSやSYSTEMです。すべてのユーザー作成共通ユーザーは、CDB共通ユーザーまたはアプリケーション共通ユーザーのいずれかです。

次の図に、2つのPDB (hrpdbとsalespdb)のユーザーとスキーマの例を示します。SYSとc##dbaは、CDB$ROOT、hrpdbおよびsalespdbにスキーマを持つCDB共通ユーザーです。ローカル・ユーザーhrとrepは、hrpdbに存在します。ローカル・ユーザーhrとrepは、salespdbにも存在します。

図1-6 CDBのユーザーとスキーマ

「図1-6 CDBのユーザーとスキーマ」の説明

共通ユーザーには、次の特徴があります。

共通ユーザーは、CREATE SESSION権限を持つどのコンテナ(CDB$ROOTも含む)にもログインできます。
共通ユーザーは、すべてのコンテナで同じ権限を持つ必要はありません。たとえば、c##dbaユーザーは、hrpdbおよびルートでセッション作成の権限を持っていて、salespdbではセッション作成の権限を持っていないという場合があります。適切な権限を持つ共通ユーザーはコンテナの切替えができるため、ルートの共通ユーザーはPDBを管理できます
アプリケーション共通ユーザーには、その固有アプリケーション・コンテナ外のコンテナでのCREATE SESSION権限がありません。
したがって、アプリケーション共通ユーザーはその固有のアプリケーション・コンテナに制限されます。たとえば、saas_salesアプリケーションで作成されたアプリケーション共通ユーザーは、saas_salesアプリケーション・コンテナ内のアプリケーション・ルートおよびPDBにのみ接続できます。
ユーザーが作成するCDB共通ユーザーの名前は、他のデータベース・ユーザーに対する命名規則に従う必要があります。また、COMMON_USER_PREFIX初期化パラメータによって指定された文字(デフォルトではc##またはC##)で始まる名前を付ける必要があります。Oracle提供の共通ユーザー名とユーザー作成のアプリケーション共通ユーザー名にはこの制限がありません。
ローカル・ユーザー名でc##またはC##の文字で始まる名前はありません。
すべての共通ユーザーには、そのユーザーが作成されたコンテナ(システム・コンテナまたは特定のアプリケーション・コンテナのいずれか)内のすべてのPDBにおいて、一意の名前が付けられます。
CDB共通ユーザーはCDBルートで定義されますが、同じIDを持つどのPDBにも接続できる必要があります。アプリケーション共通ユーザーはアプリケーション・ルートに常駐しますが、同じIDを持つそのコンテナのどのアプリケーションPDBにも接続できます。

1.4.1.2.1.1 共通ユーザーの特性

すべての共通ユーザーは、Oracle提供またはユーザー作成のいずれかです。

共通ユーザー・アカウントには次の特性があります。

共通ユーザーは、CREATE SESSION権限を持つどのコンテナ(CDB$ROOTも含む)にもログインできます。

共通ユーザーは、すべてのコンテナで同じ権限を持つ必要はありません。たとえば、c##dbaユーザーは、hrpdbおよびルートでセッション作成の権限を持っていて、salespdbではセッション作成の権限を持っていないという場合があります。適切な権限を持つ共通ユーザーはコンテナの切替えができるため、ルートの共通ユーザーはPDBを管理できます。
アプリケーション共通ユーザーには、その固有アプリケーション・コンテナ外のコンテナでのCREATE SESSION権限がありません。

したがって、アプリケーション共通ユーザーはその固有のアプリケーション・コンテナに制限されます。たとえば、saas_salesアプリケーションで作成されたアプリケーション共通ユーザーは、saas_salesアプリケーション・コンテナ内のアプリケーション・ルートおよびPDBにのみ接続できます。
ユーザーが作成するCDB共通ユーザーの名前は、他のデータベース・ユーザーに対する命名規則に従う必要があります。また、COMMON_USER_PREFIX初期化パラメータによって指定された文字(デフォルトではc##またはC##)で始まる名前を付ける必要があります。Oracle提供の共通ユーザー名とユーザー作成のアプリケーション共通ユーザー名にはこの制限がありません。

ローカル・ユーザー名でc##またはC##の文字で始まる名前はありません。
すべての共通ユーザーには、そのユーザーが作成されたコンテナ(システム・コンテナまたは特定のアプリケーション・コンテナのいずれか)内のすべてのPDBにおいて、一意の名前が付けられます。

CDB共通ユーザーはCDBルートで定義されますが、同じIDを持つどのPDBにも接続できる必要があります。アプリケーション共通ユーザーはアプリケーション・ルートに常駐しますが、同じIDを持つそのコンテナのどのアプリケーションPDBにも接続できます。

図1-7 CDBのユーザーとスキーマ

「図1-7 CDBのユーザーとスキーマ」の説明

関連項目:

共通ユーザー・アカウントの詳細は、Oracle Databaseセキュリティ・ガイドを参照してください
COMMON_USER_PREFIXの詳細は、Oracle Databaseリファレンスを参照してください

1.4.1.2.1.2 SYSおよびSYSTEMアカウント

すべてのOracleデータベースには、管理権限を持つデフォルトの共通ユーザー・アカウントが含まれています。

管理アカウントは、高度な権限が付与され、データベースの起動と停止、メモリーと記憶域の管理、データベース・ユーザーの作成と管理などのタスクの実行を認可されたDBA専用のアカウントです。

SYS共通ユーザー・アカウントは、データベースが作成されたときに自動的に作成されます。このアカウントでは、すべてのデータベース管理機能を実行できます。SYSスキーマには、データ・ディクショナリの実表とビューが格納されています。これらの実表とビューは、Oracle Databaseの操作にとって重要です。SYSスキーマ内の表はデータベースによってのみ操作され、ユーザーからは決して変更されません。

SYSTEM管理アカウントも、データベースが作成されたときに自動的に作成されます。SYSTEMスキーマには、管理情報を表示する追加の表とビュー、およびOracle Databaseの様々なオプションとツールで使用される内部の表とビューが格納されます。SYSTEMスキーマは、管理ユーザー以外のユーザーが必要とする表の格納には決して使用しないでください。

関連項目:

ユーザーアカウントの詳細は、Oracle Databaseセキュリティ・ガイドを参照してください
SYS、SYSTEMおよびその他の管理アカウントの詳細は、『Oracle Database管理者ガイド』を参照してください。

1.4.1.2.2 ローカル・ユーザー・アカウント

ローカル・ユーザーとは、共通ではなく、1つのPDBでのみ操作が可能なデータベース・ユーザーです。

ローカル・ユーザーには、次の特徴があります。

ローカル・ユーザーは、PDBに固有であり、このPDB内でスキーマを所有できます。

共通ユーザーの特性に示した例では、hrpdbのローカル・ユーザーhrがhrスキーマを所有しています。salespdbでは、ローカル・ユーザーrepがrepスキーマを、ローカル・ユーザーhrがhrスキーマを所有しています。
ローカル・ユーザーは、オープンやクローズなどを含め、PDBを管理できます。

SYSDBA権限を持つ共通ユーザーは、ローカル・ユーザーにSYSDBA権限を付与できます。この場合、権限を付与されたユーザーはローカルのままとなります。
あるPDBのローカル・ユーザーは、別のPDBまたはCDBルートにはログインできません。

たとえば、ローカル・ユーザーhrがhrpdbに接続する場合、hrは、データベース・リンクを使用せずに、salespdbデータベースに常駐するshスキーマのオブジェクトにアクセスすることはできません。同様に、ローカル・ユーザーshがsalespdb PDBに接続する場合、shは、データベース・リンクを使用せずに、hrpdbに存在するhrスキーマのオブジェクトにアクセスすることはできません。
ローカル・ユーザーには、c##またはC##の文字で始まる名前を付けることはできません。
ローカル・ユーザーの名前は、PDB内でのみ一意である必要があります。

ユーザー名とそのユーザーのスキーマが含まれているPDBにより、一意のローカル・ユーザーが決まります。共通ユーザーの特性では、repというローカル・ユーザーおよびスキーマがhrpdbに存在することが示されています。repという完全に独立したローカル・ユーザーとスキーマが、salespdb PDBに存在します。

次の表に、共通ユーザーの特性のCDBに関連するシナリオを示します。各行は、前の行のアクションの後に発生するアクションについて説明します。共通ユーザーSYSTEMが、2つのPDBでローカル・ユーザーを作成します。

表1-1 CDBのローカル・ユーザー

操作	説明
`SQL> CONNECT SYSTEM@hrpdb Enter password: ******** Connected.`	`SYSTEM`が、サービス名`hrpdb`を使用して`hrpdb`コンテナに接続します。
`SQL> CREATE USER rep IDENTIFIED BY password; User created. SQL> GRANT CREATE SESSION TO rep; Grant succeeded.`	`SYSTEM`は、ここでローカル・ユーザー`rep`を作成し、このユーザーにこのPDBでの`CREATE SESSION`権限を付与します。共通ユーザーを作成できるのはルートに接続された共通ユーザーのみであるため、このユーザーはローカルです。
`SQL> CONNECT rep@salespdb Enter password: ******* ERROR: ORA-01017: invalid username/password; logon denied`	`rep`ユーザーは、`hrpdb`に対するローカル・ユーザーで、`salespdb`への接続を試みます。`rep`はPDB `salespdb`に存在しないため、この試みは失敗します。
`SQL> CONNECT SYSTEM@salespdb Enter password: ******** Connected.`	`SYSTEM`は、サービス名`salespdb`を使用して`salespdb`コンテナに接続します。
`SQL> CREATE USER rep IDENTIFIED BY password; User created. SQL> GRANT CREATE SESSION TO rep; Grant succeeded.`	`SYSTEM`は、`salespdb`でローカル・ユーザー`rep`を作成し、このユーザーにこのPDBでの`CREATE SESSION`権限を付与します。ローカル・ユーザー名はそのPDBでのみ一意である必要があるため、`rep`というユーザーは`salespdb`と`hrpdb`の両方に存在できます。
`SQL> CONNECT rep@salespdb Enter password: ******* Connected.`	`rep`ユーザーは、正常に`salespdb`にログインします。

関連項目:

ローカル・ユーザー・アカウントの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

1.4.1.3 CDBの共通ロールおよびローカル・ロールの概要

ユーザー作成のロールは、ローカルまたは共通のいずれかです。共通ロールは、CDB自体または特定のアプリケーション・コンテナのいずれかに共通します。

Oracle提供ロールは、例として事前定義DBAロールのように、すべて共通です。Oracle提供のスクリプトでは、Oracle提供のユーザーおよびロールに付与されるすべての権限またはロールは共通に付与されますが、例外は、システム権限が共通ロールPUBLICに対してローカルに付与される場合です。

1.4.1.3.1 CDBの共通ロール

共通ロールは、CDBルートまたはアプリケーション・ルートのいずれかに存在し、ルート・コンテナ(CDBまたはアプリケーション・コンテナのいずれか)内のあらゆるPDBに適用されます。

共通ロールは、コンテナ間の操作に便利で、共通ユーザーがすべてのPDBでロールを持つことを保証します。すべての共通ユーザーは、次のいずれかのタイプになります。

Oracle提供

DBAやPUBLICなどのOracle提供ロールはすべて、CDBに共通です。
ユーザー作成

共通ロールを作成するには、CDBルートまたはアプリケーション・ルートのいずれか(これによって、ロールが共通となるコンテナが決まります)でCREATE ROLE ... CONTAINER=ALLを実行します。標準の命名規則が適用されます。また、CDB共通ロールには、COMMON_USER_PREFIX初期化パラメータによって指定された文字(デフォルトではc##またはC##)で始まる名前を付ける必要があります。

ロールのスコープは、そのロールが定義されているルートのスコープです。CDB$ROOTでロールを定義すると、そのスコープはCDB全体になります。アプリケーション・ルート内でロールを定義すると、そのスコープはアプリケーション・コンテナになります。

1.4.1.3.2 CDBのローカル・ロール

ローカル・ロールは、単一のPDBにのみ存在するため、他のPDBのローカル・ロールとは完全に独立しています。

ローカル・ロールには、そのロールが存在するコンテナで適用されるロールおよび権限のみを含めることができます。たとえば、hrpdbでローカル・ロールpdbadminを作成した場合、このロールのスコープはこのPDBに制限されます。

同じCDB、または同じアプリケーション・コンテナのPDBには、同じ名前のローカル・ロールが含まれる場合があります。たとえば、ユーザー作成のロールpdbadminは、hrpdbとsalespdbのどちらにも存在する可能性があります。ただし、これらのロールは相互に完全に独立しています。

1.4.1.4 共通オブジェクトとローカル・オブジェクト

共通オブジェクトは、CDBルートまたはアプリケーション・ルートのいずれかで定義されており、メタデータ・リンクまたはオブジェクト・リンクを使用して参照できます。ローカル・オブジェクトは、共通オブジェクトではないすべてのオブジェクトです。

データベースによって提供される共通オブジェクトは、CDB$ROOTで定義されており、変更できません。Oracle Databaseでは、CDB$ROOTでの共通オブジェクトの作成はサポートされていません。

アプリケーション・ルートでは、表、ビュー、PL/SQLおよびJavaプログラム・ユニット、順序などのほとんどのスキーマ・オブジェクトを共通オブジェクトとして作成できます。オブジェクトがアプリケーション・ルートに存在する場合、それはアプリケーション共通オブジェクトと呼ばれます。

ローカル・ユーザーは共通オブジェクトを所有できます。また、共通ユーザーはローカル・オブジェクトを所有できますが、これはオブジェクトがデータリンクまたはメタデータリンクされてなく、なおかつメタデータ・リンクでもデータ・リンクでもない場合のみです。

関連項目:

共通オブジェクトの権限管理の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください

1.4.1.5 CDB管理とPDB管理の業務の分離

一部のデータベース管理者はCDB全体を管理し、他のデータベース管理者は個々のPDBを管理します。

CDB全体を管理するデータベース管理者は共通ユーザーとしてCDBに接続し、CDB全体とルートの属性、およびPDBの一部の属性を管理します。たとえば、これらのCDBのDBAは、PDBの作成、切断、接続および削除を実行できます。また、CDBルートの一時表領域およびデフォルト表領域を指定したり、PDBのオープン・モードを変更することもできます。

DBAは、ローカルPDB管理者として特定のPDBに接続することもできます。PDBのDBAは、PDBがアプリケーションをサポートするために必要なタスクを実行します。たとえば、PDB内の表領域およびスキーマの管理、そのPDBの記憶域パラメータの指定、現在のPDBのオープン・モードの変更、PDBレベルの初期化パラメータの設定などのタスクがあります。

1.4.2 マルチテナント環境のタスクおよびツール

このマニュアルでは、SQL*Plus、SQL Developerなどのコマンドライン・ツールを使用して、コンテナの作成およびコンテナでの操作の実行を行う方法について説明しています。

1.4.2.1 マルチテナント環境のタスク

この項は、マルチテナント環境の管理に必要なタスクについてまとめています。

このマニュアルでは、コンテナをコンテナとして管理する方法(CDBおよびPDBの作成、それらの起動および停止、コンテナ間操作の実行など)について説明します。Oracle Database管理者ガイドでは、既存のコンテナ内で実行する通常の管理タスク(データベース記憶域、スキーマ・オブジェクト、リソースおよびタスク・スケジュールの管理など)について説明しています。

マルチテナント・アーキテクチャの利点で説明されている目標を達成するには、次の一般的なタスクを完了する必要があります。

タスク1 マルチテナント環境のプラン

データベースを作成および構成するには、綿密な計画が必要です。CDBには特別な注意が必要です。たとえば、CDBを計画するときは、次のことを考慮する必要があります。

各CDBに接続するPDBの数
計画しているCDBのサポートに必要なリソース
CDB全体に対してまとめて実行されるか、個別のPDBでローカルに実行されるコンテナ管理ポリシー
アプリケーション・コンテナとアプリケーションPDB、CDBとPDB、またはその両方の組合せで構成されるコンテナ・データベース・トポロジ

CDBの計画の詳細は、CDBの作成の準備を参照してください。

タスク2 1つ以上のCDBの作成

必要な計画を完了すると、Database Configuration Assistant (DBCA)またはCREATE DATABASE ... ENABLE PLUGGABLE DATABASEコマンドを使用して、1つ以上のCDBを作成できます。いずれの場合も、各CDBの構成の詳細を指定する必要があります。

CDBの作成の詳細は、DBCAを使用したCDBの作成およびCREATE DATABASE文を使用したデータベースの作成を参照してください。

CDBは、作成されると、次の図に示すようにルートおよびPDB$SEEDで構成されます。CDBルートにはOracleによって保守されるオブジェクトおよびデータ構造のみが含まれ、PDB$SEEDはクローニングのための汎用的なシード・データベースです。

図1-8 新しく作成されたCDB

「図1-8 新しく作成されたCDB」の説明

タスク3 オプションでのアプリケーション・コンテナの作成

アプリケーション・コンテナは、アプリケーション・ルートとそれに関連付けられたアプリケーションPDBから構成されるCDBのオプション・コンポーネントです。アプリケーション・コンテナには、1つ以上のアプリケーションのデータが格納されています。

次の図は、1つの空のアプリケーション・コンテナがあるCDBを示しています。

図1-9 アプリケーション・コンテナ

「図1-9 アプリケーション・コンテナ」の説明

アプリケーション・コンテナについてを参照してください。

タスク4 PDBの作成、接続および切断

PDBにはユーザー・データが含まれています。CDBの作成後、PDBを作成し、切断されたPDBをそのCDBに接続し、必要な場合はいつでもPDBをそのCDBから切断できます。CDBからPDBを切断して、このPDBを異なるCDBに接続できます。PDBのワークロードをあるサーバーから別のサーバーに移動する必要がある場合など、PDBをあるCDBから別のCDBに移動することがあります。

PDBの作成、PDBの接続およびPDBの切断の詳細は、PDBおよびアプリケーション・コンテナの作成を参照してください。

次の図は、複数のPDBが含まれているCDBを示しています。

図1-10 PDBが含まれるCDB

「図1-10 PDBが含まれるCDB」の説明

図1-11は、PDB、アプリケーション・コンテナおよびアプリケーションPDBが含まれるCDBを示しています。

図1-11 PDB、アプリケーション・コンテナおよびアプリケーションPDBが含まれるCDB

「図1-11 PDB、アプリケーション・コンテナおよびアプリケーションPDBが含まれるCDB」の説明

タスク5 CDBおよびアプリケーション・コンテナの管理および監視

CDBの管理および監視には、CDB全体、CDBルート、およびPDBの一部の属性の管理が含まれます。アプリケーション・コンテナの管理および監視は、CDBの管理および監視と似ていますが、アクションはアプリケーション・ルートとアプリケーション・コンテナに属するアプリケーションPDBにのみ影響します。

類似のタスクおよび異なるタスクの詳細は、「CDBの作成後」を参照してください。また、CDBの管理およびCDBのコンテナの監視も参照してください。

Oracle Resource Managerを使用して、CDB内でホストされているPDB間でリソースを割り当てて管理したり、PDB内のユーザー・プロセス間でリソース使用量を割り当てて管理できます。

Oracle Schedulerを使用して、CDB内のジョブ、および個々のPDB内のジョブをスケジュールすることもできます。Oracle Database管理者ガイドを参照してください。

タスク6 PDBおよびアプリケーションPDBの管理および監視

PDBの管理およびCDB内のコンテナの監視を参照してください。

1.4.2.2 マルチテナント環境のツール

様々なツールを使用して、マルチテナント環境を構成および管理できます。

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

ツール	説明	関連項目
SQL*Plus	SQLPlusとは、CDBおよびPDBを作成、管理および監視できるコマンドライン・ツールです。SQL文およびオラクル社が提供するPL/SQLパッケージを使用して、SQLPlusでこれらのタスクを実行します。	SQL*Plusユーザーズ・ガイドおよびリファレンス
Oracle Database Configuration Assistant(DBCA)	DBCAは、CDBの作成および複製が可能なグラフィカル・ユーザー・インタフェースを備えたユーティリティです。また、PDBを作成、再配置、クローニング、接続および切断することもできます。	Oracle Database 2日でデータベース管理者、Oracle Databaseインストレーション・ガイドおよびDBCAオンライン・ヘルプ
Oracle Enterprise Manager Cloud Control。	Cloud Controlとは、CDBおよびそのPDBの管理および監視に使用できるグラフィカル・ユーザー・インタフェースが含まれたシステム管理ツールです。	Cloud Controlオンライン・ヘルプ
Oracle SQL Developer	Oracle SQL Developerは、CDBの構成、PDBの作成、PDBの接続と切断、PDBの状態の変更、Oracle CloudへのPDBのクローニング、PDBのホット・クローニング/リフレッシュ、アプリケーション・ルート間でのPDBの再配置などを行うことのできるグラフィカル・ユーザー・インタフェースのあるクライアント・アプリケーションです。また、Oracle SQL Developerには、リソース管理、記憶域、セキュリティ、構成およびCDB内のコンテナとプラガブル・データベースに関するパフォーマンス・メトリックのレポートのためのグラフィカル・インタフェースがあります。	Oracle SQL Developerユーザーズ・ガイド
サーバー制御(SRVCTL)ユーティリティ	SRVCTLユーティリティを使用して、PDBのサービスを作成および管理できます。	「PDBのサービスの管理」
EM Express	EM Expressは、グラフィカル・ユーザー・インタフェースを持つ管理および監視ツールであり、Oracle Databaseに同梱されています。これは、CDB、ホストされる個別のPDB、またはその両方のために構成できます。このツールはPDBを管理するために使用することが意図されており、PDBのコンテキストで、アプリケーションDBAとしてアプリケーション開発を管理および監視するために使用します。	Oracle Database 2日でデータベース管理者
Oracle Multitenant Self-Service Provisioningアプリケーション	このアプリケーションを使用すると、PDBのセルフサービス・プロビジョニングが可能になります。CDB管理者は、このセルフサービス・アプリケーションへのアクセスを制御し、PDBに対する割当てを管理します。	`http://www.oracle.com/goto/multitenant` アプリケーションにアクセスするには、「ダウンロード」タブをクリックして、Oracle Multitenentのダウンロード・セクションでOracle Pluggable Database Self-Service Provisioningアプリケーションを選択します。

1.4.3 コンテナの作成の概要

CDBはCREATE DATABASEを使用して作成し、PDBおよびアプリケーション・コンテナはCREATE PLUGGABLE DATABASEを使用して作成します。

1.4.3.1 CDBの作成

CREATE DATABASE文で新規のCDBを作成します。

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

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

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

関連項目:

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

1.4.3.2 PDBまたはアプリケーション・コンテナの作成

CREATE PLUGGABLE DATABASE SQL文でPDBを作成します。AS APPLICATION CONTAINER句を指定すると、アプリケーション・コンテナが作成されます。

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

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

注意:

次のトピックで、「PDB」という用語は、PDB、アプリケーション・コンテナまたはアプリケーションPDBを指しています。

関連項目:

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

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

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

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

1.4.3.2.1.1 シードからの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-13 PDB$SEEDからの作成

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

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

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

CREATE PLUGGABLE DATABASE hrpdb
 ADMIN USER dba1 IDENTIFIED BY password;

関連項目:

「PDBを最初から作成」

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

別のPDBからPDBをクローニングするには、FROM句とともにCREATE PLUGGABLE DATABASE文を使用します。

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

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

注意:

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

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

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

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

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

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

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

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

CREATE PLUGGABLE DATABASE salespdb FROM hrpdb;

関連項目:

1.4.3.2.1.2.1 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ライセンス情報ユーザー・マニュアル』を参照

1.4.3.2.1.2.2 スナップショット・コピー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の作成とマテリアライズ

1.4.3.2.1.2.3 リフレッシュ可能なクローン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のクローニングの概要」を参照してください

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

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

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

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

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

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

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

例1-3 PDBの接続

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

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

関連項目:

「切断されたPDBの接続」

1.4.3.2.3 再配置によるPDBの作成

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

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

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

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

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

図1-16 PDBの再配置

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

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

例1-4 PDBの再配置

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

CREATE PLUGGABLE DATABASE hrpdb FROM hrpdb@lnk_to_source RELOCATE;

関連項目:

「PDBの再配置」

1.4.3.2.4 プロキシ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-17 プロキシPDBの作成

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

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

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

CREATE PLUGGABLE DATABASE pdb1 AS PROXY FROM pdb1@pdb1_link;

注意:

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