1. 管理者ガイド
  2. マルチテナント管理の概要

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

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

Oracle Multitenant管理者ガイドのOracle Databaseリリース23cでの変更点

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

ノート:

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

親トピック: マルチテナント管理の概要

プラガブル・データベースのハイブリッド読取り専用モード

Oracle Database 23c以降では、プラガブル・データベース(PDB)を構成して、ハイブリッド読取り専用と呼ばれる新しいモードで動作できます。

ハイブリッド読取り専用モードでは、PDBに接続されているユーザーに応じて、PDBを読取り/書込みまたは読取り専用として動作させることができます。共通ユーザーの場合、PDBは読取り専用モードと読取り/書込みモードの両方になります。ローカル・ユーザーの場合、PDBは読取り専用モードに制限されます。

この機能強化に対応するため、次の変更が行われました。

  • ALTER PLUGGABLE DATABASE文には、新しい句HYBRID READ ONLYがあります。

V$CONTAINER_TOPOLOGY動的ビューには、新しい列IS_HYBRID_READ_ONLYがあります。V$PDBS動的ビューの出力も、この機能の影響を受けます。ローカル・ユーザーの場合、 OPEN_MODE列にはREAD ONLYが表示されます。共通ユーザーの場合、この列にはREAD WRITEが表示されます。

ハイブリッド読取り専用モードを使用する利点は、データベース管理者およびアプリケーション管理者が、より高い権限を持つユーザーを含むローカル・ユーザーがPDBの継続的な保守運用を妨害するリスクなしで、オープンPDBの安全なモードでアプリケーションにパッチを適用してメンテナンスできることです。

関連トピック

親トピック: Oracle Multitenant管理者ガイドのOracle Databaseリリース23cでの変更点

PDBのオープン順序の制御

Oracle Database 23c以降では、最も重要なPDBを最初に起動するPDBの起動順序を定義できます。データベース管理者は、各PDBの優先度を定義できます。優先度は、PDBのオープン順序およびアップグレード順序に次のように適用されます。

  • CDBのオープン時のPDB状態のリストア
  • PDBのOPEN ALL文を使用する場合のPDB状態の設定
  • PDBデータベースのアップグレード操作の順序の設定
  • ADGスイッチオーバーまたはフェイルオーバーでのPDBの起動

この機能により、重要なPDBが重要度の低いPDBより前に起動およびオープンし、重要なアプリケーションが使用できるようになるまでの時間を短縮できます。

関連トピック

親トピック: Oracle Multitenant管理者ガイドのOracle Databaseリリース23cでの変更点

Oracle DBCAでのStandard Edition高可用性のサポート

Oracle Database 23c以降、Oracle Database Configuration Assistant (Oracle DBCA)を使用すると、Standard Edition高可用性、単一インスタンスのOracle Databaseを作成できます。このデータベースは、フェイルオーバー機能を備えた単一インスタンス・データベースです。このデータベースは、データベース記憶域ファイルにASMまたはACFSを使用します(NASはサポートされていません)。

Oracle DBCAはデータベースを自動的に登録し、Standard Edition高可用性単一インスタンス・データベース・デプロイメント用に構成するクラスタ・ノードを選択できます。SPFILEおよびパスワード・ファイルは、データベース記憶域の場所に基づいてASMまたはACFSに自動的に作成されます。

関連トピック

親トピック: Oracle Multitenant管理者ガイドのOracle Databaseリリース23cでの変更点

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

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

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

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

  • CDB
    CDBには、ユーザーが作成した1つ以上のPDBおよびアプリケーション・コンテナが格納されています。
  • PDB
    PDBは、アプリケーションに個別のデータベースとして表示されるスキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトのポータブル・コレクションです。
  • アプリケーション・コンテナ
    アプリケーション・コンテナは、オプションのCDB内のユーザー作成のコンテナで、1つ以上のアプリケーションのデータおよびメタデータが格納されます。

親トピック: マルチテナント管理の概要

CDB

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

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

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

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

図1-1の説明が続きます
「図1-1 データベース・インスタンスとCDB」の説明

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

PDB

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

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

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

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

図1-2 CDB内のPDB

図1-2の説明が続きます。
「図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およびアプリケーション・コンテナはこれに属します。

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

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

アプリケーション・コンテナは、オプションの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の説明が続きます
「図1-3 SaaSのユースケース」の説明

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

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

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

  • データを1つのCDBに統合する利点
    データベース統合とは、別個のホスト上の複数のデータベースから1つのホスト上の1つのCDBにデータを統合するプロセスです。マルチテナント・アーキテクチャでは、既存のスキーマまたはアプリケーションを変更することなくデータおよびコードを統合できます。
  • マルチテナント・アーキテクチャの管理性に対する利点
    マルチテナント・アーキテクチャでは、PDB自体に固有のデータおよびメタデータを格納することによって、管理性が向上します。

親トピック: マルチテナント管理の概要

データを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をアップグレードする方が簡単です。

関連項目:

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

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

マルチテナント・アーキテクチャでは、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は共有リソースで競合します。リソースの競合、使用方法および監視の問題に対処するには、リソース・マネージャを使用します。

関連項目:

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

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

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

親トピック: マルチテナント管理の概要

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

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

親トピック: マルチテナント管理の概要

CDBの共通性について

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

  • 共通性の原則
    CDBでは、ある現象はシステム・コンテナ(CDB自体)内または特定のアプリケーション・コンテナ内のいずれにも共通します。
  • CDBのネームスペース
    CDBでは、すべてのオブジェクトのネームスペースはそのオブジェクトのコンテナをスコープとしています。

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

共通性の原則

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

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

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

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

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

  • 共通ユーザーのみが共通現象の存在を変更できます。

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

親トピック: CDBの共通性について

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セキュリティ・ガイドを参照してください

親トピック: CDBの共通性について

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

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

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

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

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

図1-4 HRスキーマ

図1-4の説明が続きます
「図1-4 hrスキーマ」の説明

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

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

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

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

図1-5の説明が続きます
「図1-5 CDBのユーザー・アカウント」の説明

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

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

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

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

システム・コンテナ(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の説明が続きます
「図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にも接続できます。

  • 共通ユーザーの特性
    すべての共通ユーザーは、Oracle提供またはユーザー作成のいずれかです。
  • SYSおよびSYSTEMアカウント
    すべてのOracleデータベースには、管理権限を持つデフォルトの共通ユーザー・アカウントが含まれています。

親トピック: 共通およびローカル・ユーザー・アカウントについて

共通ユーザーの特性

すべての共通ユーザーは、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にも接続できます。

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

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

図1-7の説明が続きます。
「図1-7 CDBのユーザーとスキーマ」の説明

関連項目:

親トピック: 共通ユーザー・アカウント

SYSおよびSYSTEMアカウント

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

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

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

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

関連項目:

親トピック: 共通ユーザー・アカウント

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

ローカル・ユーザーとは、共通ではなく、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セキュリティ・ガイド』を参照してください。

親トピック: 共通およびローカル・ユーザー・アカウントについて

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

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

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

  • CDBの共通ロール
    共通ロールは、CDBルートまたはアプリケーション・ルートのいずれかに存在し、ルート・コンテナ(CDBまたはアプリケーション・コンテナのいずれか)内のあらゆるPDBに適用されます。
  • CDBにおけるローカル・ルール
    ローカル・ロールは、単一のPDBにのみ存在するため、他のPDBのローカル・ロールとは完全に独立しています。

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

CDBの共通ロール

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

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

  • Oracle提供

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

  • ユーザー作成

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

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

CDBのローカル・ロール

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

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

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

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

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

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

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

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

関連項目:

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

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

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

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

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

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

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

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

親トピック: マルチテナント管理の概要

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

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

このマニュアルでは、コンテナをコンテナとして管理する方法(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の説明が続きます。
「図1-8 新しく作成されたCDB」の説明
タスク3   オプションでのアプリケーション・コンテナの作成

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

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

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

図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の説明が続きます
「図1-10 PDBが含まれるCDB」の説明

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

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

図1-11の説明が続きます
「図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-2 マルチテナント環境のツール

ツール 説明 関連項目

SQL*Plus

SQL*Plusとは、CDBおよびPDBを作成、管理および監視できるコマンドライン・ツールです。SQL文およびオラクル社が提供するPL/SQLパッケージを使用して、SQL*Plusでこれらのタスクを実行します。

SQL*Plusユーザーズ・ガイドおよびリファレンス

Oracle Database Configuration Assistant(DBCA)

DBCAは、CDBの作成および複製が可能なグラフィカル・ユーザー・インタフェースを備えたユーティリティです。また、PDBを作成、再配置、クローニング、接続および切断することもできます。

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のサービスの管理」

Oracle Multitenant Self-Service Provisioningアプリケーション

このアプリケーションを使用すると、PDBのセルフサービス・プロビジョニングが可能になります。CDB管理者は、このセルフサービス・アプリケーションへのアクセスを制御し、PDBに対する割当てを管理します。

http://www.oracle.com/goto/multitenant

アプリケーションにアクセスするには、「ダウンロード」タブをクリックして、Oracle Multitenentのダウンロード・セクションでOracle Pluggable Database Self-Service Provisioningアプリケーションを選択します。

コンテナの作成の概要

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

親トピック: マルチテナント管理の概要

CDBの作成

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

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

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

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

関連項目:

親トピック: コンテナの作成の概要

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の作成
    PDBを作成する方法として、クローニングと呼ばれる方法があります。
  • 切断されたPDBの接続によるPDBの作成
    切断されたPDBは、自己完結型のデータ・ファイルのセットと、PDBファイルの場所を指定するXMLメタデータ・ファイルです。切断されたPDBを接続するには、USING句を使用してCREATE PLUGGABLE DATABASE文を使用します。
  • 再配置によるPDBの作成
    PDBをあるCDBから別のCDBに再配置するには、CREATE PLUGGABLE DATABASE ... RELOCATE文またはDBCAを使用します。
  • プロキシPDBとしてのPDBの作成
    プロキシPDBは、参照先PDBと呼ばれるリモートCDB内の別のPDBへのアクセスを提供します。

関連項目:

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

親トピック: コンテナの作成の概要

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

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

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

親トピック: 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-13 PDB$SEEDからの作成

図1-13の説明が続きます。
「図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のクローニングによる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の説明が続きます。
「図1-14 PDBのクローニング」の説明

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

例1-2 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の作成

SNAPSHOT COPY句を使用して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の作成

スナップショット・コピー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

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

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

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

ノート:

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

切断された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の説明が続きます
「図1-15 切断されたPDBの接続」の説明

例1-3 PDBの接続

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

CREATE PLUGGABLE DATABASE salespdb USING '/disk1/usr/salespdb.xml' NOCOPY;
再配置によるPDBの作成

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

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

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

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

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

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

図1-16 PDBの再配置

図1-16の説明が続きます
「図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としての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の説明が続きます
「図1-17 プロキシPDBの作成」の説明

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

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

CREATE PLUGGABLE DATABASE pdb1 AS PROXY FROM pdb1@pdb1_link;

ノート:

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