Comments
Description
Transcript
日本語ホワイト・ペーパー：Oracle Multitenant
Oracleホワイト・ペーパー 2013年6月 Oracle Multitenant Oracle Multitenant 概要...............................................................................................................................................................1 本書の構造 ..................................................................................................................................................3 詳しい技術説明は不要な場合 ............................................................................................................3 詳しい説明が必要な場合 ....................................................................................................................3 各項の概要 ............................................................................................................................................3 Oracle Multitenantで解決される課題 ....................................................................................................5 統合密度の最大化に向けた取組み ....................................................................................................5 標準化による運用コストの削減 ..................................................................................................5 標準化による運用コストおよび資本コストの削減機会の増加 ............................................. 5 データベースのプロビジョニング ....................................................................................................8 Oracle Databaseソフトウェア・バージョンのパッチ適用とアップグレード ......................... 8 Oracle Multitenantの概要 ........................................................................................................................9 マルチテナント・アーキテクチャの静的側面： 水平方向にパーティション化 されたデータ・ディクショナリとプラグ機能 .............................................................................. 12 究極の論理的存在である表 ............................................................................................................. 12 非CDBアーキテクチャの画一的データ・ディクショナリ ........................................................ 12 マルチテナント・アーキテクチャの水平方向にパーティション化されたデータ・ ディクショナリ .............................................................................................................................. 14 このアプローチの概要 ............................................................................................................... 14 PDBおよびルートの実際の定義 ............................................................................................... 15 このアプローチの内部の概要 ................................................................................................... 16 エンティティとしてのPDB上での操作： アンプラグ/プラグ、クローン、作成、削除 .......... 17 マシン間のアンプラグ/プラグ ....................................................................................................... 17 異なるオペレーティング・システム、チップセット、エンディアンネス間の アンプラグ/プラグ ......................................................................................................................... 18 アンプラグ/プラグによるOracleバージョンのパッチ適用 ....................................................... 19 アンプラグ/プラグによるSLA変更への対応 ................................................................................ 22 PDBのクローニング ......................................................................................................................... 22 フル・コピーを使用したPDBのクローニング ....................................................................... 23 スナップショット・コピーを使用したPDBのクローニング .............................................. 24 アンプラグしたPDBからのクローニング ............................................................................... 25 アンプラグ/プラグの代わりにOracle GoldenGateレプリケーションを使用した リモート・クローニング ........................................................................................................... 25 2013年6月 Oracleホワイト・ペーパー-Oracle Identity Management 11g Release 1 PDBのクローン作成SQL文の構文 ............................................................................................ 25 PDBの作成 .......................................................................................................................................... 26 PDBの作成SQL文の構文 ............................................................................................................ 26 PDBの削除 .......................................................................................................................................... 27 PDBの削除SQL文の構文 ............................................................................................................ 27 PDBの作成、クローン作成、削除、およびアンプラグ/プラグがSQL文であることが 重要な理由....................................................................................................................................... 28 Oracle Data Guardで保護されたCDBに対するPDBのアンプラグ/プラグおよび クローニング ................................................................................................................................... 28 非CDBをPDBとして導入する方法........................................................................................................ 29 12.1の非CDBをPDBとして直接導入する方法 ............................................................................. 29 非CDBのコンテンツの導入 ............................................................................................................. 29 マルチテナント・アーキテクチャの動的側面： Oracleインスタンス、ユーザー、 およびセッション ............................................................................................................................... 31 ユーザー、ロールおよび権限付与の共通性 ................................................................................ 31 ローカル・ユーザーとローカル・ロール .............................................................................. 31 共通ユーザーと共通ロール ....................................................................................................... 31 権限および共通ロールの共通付与 ........................................................................................... 32 ユーザーが作成した共通ユーザーと共通ロール .................................................................. 32 サービスとセッション ..................................................................................................................... 33 確立されたセッションでのセッションのカレント・コンテナの変更 .................................... 33 論理的に仮想化されるSGA ............................................................................................................. 34 データ・ディクショナリ・ビューとパフォーマンス・ビュー ................................................ 36 CDB単位の選択肢とPDB単位の選択肢 ............................................................................................... 39 CDB全体に対してのみできる選択 ................................................................................................. 39 Oracle Databaseソフトウェア・バージョン、およびプラットフォームの指定 ............ 39 spfile、制御ファイル、パスワード・ファイル..................................................................... 39 Oracle Data Guard、RMANバックアップ、REDO、およびUNDO .................................... 39 キャラクタ・セット ................................................................................................................... 40 CDB全体の初期化パラメータとデータベース・プロパティ .............................................. 41 AWRレポート............................................................................................................................... 41 PDBごとに変えることができる選択肢 ......................................................................................... 41 PDBのポイント・イン・タイム・リカバリ ........................................................................... 41 PDBのための非定型のRMANバックアップ............................................................................ 42 Oracleホワイト・ペーパー-Oracle Identity Management 11g Release 1 alter system flush Shared_Pool ............................................................................................... 42 PDBで設定できる初期化パラメータとデータベース・プロパティ .................................. 42 ORA-65040エラー....................................................................................................................... 42 CDB内でのPDB間リソース管理............................................................................................................ 43 12.1のCDBレベルの計画で制御されるコンピューティング・リソース ................................ 43 シェアとキャップ・モデル ............................................................................................................. 44 12.1のCDBレベルの計画によるセッション、CPU、Oracleパラレル・サーバー・ プロセス、およびファイルI/Oの管理方法 ................................................................................ 44 PDBとRACインスタンスのアフィニティゼーション ................................................................. 45 CDB内の単独PDBと非CDBの比較 ........................................................................................................ 47 まとめ ....................................................................................................................................................... 48 付録A： Oracle Databaseドキュメント・ライブラリでのマルチテナント・ アーキテクチャの扱い ....................................................................................................................... 49 Oracle Multitenant 概要 Oracle Database 12c Enterprise Editionの新しいオプションであるOracle Multitenantは、統合、プロ ビジョニング、アップグレードなど、さまざまな作業を簡素化することでITコスト削減を支援します。 それを可能にするのは、コンテナ・データベースに多くのプラガブル・データベースを保持できる 新しいアーキテクチャです。Oracle MultitenantはOracle Real Application ClustersやOracle Active Data Guardなど、他のオプションを完全に補完します。既存のデータベースは、なにも変更するこ と無くプラガブル・データベースとして簡単に導入でき、このアプリケーションの他の層を変更す る必要もありません。デプロイメント・オプションをそのまま実装するだけで、Oracle Multitenant のメリットを享受できます。特に重要なメリットの例を以下に示します。 • 高密度の統合。多くのプラガブル・データベースが1つのコンテナ・データベース内でメモリやバック グラウンド・プロセスを共有します。そのため、古いアーキテクチャを使用する単一のデータベース を稼働させる場合よりも多くのプラガブル・データベースを特定のプラットフォーム上で稼働させら れます。これはスキーマベースの統合によるメリットと同じです。しかし、スキーマベースの統合を 導入するには大きな障壁があり、運用上の問題が継続的に発生することになります。こうした導入の 障壁や運用上の問題は、この新しいアーキテクチャによって排除されます。 • SQLの使用による迅速なプロビジョニングとクローニング。プラガブル・データベースは、1つのコン テナ・データベースからアンプラグして別のコンテナ・データベースにプラグインすることができま す。また、同じコンテナ・データベース内でクローニングすることも、異なるコンテナ・データベー ス間でクローニングすることも可能です。プラガブル・データベースの作成も含め、こうした操作は 新しいSQLコマンドで行われ、わずか数秒で完了します。基盤となるファイル・システムがシン・プ ロビジョニングに対応している場合は、SQLコマンドでキーワードsnapshotを使用するだけで、ほぼ 一瞬で数テラバイトをクローニングできます。 • 高速のパッチ適用とアップグレードを実現する新たなパラダイム。1つのコンテナ・データベースのパッ チ適用にかける時間と労力で、そこに含まれる多数のプラガブル・データベースすべてにパッチを適用で きます。異なるOracle Databaseソフトウェア・バージョンのコンテナ・データベース間でプラガブル・デー タベースをアンプラグ/プラグするだけで、1つのプラガブル・データベースにパッチを適用できます。 • 多数のデータベースの一元管理。既存のデータベースをプラガブル・データベースとして統合する と、管理者は多くのデータベースを1つのデータベースとして管理できます。たとえば、バックアッ プやディザスタ・リカバリといったタスクは、コンテナ・データベース・レベルで実行されます。 • プラガブル・データベース間での動的なリソース管理。 Oracle Database 12cでは、Resource Managerが専用の機能で拡張されるため、コンテナ・データベース内のプラガブル・データベー ス間のリソース競合を即座に制御できます。 このホワイト・ペーパーでは、Oracle Databaseの新しいアーキテクチャ、それに付随する新しい機 能、およびそれらによりもたらされるメリットについて説明します。 2013年6月 1ページ Oracle Multitenant 免責事項 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を 唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテ リアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定 を行う際の判断材料になさらないで下さい。オラクルの製品に関して記載されている機能の開発、 リリース、および時期については、弊社の裁量により決定されます。 2013年6月 2ページ Oracle Multitenant 本書の構造 詳しい技術説明は不要な場合 次の項のみお読みください。 • "Oracle Multitenantで解決される課題"（5 ページの） • "Oracle Multitenantの概要"（9 ページの） • "まとめ"（48 ページの） 次の項にも簡単に目を通しておくことをお薦めします： • "非CDBをPDBとして導入する方法"（29 ページの） • "CDB単位の選択肢とPDB単位の選択肢"（39 ページの） • "CDB内でのPDB間リソース管理"（43 ページの） • "CDB内の単独PDBと非CDBの比較"（47 ページの） 詳しい説明が必要な場合 もちろん、最初から最後までじっくりとお読みいただくことをお薦めします。 各項の概要 "Oracle Multitenantで解決される課題"（5 ページの）では、3つの問題（非常に多数のデータベース を1つのプラットフォームに統合して投資収益率を最大化するための労力、データベースのプロビ ジョニング、非常に多数のデータベースへのOracleバージョンのパッチ適用）について説明します。 続いて、"Oracle Multitenantの概要"（9 ページの）では、新しいアーキテクチャを特徴付ける用語 であるマルチテナント・コンテナ・データベース（略記CDB）およびプラガブル・データベース（略 記PDB）を紹介し、代表的な機能の概要とその機能で課題を解決する方法について簡単に説明します。 次に、"マルチテナント・アーキテクチャの静的側面：水平方向にパーティション化されたデータ・ ディクショナリとプラグ機能"（12 ページの）では、12.1 1より前のOracle Databaseのアーキテクチャ にはどのような課題があるのか、また12.1で導入された新しいアーキテクチャによってどのように根 本原因が取り除かれるのかについて説明します。簡単に言うと、"スーパー・データベース"（コンテ ナ・データベース）に"サブ・データベース"（プラガブル・データベース）を収容できるデータベー ス内仮想化が導入されます。ユーザー・システムにプラガブル・データベースという用語を使用す る理由について説明します。 次に、"エンティティとしてのPDB上での操作：アンプラグ/プラグ、クローン、作成、削除"（17 ペー ジの）では、マルチテナント・アーキテクチャのコンテキストでSQL文によって実装されるこれらの 操作が、なぜOracleバージョンのプロビジョニングおよびパッチ適用の新しいパラダイムになるのか について説明します。 -------------------------------------------------1 各リリースの略称として、Oracle Database 12cには12.1、Oracle Database 11gには11.2、というように使用し ます。 2013年6月 3ページ Oracle Multitenant "非CDBをPDBとして導入する方法"（29 ページの）では、12.1より前のデータベースをPDBとして導 入する方法を簡単に説明します。 続いて、"マルチテナント・アーキテクチャの動的側面：Oracleインスタンス、ユーザー、およびセッ ション"（31 ページの）では、共通ユーザーとローカル・ユーザーとを区別する理由、およびセッ ション（特に、接続するPDBを変えられないセッション）の作成方法について説明します。また、1 つ1つの構造体にそれが属するシステムの識別子をタグ付けすることによって、SGA、REDOログ、 およびUNDO表領域を物理的ではなく論理的に仮想化する方法を説明します。 新しいアーキテクチャについて理解したところで、"CDB単位の選択肢とPDB単位の選択肢"（39 ペー ジの）では、12.1より前のデータベースに認められていた自由がPDBでどの程度維持されるのか、ま た統合の目標を追求する中で手放さざるを得ない自由はほとんどないことについて説明します。 次の"CDB内でのPDB間リソース管理"（43 ページの）では、CDB内におけるPDB間のリソース管理に ついて説明します。 "CDB内の単独PDBと非CDBの比較"（47 ページの）では、単一のアプリケーション・バックエンド をホストすることが目的の場合に、この目的専用のCDB内で単一のPDBを使用する例と、12.1より前 のアーキテクチャを持つデータベースを使用する例とを比較します。単独PDBのほうが劣ることは決 してなく、むしろ複数の利点があることを確認します。 "まとめ"（48 ページの）でこのホワイト・ペーパーを締めくくります。 付録は次の1つです。 • "付録A：Oracle Database ドキュメント・ライブラリでのマルチテナント・アーキテクチャの扱い" （49 ページの）。 2013年6月 4ページ Oracle Multitenant Oracle Multitenantで解決される課題 最近では、かなり大規模な顧客サイト内に、数百台または数千台のデータベースがほぼ同数のマシ ンに散在している状態が一般的になっています。これに関連してコストも増大しているため、大量 のデータベースを1つに統合して、関連コストを削減しようとする取組みが始まっています。これま で数十年にわたり、データベース管理者は必要以上の時間をデータベースのプロビジョニング、非 常に多数のデータベースへのOracleバージョン・パッチの個別適用、バックアップおよびディザス タ・リカバリ体制の計画、設定および管理、各データベースの継続稼働に伴う管理に費やしてきま した。 統合密度の最大化に向けた取組み 標準化は本質的に有益です。理由はごく単純で、理解すべきことが減るからです。そのうえ、特定 の標準に準拠した多数のデータベースは、同じ標準を実装した単一のプラットフォームに統合する ことが可能になります。 標準化による運用コストの削減 非常に多数のデータベースを所有する組織では所有コストが高くつきますが、データベース間にば らつきがあるとコストはさらに高くなります。もっともわかりやすい違いは、ハードウェアおよび オペレーティング・システムの種類、選択したオプション、選択したOracle Databaseソフトウェア・ バージョン（ワンオフ・パッチのもっとも詳細な粒度で識別される）です。定期的なバックアップ の実施方法、ディザスタ・リカバリの対応状況といったその他の違いも、それぞれコストに影響し ます。 多くのユーザーが気付いているとおり、複雑なものを管理するための第一歩は、ハードウェア・プ ラットフォームの数をできる限り減らし、プラットフォーム1つ1つでホストするデータベースの数 をできる限り増やすことです。オペレーティング・システムの仮想化は一見すると、個々のデータ ベースが専用のプラットフォーム上にあったときと同じように各データベースを個別管理できる魅 力的な手段のように思えます。しかし、オペレーティング・システムの仮想化によってデータベー ス間のばらつきを最小化することで実現することは、まさに管理コストの削減です。したがって、 多数のデータベースを少数のマシンに統合するユーザーは、オペレーティング・システムの仮想化 によって解決されるのは自分たちが抱えている問題ではないことに気付いています。そのため、ネ イティブ・オペレーティング・システムを仮想化なしで使用することを選択し、さらにはデプロイ するOracleホーム・インストールをできる限り少なくすることを選択します。つまり、ハードウェア の種類、オペレーティング・システムのバージョンおよびパッチレベル、サポートするOracle Databaseの特定の構成のそれぞれで標準化を実施することを選択します。 標準化による運用コストおよび資本コストの削減機会の増加 データベースごとに独自のSGAとバックグラウンド・プロセス一式を所有するため、データベースを 1つ追加するたびにメモリおよびCPUに対する要件が著しく増加します。そして、Oracle Real Application Clustersが導入されている場合は、当然ながら、何倍にもなります。統合をここまで追求 してきたユーザーは、この事実によって統合密度が制限されることに気付いています。この時点で ユーザーは、重要なメトリックはプラットフォームがサポートできるデータベースの密度ではなく、 むしろプラットフォームがサポートできるアプリケーション・バックエンドの密度であることに気 付きます。 2013年6月 5ページ Oracle Multitenant アプリケーション・バックエンドとは、特定のアプリケーションのための永続性メカニズムをデー タベース内に実装するアーチファクト一式を意味する用語です。すべてのアプリケーションには必 然的に、アプリケーション・バックエンドをインストールするための機械的なスキームが存在しま す。このスキームの構成要素は、SQL*Plusスクリプトだけの場合、SQL*PlusスクリプトとOracle Data Pumpのインポート・ファイルおよびコマンドとの組合せの場合、または適切なSQL文を発行する専 用のクライアント・プログラムの場合があります。しかし、機械的なスキームは必ず存在します。 アーチファクトという用語は、アプリケーション・バックエンドのインストール・スキームによっ てデータベースに対して行われるあらゆる変更の影響を意味するものとして使用します。もっとも わかりやすい例は、DBA_Objetcsにリストされる表、索引、ビュー、PL/SQLパッケージなどのオブ ジェクトです。ただし、一部のアーチファクト（ユーザー、ロール、表領域など）は、この意味で はオブジェクトではありません。権限またはロールをユーザーまたはロールに付与することによる 影響も該当しません。また、アプリケーション・メタデータとして使用されるアプリケーション表 のデータも該当しません。 これまで、アプリケーション・バックエンドは独自の専用データベースに収容されていました。し かし、それぞれのインストール・スキームを順番に実行することで、多数の異なるアプリケーショ ン・バックエンドを同じデータベースにインストールできます。このアプローチは通常スキーマベー スの統合と呼ばれ、本書でもこの用語を使用します 2。ユーザーは、スキーマベースの統合でサポー トされる統合密度（プラットフォーム当たりのアプリケーション・バックエンド数）のほうが、各 アプリケーション・バックエンドを専用のデータベースに収容した場合（以下、専用データベース・ モデルと呼ぶ）に可能な密度よりはるかに高いことを実証しています。統合密度は、必要なデータ ベース・メモリのサイズやサポートする必要があるスループットといったアプリケーション・バッ クエンドのプロパティにより変動します。さらに、データベースの数を極端に減らせば、管理コス トも大幅に削減されます。 ただし、スキーマベースの統合にはよく知られたデメリットがいくつかあります。 • 名前の競合によりスキーマベースの統合ができない場合がある。アプリケーション・バックエン ド全体が1つのスキーマ内に実装されることがあります。そのような場合は、スキーマの名前を自 由に選択できるのが普通で、必要なのはクライアント側の一元化された構成ファイルに指定する だけです。このようなアプリケーション・バックエンドは通常、同じデータベースに難なくイン ストールできます（それでも、以下に説明するような潜在的な問題がいくつかあります）。スキー マベースの統合という用語は、言うまでもなくこのユースケースから生まれました。 他のアプリケーション・バックエンドは複数のスキーマに実装されます。つまり、スキーマの相 互参照があるということであり、したがって設計に採用された特定のスキーマ名への依存性があ ることを意味しています。もちろん、同じスキーマ名を異なるアプリケーション・バックエンド で使用することもできます。しかし、スキーマ名はデータベース全体で一意である必要があるた め、スキーマ名が競合しているアプリケーション・バックエンドは、少なくとも一方の名前を変 更しない限り、同じデータベースにインストールできません。こうした変更は、膨大なコストが かかると見なされるのが普通です。 -------------------------------------------------2 スキーマベースの統合がデータベース内統合の一種であることについては、マルチテナント・アーキテクチャ が実現するPDBベースの統合との比較と併せて後ほど説明します。 2013年6月 6ページ Oracle Multitenant さらに、他の事象の名前もデータベース全体で一意である必要があります。例としては、ロール、 ディレクトリ、エディション、パブリック・シノニム、パブリック・データベース・リンク、表 領域などがあります。アプリケーション・バックエンドを考慮してそれぞれを1つのスキーマに実 装した場合でも、こうした他の事象の名前が競合して同じデータベースにインストールできなく なる可能性があります。 • スキーマベースの統合によりセキュリティが脆弱になる。特定のアプリケーション・バックエンド をインストールする人は、Create User、Alter User、Drop Userなどの強力な権限を持つデータベー ス・ユーザーとして認証する必要があります。そうすると、この人は同じデータベース内の他のア プリケーション・バックエンドをどれでも変更できるようになるため、アプリケーション・バック エンドの機密データを読み取ったり変更したりできてしまいます。さらに、複数のスキーマを使用 して実装する設計が不十分なアプリケーション・バックエンドは、Select Any Table、Delete Any Tableなどのシステム権限に依存している場合があります。このようなケースでは、たとえば、SQL インジェクションに対する脆弱性のために、あるアプリケーション・バックエンドの実行時ユーザー が別のアプリケーション・バックエンドのデータを読み取ったり変更したりできる場合があります。 たとえば、Sys.Utl_Fileに対するExecuteなどの特定の権限をpublicに付与する必要があるアプリ ケーション・バックエンドがあるとします。反対に、別のアプリケーション・バックエンドでは この権限をpublicに付与することを明確に禁止しているとします。このような場合は、これら2つ のアプリケーション・バックエンドを同じデータベースに共存させることができません。 • アプリケーション・バックエンド単位でのポイント・イン・タイム・リカバリが非常に困難であ る。ポイント・イン・タイム・リカバリが必要になるのは、通常、アプリケーション・パッチに よって導入されたアプリケーション・コードにエラーがあり、そのために回復できないほどデー タが破損したとわかった場合です。したがって、誤ったアプリケーション・パッチが適用される 直前までリカバリする必要があるのは単一のアプリケーション・バックエンドであり、データベー ス全体ではありません。運がよければ、表領域のポイント・イン・タイム・リカバリで十分な場 合もあります。しかし、破損したデータが複数の表領域に散在している場合は、それが困難な場 合もあります。相互参照している1つ以上の表を管理者が誤って削除した場合も困難です。 • アプリケーション・バックエンド間のリソース管理が困難である。特定のアプリケーション・バッ クエンドにアクセスするセッションを開始する場合は1つ以上の特定のサービスを使用する、複数 のアプリケーション・バックエンドにはサービスを使用しない、という人が決めた規則に依存し ます。つまり、個々の異なるアプリケーション・バックエンドの区別は管理者しか認識せず、デー タベースはこうした区別を認識しません。 • 単一のアプリケーション・バックエンドにOracleバージョンのパッチを適用できない。1つのアプ リケーション・バックエンドでOracle Databaseソフトウェア・バージョンへのパッチ適用が必要 な場合は、他のアプリケーション・バックエンドのどれにも影響を及ぼさずにパッチ適用するこ とはできません。代替手段としては、すでにパッチが適用されている別のデータベースに、パッ チが必要なアプリケーション・バックエンドをOracle Data Pumpを使用して移動する方法しかあ りません。ただし、XMLスキーマなど、一部の種類のデータベース・アーチファクトはOracle Data Pumpを使用して移動することができません。 • 単一のアプリケーション・バックエンドのクローニングが困難である。Oracle Data Pumpが唯一 のオプションです。 2013年6月 7ページ Oracle Multitenant スキーマベースの統合には重大なデメリットがあるにもかかわらず、多くのユーザーがこの方法を 採用し、実際に投資収益率を大幅に増加させています。理由は言うまでもありませんが、統合密度 の向上による資本支出の削減量と管理対象データベースの削減による運用コストの削減量が、上記 のデメリットに起因するコストを上回ったことにあります。 データベースのプロビジョニング データベース管理者は何年にもわたり、ごく標準的な就業日のかなりの時間を、新規データベース を作成したり、既存データベースのマシン間移行を行ったり、開発、テスト、問題の診断といった さまざまな目的のために既存データベースのなるべく新しいクローンを作成したりすることに費や す必要がありました。本書では、この類いの作業をプロビジョニングという用語で呼びます。 Oracle Databaseソフトウェア・バージョンのパッチ適用とアップグレード プロビジョニングほど頻繁に発生する作業ではありませんが、ワンオフ・パッチ、バンドル・パッ チ、パッチ・セット・アップデート（重要なパッチまたは通常パッチ）やパッチ・セットの既存デー タベースへの適用、およびx.1リリースからx.2リリースへ、またはx.2リリースからx+1.1リリースへ とデータベースをアップグレードする作業はストレスが多く時間もかかります。このような作業を Oracleバージョンのパッチ適用と呼びます。本書ではこの用語を頻繁に使用します。パッチ適用と アップグレードをいちいち区別したり、アプリケーション・バックエンドのバージョンではなく、 実行可能なバイナリやデータベース内のOracleシステムを含めたOracle Databaseソフトウェア・ バージョンを意味していることをその都度明記したりするのはくどくなるためです。 2013年6月 8ページ Oracle Multitenant Oracle Multitenantの概要 Oracle Database 12cは単一の"スーパー・データベース"内に多数の"サブ・データベース"を収容でき る新しいアーキテクチャをサポートしています。ここからは正式な用語を使用します。"スーパー・ データベース"はマルチテナント・コンテナ・データベース（略記CDB）で、"サブ・データベース" はプラガブル・データベース（略記PDB）です。つまり、新しいアーキテクチャでは、単一のCDB の中に多数のPDBを収容できます（12.1では最大252個）。この新しいアーキテクチャをマルチテナ ント・アーキテクチャと呼ぶことにします。 そうなると、今度は旧データベース（Oracle Database 11gまででサポートされていた種類のデータ ベースのみ）を意味する用語が必要になります。これを非CDBと呼び、旧アーキテクチャを非CDB アーキテクチャと呼ぶことにします。 Oracle Database 12c Release 1は新しいマルチテナント・アーキテクチャと古い非CDBアーキテク チャの両方をサポートします。つまり、12.1より前のデータベースは（必然的に非CDBですが）、12.1 の非CDBにアップグレードしてそのまま運用し続けられます。ただし、 選択次第では、12.1の非CDB をPDBとしてCDBに導入することもできます 3。 Oracle Net経由で接続するクライアントから見ると、PDBこそがデータベースです。PDBは非CDBと 完全に互換性があります。以降、このことをPDB/非CDB互換性保証と呼びます 4。つまり、非CDBに 対してエラーなしで実行できたアプリケーション・バックエンドのインストール・スキームは、PDB でもそのままエラーなしで実行でき、同じ結果が得られます。アプリケーション・バックエンドを 保持しているPDBに接続するクライアント・コードの実行時動作は、このアプリケーション・バック エンドを保持している非CDBに接続したクライアント・コードの動作とまったく同じです。これは、 単一のアプリケーション・バックエンドを保持するためにPDBが使用されることを意図したものです。 こうすると、アプリケーション・バックエンドは宣言的な手段で直接PDBに収容されるため、どのアー チファクトがどのアプリケーション・バックエンドに属しているのかをOracleシステム側で明示的に 認識できるのです。これに対し、非CDB内でスキーマベースの統合を使用した場合は、Oracleシステ ムに各種アーチファクトの所属先に関する情報が提供されません。各フォアグラウンド・プロセス が参照できるPDBは同時に1つだけであることがわかります。実際、ごく単純な使用モデルでは、PDB 内に定義されているデータベース・ユーザーはそのPDBのみを参照するセッションしか作成できませ ん。したがって、参照されるアーチファクトも単一のアプリケーション・バックエンドに属するも ののみとなります 5。 PDB/非CDB互換性保証が承認されると、非常に多くの質問にアサーションは回答できます。回答が "yes"でなかった場合は、この原則が尊重されなかったことになります。Oracle Corporationのエンジ ニアが12.1の開発サイクルを通じてテストを実施したところ、Oracle Netを使用して接続するクライ アント・コードではPDBと非CDBを区別できないことが証明されました。次に、いくつかの例を示し ます。 -------------------------------------------------3 詳細は、"非CDBをPDBとして導入する方法"（29ページ）を参照してください。 4 PDB/非CDB互換性保証に関する注意事項は、"ORA-65040エラー"（42ページ）を参照してください。 5 詳細は、"マルチテナント・アーキテクチャの動的側面：Oracleインスタンス、ユーザー、およびセッション" （31ページ）を参照してください。 2013年6月 9ページ Oracle Multitenant • 同じCDB内の2つのPDBのそれぞれでScottというユーザーを使用できますか。はい、2つの非CDB のそれぞれでScottというユーザーを使用できるからです。また、同じCDB内の2つのPDBのそれぞ れで、同じ名前のロール、同じ名前のディレクトリ、同じ名前のエディション、同じ名前のパブ リック・シノニム、同じ名前のパブリック・データベース・リンク、同じ名前の表領域を使用で きます。その他、1つのPDBではSys.Utl_Fileに対するExecute権限をpublicに付与し、別のPDBでは 付与しないということができます。あるPDBでpublicに付与したものはそのPDB内のみで参照され ます。同様に、Any権限は、この権限が付与されたPDB内でのみ実行できます。 つまり、非CDBと同様に、PDBではグローバル名前空間が定義されます。また、非CDBと同様に、 権限の影響も含まれます。 • 2つのPDB間にデータベース・リンクを作成できますか。はい、2つの非CDB間で作成できます。 データベース・リンクはSQL文を実行して作成されます。したがって、PDBでそのSQL文を実行し た結果は、非CDBの場合と同じになる必要があります。また、PDBから非CDB、または非CDBから PDBへのデータベース・リンクも作成できます。 Oracle Databaseソフトウェア・バージョンが異なる場合も、2つの非CDB間と同様にサポートさ れています。 • 2つのPDB間にOracle GoldenGateレプリケーションを設定できますか。はい。それだけでなく、 Oracle Databaseソフトウェア・バージョンが異なるPDBと非CDBの間にも設定できます（これは、 12.1をサポートする最初のOracle GoldenGateバージョンで使用できる機能です 6）。 オペレーティング・システムから見ると、データベースはCDBです。各RACインスタンスがCDB全体 をオープンし、各SGAには、CDBに含まれる各PDBのデータ・ブロックおよび子カーソルなどのライ ブラリ・キャッシュ構造体を含めることができます 7（これは、言うまでもなく、マルチテナント・ アーキテクチャにはOracle Real Application Clustersとの完全な相互運用性があることを間接的に表 現したものです）。 したがって、マルチテナント・アーキテクチャによってデータベース内統合の新しいモデル（PDB ベースの統合）がサポートされることがわかります。 PDBベースの統合モデルでのSGAの移入は、そのままスキーマベースの統合モデルでの移入に当ては めることができます。ここでも、各RACインスタンスが非CDBをオープンし、各SGAには、非CDBに 統合された各アプリケーション・バックエンドのデータ・ブロックやライブラリ・キャッシュ構造 体を含めることができます。したがって、特定のOracle Databaseパッチセット・レベルにあるのは CDBということになります。パッチセット・レベルは、非CDB内のスキーマに継承されるのと同様に、 そこに含まれるPDBに継承されます。同じCDB内の2つのPDBを異なるOracle Databaseパッチセッ ト・レベルにできるかという質問は、同じ非CDBでScottスキーマとBlakeスキーマを異なるOracle Databaseパッチセット・レベルにできるかという質問と同じくらいの意味しかありません。 -------------------------------------------------6 マルチテナント・アーキテクチャでは、発生元であるコンテナの識別子が注釈として各REDOログ・エントリに 付けられるため、エンジニアリング作業が必要でした。詳細は、"Oracle Data Guard、RMANバックアップ、REDO、 およびUNDO"（39ページ）を参照してください。 7 各RACインスタンス内でPDBごとにOpen_Modeを変えられる件については、"論理的に仮想化されるSGA"（34 ページ）で説明します。 2013年6月 10ページ Oracle Multitenant 適切な権限を持つデータベース・ユーザーのパスワードを知っている人は、このユーザーを使用し て、CDBに含まれるすべてのPDBのデータ・ディクショナリ・ビューおよびパフォーマンス・ビュー の情報を表示できるセッションを開始できます 8。言い換えれば、SQLを介して単一のシステム・イ メージを入手できるということであり、したがってOracle SQL DeveloperやOracle Enterprise Managerなどのツールからも入手できるということになります。実際、これらのツールは、マルチ テナント・アーキテクチャによって導入される新しい機能をすべて使用できるように拡張されてい ます。 マルチテナント・アーキテクチャではResource Managerの機能が拡張され、CDBレベルの計画でPDB 間のリソース競合を管理できるようになります。 Oracle Active Data Guardは、Oracle Recovery Manager（Oracle RMAN）の計画バックアップの体制 に従ってCDBレベルで実施されます。ポイント・イン・タイム・リカバリはPDBレベルでサポートさ れます。 最後になりますが、PDBは、あるCDBからアンプラグして別のCDBにプラグインすることができます。 プラガブル・データベースという名前が付けられたのはそのためです。既存のPDBのクローンとして 新しいPDBを作成することもできます。基盤となるファイル・システムがシン・プロビジョニングを サポートしている場合は、ほぼ一瞬で数テラバイトをクローニングできます。不明瞭なエンティティ としてのPDBに関するすべての操作（ PDBの新規作成、アンプラグ、プラグイン、クローニング、 および削除）がSQL文として公開されています。キーワードsnapshotをSQLコマンドで使用するだけ で、シン・プロビジョニングを使用するクローニングをリクエストできます。アンプラグ/プラグは、 トランスポータブル表領域テクノロジーの性質を拡張することにより実装され、マルチテナント・ アーキテクチャの特徴であるデータベース内仮想化により実現されます。アンプラグ/プラグは、異 なるOracle Databaseソフトウェア・バージョン間でもサポートされます 9。 新しいマルチテナント・アーキテクチャを使用できるのは、Standard Edition、Standard Edition One、 およびEnterprise Editionです。ただし、Oracle Multitenantオプションのライセンスがない場合は、 PDBを最大1つに制限されます 10。このモデルの重要性については、"CDB内の単独PDBと非CDBの比 較"（47 ページの）で説明します。 -------------------------------------------------8 これを完全に理解するには、後で説明する各概念を理解している必要があります。特に、ルート（"マルチテナ ント・アーキテクチャの静的側面：水平方向にパーティション化されたデータ・ディクショナリとプラグ機能 "（12ページ））、共通ユーザー（"マルチテナント・アーキテクチャの動的側面：Oracleインスタンス、ユーザー、 およびセッション"（31ページ））、container_dataビュー（"データ・ディクショナリ・ビューとパフォーマン ス・ビュー"（36ページ））の理解が前提となります。 9 これに関する詳細は、"マルチテナント・アーキテクチャの静的側面：水平方向にパーティション化されたデー タ・ディクショナリとプラグ機能"（12ページ）で説明します。 10 正式な使用条件については、Oracle Database 12cのライセンス・ガイドを参照してください。 2013年6月 11ページ Oracle Multitenant マルチテナント・アーキテクチャの静的側面： 水平方向にパーティション化されたデータ・ディクショナリとプラグ機能 スキーマベースの統合を実装したユーザーは、実質的に、Oracle Database固有のサポートを何も使 用せずにデータベース内仮想化を実装しようとしたと言えます。この項では、このアプローチを難 しくしている原因が古いアーキテクチャのデータ・ディクショナリにあることを説明します。続い て、マルチテナント・アーキテクチャに固有の仮想化の基本概念（水平方向にパーティション化さ れたデータ・ディクショナリ）について説明します。 究極の論理的存在である表 静止しているOracle Databaseはデータベース・ファイルのみで構成されています。ブートストラッ プ・ファイル（制御ファイル、spfileなど）を除けば、そのほとんどは表領域を実装するファイルで す。同様に、表領域に含まれるのは、表と、アクセスを高速化したり表領域のリカバリ可能性を保 証したりするためのさまざまな構造体のみです。表領域が存在するのは、もちろん表のためです。 制約、ビュー、PL/SQLオブジェクトなど、他のあらゆる種類のデータベース・アーチファクトは結 局、表内の行として表されます。表に保持されるデータは、Oracleシステムを表すメタデータ、ユー ザーが作成したアプリケーション・バックエンドを表すメタデータ、アプリケーション・バックエ ンドの表で割当て制限を消費しているデータの3種類のみです。 非CDBアーキテクチャの画一的データ・ディクショナリ 11.2までは、Oracleシステムを表すメタデータも、ユーザーが作成したアプリケーション・バックエ ンドを表すメタデータも、データ・ディクショナリと総称される単一の表セットに表示されます。 この表は、よく知られているとおり、DDL文の実行時に、Oracleインスタンスを実装する実行可能ファ イルによって暗黙的にメンテナンスされます。ユーザーがこれらの表に対して挿入、更新、削除を 直接実行することはできません。また、これらの表の構造は文書化されていないため、ここに表示 される情報はデータ・ディクショナリ・ビュー経由で問い合わせる必要があります。それでも、ユー ザーはこれらの表の名前（Obj$、Tab$、Col$など）を知り、その重要性を理解するようになります。 これらのデータ・ディクショナリ表は専用の表領域に格納されますが、特に注目すべきなのはSystem 表領域です。図1は、ユーザーが何もアーチファクトを作成していない、作成直後の非CDBの全容を 表しています。 図1 作成直後の非CDB 2013年6月 12ページ Oracle Multitenant アプリケーション・バックエンドを非CDBにインストールすると、まず、アプリケーション・バック エンドのメタデータを表すデータ・ディクショナリ表に行が挿入されます。アプリケーション・バッ クエンドの最終的な目的はアプリケーションの永続性メカニズムになることであるため、このメタ データには当然、アプリケーション表の説明が含まれます。通常のベスト・プラクティスに従い、 これらの表は専用のアプリケーション・データ表領域に格納されます。アプリケーション表には割 当て制限を消費するデータがすぐに含まれるため、非CDBを定義する表セット全体は図2のようにな ります。 図2 アプリケーション・バックエンドのアーチファクトをインストールした後の非CDB 図2と、次の項の図3および図4では、ユーザーが作成したアーチファクト（メタデータ行と割当て制 限を消費するデータ行の両方）を赤で示し、Oracleシステムを表すアーチファクト（メタデータ行の み）を黒で示しています。 当然ながら、ユーザー、ロール、エディション、表領域といったグローバル・アーチファクトの名 前空間は、User$、Edition$、TS$などの表の一意索引で定義されます。同様に、ユーザーおよびロー ルに付与された権限（publicロールを含む）などのグローバル・アーチファクトは、SysAuth$表お よびObjAuth$表に表示されます。これですぐに、2つ以上のアプリケーション・バックエンドを同じ 非CDBにインストールしようとしたときによく見られる名前の競合、およびそれに伴うセキュリティ 上の問題が明らかになります。 図2を見ると、第2世代のOracle Data Pump、つまりトランスポータブル表領域の使用によりさらな る飛躍を遂げたのも理解できます。第1世代のOracle Data Pumpでは、ひたすらSQLのスローバイス ロー 11作成（エクスポート時）とリプレイ（インポート時）を使用しました。それも、DDL文とDML 文の両方についてです。第2世代では、DML文を使用する代わりに、アプリケーションの割当て制限 を消費するデータを保持する一連の表領域（図の右側の、すべて赤で表示されている部分）を、表 データとその索引の説明をすべて保持する自己完結型ユニットとして処理することで、DML文を使 用する必要性をなくしました。特に、インポート時は、メタデータ操作のみを使用してトランスポー タブル表領域がプラグインされるため、非常に高速です。 図2を見ると、12.1より前は第3世代のOracle Data Pumpがなかった理由も理解できます。各データ・ ディクショナリ表にはユーザーのメタデータとOracleシステムのメタデータの両方が含まれている ため、アプリケーション・バックエンドのこの部分の移動は引き続きスローバイスローのDDL文に 頼るしかありません。 -------------------------------------------------11 スローバイスローとはOracleのTom Kyteが作った表現です。この表現はAskTomやOracle Magazineの彼の記事 でよく使われています。 2013年6月 13ページ Oracle Multitenant 要するに、スキーマベースの統合を難しくし、統合後の体制にセキュリティの低下を招き、アプリ ケーション・バックエンドの移動性に制限をかけるのは、非CDBアーキテクチャの画一的なデータ・ ディクショナリなのです。別の言い方をするならば、非CDBアーキテクチャのデータ・ディクショナ リは仮想化されない、ということになります。 マルチテナント・アーキテクチャの水平方向にパーティション化されたデータ・ディクショナリ そうなると、解決策は明白です。マルチテナント・アーキテクチャのデータ・ディクショナリは仮 想化されているのですから。 このアプローチの概要 教科書どおりに仮想化を行う場合は、システムを実装する1つ1つの事象を識別し、それぞれに所属 先の識別子をタグ付けします。これを実行する概念上のもっとも簡単な方法としては、すべてのデー タ・ディクショナリ表に新しい列を追加し、その表が説明するアプリケーション・バックエンドを 示し、Oracleシステムを表す行には特殊な値を使用するというやり方がありました。しかし、このア プローチではアプリケーション・バックエンドの移動性は解決されません。そのため、データ・ディ クショナリを水平方向にパーティション化する方法で、この論理的なタグ付けスキームが実装され ました（この機能はユーザーが使用できるように公開されているものですから、この実装とOracle Partitioningの実装を混同しないでください。この実装はまったく異なり、データ・ディクショナリ は、通常の抽象的な意味でパーティション化されます）。図3は、単一のアプリケーション・バック エンドを保持するCDBのスキームを示しています。 図3 水平方向にパーティション化されたデータ・ディクショナリがマルチテナント・アーキテクチャによって導入された状態 2013年6月 14ページ Oracle Multitenant "下"半分（本書で説明する部分）にはOracleシステムのメタデータが保持され、それ以外は何もあり ません。そして、"上"半分にはアプリケーション・バックエンドのメタデータが保持され、それ以外 は何もありません。つまり、各データ・ディクショナリ表は、Oracleシステム用として1回、アプリ ケーション・バックエンド用として1回、の計2回出現しています。概念上、データ・ディクショナ リ表に対するすべての問合せは、2回出現するその表の間の結合になります。 データ・ディクショナリ表の各セットはそれぞれ独自の表領域（1つまたは複数）に存在し、したがっ てそれぞれ独自のデータファイルに存在しています。データファイルのパスは、当然ながら、ファ イル・システム内で一意である必要があります。ただし、表領域の名前、および表領域に含まれる セグメントは、"上"または"下"のいずれかのパーティションに存在するデータ・ディクショナリ表内 でのみ一意である必要があります。したがって、両方のパーティションでデータ・ディクショナリ 表に同じ名前を使用し、データ・ディクショナリ表が含まれる表領域に同じ名前を使用するのは自 然なことです。この点については次の項で詳しく説明します。 PDBおよびルートの実際の定義 Oracleシステムのメタデータを保持するデータ・ディクショナリ表を実装する一連の表領域（すなわ ち一連のデータファイル）をルートと呼びます（ルートの名前はCDB$Rootです）。また、アプリケー ション・バックエンドのメタデータを保持するデータ・ディクショナリ表を実装する一連の表領域 （すなわちそのデータファイル）と、アプリケーション・バックエンドの割当て制限を消費するデー タ（すなわちそれらすべてのためのデータファイル）を保持する一連の表領域を結合したものがPDB です。したがって、PDBは完全なデータベースですが、ルートはメタデータベースにすぎません。デー タ・ディクショナリはすでに仮想化されているため、当然、同じCDBに多数のPDBを収容できますが、 この場合、各PDBは結局、自己完結型データファイルの独自セットということになります。 このことを示しているのが図4です。 図4 PDBを252個までルートにプラグインしたCDBアーキテクチャ そこで、意味を持つのが、各PDBに専用の（プライベート）名前空間が定義されており、非CDBでは データベース全体で一意でなければならないユーザー、ロール、パブリック・シノニムといった事 象はすべてここに保持されるという点です。そのため、特定のCDBに収容されているPDBごとに、 Scottという名前のユーザーを設定できます。したがって、権限およびロールを割り当てるとデータ・ ディクショナリ表のSysAuth$とObjAuth$に表示される内容も、1つのPDB内に収容されます。 2013年6月 15ページ Oracle Multitenant 割当て制限を消費するデータを決して保持しないという点でルートとPDBは大きく異なりますが、そ れぞれがデータ・ディクショナリを持ちフォアグラウンド・プロセスの"焦点"になり得るため、これ らのCDBコンポーネント同士には非常に類似する点があります。そこで、ルートまたはPDBのスー パークラス用語としてコンテナという用語を使用します。存続中のフォアグラウンド・プロセス（す なわちセッション）には、常にカレント・コンテナが一意に定義されています。 PDBがPDB（プラガブル・データベース）と呼ばれる理由は、あるCDBのルートからアンプラグして 別のCDBのルートにプラグインできるためです。図4の黒い大きな矢印はそれを示しています。もち ろん、ルートのメタデータには、そこにプラグインされている各PDBが記述されています。アンプラ グすると、アンプラグしたPDBのメタデータは削除され、プラグインすると、プラグインされたPDB を記述したメタデータが作成されます。これは、12.1より前のトランスポータブル表領域テクノロ ジーの性質を発展させたものです。PDBのアンプラグとプラグインが第3世代のOracle Data Pumpに なり得ることがこれでわかります。割当て制限を消費するデータとメタデータの2つを合わせて完全 なアプリケーション・バックエンドとなりますが、これを不明瞭な自己完結型のユニットとして移 動できるため、スローバイスローのDDL文を作成したりリプレイしたりする必要がなくなります。 このアプローチの内部の概要 データ・ディクショナリ問合せがどのように実装されるのかわからない人がいるかもしれません（わ かる人はこの項を飛ばしてくださってかまいません）。これについて再度説明することはしません。 また、以降の説明を理解するには、ここでの説明を理解しておく必要があります。 すべての問合せは、最終的に、ブロックをバッファ・キャッシュに取り込むことで実装されます。 したがって、ブロックにアドレスを付ける必要があり、ブロックのアドレスの一部はブロックが格 納されているファイルの番号となります。マルチテナント・アーキテクチャでは、セッションのカ レント・コンテナのIDに基づく相対スキームを使用してデータファイルに番号を付けます。通常の 操作ではPDBがカレント・コンテナであるため、セッションがアクセスできるのはそのPDBのデータ ファイルに含まれるブロックのみです。データファイルに相対的な番号を付けるこのスキームは、 Oracle Databaseを実装するレイヤード・モジュールの低レベルで実装されます。すなわち、セッショ ンのPDB識別子はサイド・チャネル経由で低レベルのモジュールに渡され、SQLとPL/SQLのコンパイ ル・サブシステムおよび実行サブシステムが下方のデータ・レイヤーと通信するときに使用するさ まざまな高レベルのAPIは、非CDBアーキテクチャに関しては変更されません。つまり、12.1では、 Oracle Databaseを実装する大量のコード（オプティマイザも含むすべてのSQL、すべてのPL/SQL、 これらの上に構築されているスケジューラなどのあらゆるもの）を変更しなくても、新しいマルチ テナント・アーキテクチャに対応できるのです。そのため、PDB/非CDB互換性保証を比較的容易に 遵守できました。 データ・ディクショナリ問合せがPDBのコンテキストで発行され、Oracleシステムを表す行にアクセ スする必要がある場合は、カレント・コンテナがルートに切り替わり、その後PDBに戻ります。この 必要性を通知し、効率化するメカニズムが、図3では、PDBのObj$表の行からルートのObj$表の行へ 向かう点線の矢印で示されています。直接または間接的にルートのObj$表の行を参照するさまざま な詳細表をすべてクローズすると、オラクルが提供するオブジェクトがルートに完全に表示されま す。またこれは、ルート内の対応する行を示すPDBのObj$に含まれるたった1行によって、PDB内に まばらに配置されます。 2013年6月 16ページ Oracle Multitenant エンティティとしてのPDB上での操作： アンプラグ/プラグ、クローン、作成、削除 次は、マルチテナント・アーキテクチャのコンテキストでこれらの操作を実装すると、なぜOracle バージョンのプロビジョニングおよびパッチ適用の新しいパラダイムになるのかを説明します。 マシン間のアンプラグ/プラグ 図5は、マシン1で動作しているCDB_1のルートに、PDB_1がプラグインされている様子を示してい ます。設計に従い、PDB_1にはアプリケーション・バックエンドが1つだけ保持されています。ここ での目的は、このアプリケーション・バックエンドをマシン1からマシン2に移動することです。 図5 2つのマシン間のアンプラグ/プラグ：CDB_1にPDB_1をプラグインした状態から開始 PDBがCDBに収容されている間は、PDBがこのCDBの中で持っている名前やPDBのデータファイルへ のパスといったPDBのメタデータは、CDBで保持されます（その一部はルートに保持され、CDBの制 御ファイルに保持されるものもあります。今説明している内容には、この区別は重要ではありませ ん）。PDBをアンプラグすると、このメタデータは、PDBのデータファイルを伴う外部のマニフェス トに書き込まれます。アンプラグは、-- コード_1に示すような単一のSQL文として実装されます。 -- コード_1 -- アンプラグする前にPDBをクローズする必要があります。 alter pluggable database PDB_1 unplug into '/u01/app/oracle/oradata/…/pdb_1.xml' この意味は、"PDBの名前を指定し"、"そのアンプラグを指示し"、"外部のマニフェストへのパスを指 定する"、というものです。 同様に、プラグインも、コード_2に示すような単一のSQL文として実装されます（アンプラグしたPDB をプラグインするためのSQL文は、create pluggable database文のバリエーションの1つです。その他 のバリエーションには、PDBのクローン作成や新規PDBの作成があります。これらの例は、-- コード _2、-- コード_3（25 ページの）、-- コード_4（25 ページの）、-- コード_6（26 ページの）、 お よび-- コード_7（26 ページの）に示されています。ただし、Oracle Managed Filesが有効化されてい ることを前提としています）。 2013年6月 17ページ Oracle Multitenant -- コード_2 -- プラグインした後にPDBをオープンする必要があります。 create pluggable database PDB_2 using '/u01/app/oracle/oradata/…/pdb_1.xml' path_prefix = '/u01/app/oracle/oradata/pdb_2_Dir' path_prefix句はオプションです。この句はcreate pluggable database SQL文のみで指定できます。 既存のPDBについて変更することはできません。この句を使用して作成されたPDBからcreate directory SQL文が発行された場合は、結果に影響します。create directoryのpath句に指定した文字 列はcreate pluggable databaseのpath_prefix句に指定した文字列に追加され、新しいディレクト リ・オブジェクトが示す実際のパスになります。これは、PDB間の独立性を制御するための重要な方 法です。 -- コード_2を実行すると、図6に示す結果となります。 図6 2つのマシン間のアンプラグ/プラグ：CDB_2にPDB_1がプラグインされた状態で終了 この意味は、"新しいPDBの作成を指示し"、"その作成のために、アンプラグしたPDBのプラグインと、 外部のマニフェストのパスの指定を指示し"、"プラグインしたPDBの新しいCDB内での名前を指定し、 このPDB内で作成されるディレクトリ・オブジェクトはすべてCDBが使用するファイル・システム内 の特定のサブツリーに設定されるようにする"というものです。 異なるオペレーティング・システム、チップセット、エンディアンネス間のアンプラグ/プラグ クロス・プラットフォームのアンプラグ/プラグには、クロス・プラットフォームでトランスポータ ブル表領域を使用する場合と同様の懸念事項があります。ユーザーが作成した表領域のエンディア ンネスをOracle RMANのconvertコマンドで一方から他方へ変換する場合、変更されるのはブロッ ク・ヘッダーのみです（ブロック・ヘッダーはエンディアンネスを区別する方法でエンコードされ ているためです）。ユーザーが作成した表の列に含まれるデータはそのままです。これらのほとん どには（楽観的に考えると）、varchar2やnumberなどのプリミティブなスカラー・データ型が使用 されます。そして、これらはエンディアンネスを区別せずにネットワーク・バイト・オーダーで表 現されます。 2013年6月 18ページ Oracle Multitenant 一方（こちらも楽観的に考えると）、rawまたはblobのデータ型の列が使用されている場合は、解釈 方法を知っているクライアント側のコードのみで消費されるデータ（.pdfファイルまたは.jpgファイ ルなど）の保持に使用されます。ただし、ユーザーがエンディアンネスを区別する方法でデータを エンコードしている場合は、そうしたデータを含むトランスポータブル表領域を異なるエンディア ンネスの環境にプラグインした後に、ユーザー自身の責任で、そのエンコードが行われている場所 を把握し、ユーザー独自の変換処理を適用する必要があります。 アンプラグしたPDBにはデータ・ディクショナリ表が含まれ、その中の一部の列にはエンディアンネ スを区別する方法でエンコード情報が含まれているため、この問題はさらに複雑になります。この ような列の変換を自動処理する方法はサポートされていません。要するに、アンプラグしたPDBをエ ンディアンネスの異なる環境に移動することはできないということです。 なお（データ・ディクショナリではエンディアンネスが区別されている場合に）、機能として求め られているものが異なるエンディアンネス間のアンプラグ/プラグであれば、実行可能なアプローチ は、Oracle Data Pumpを使用して、ターゲットCDB内にある空の新規PDBにコンテンツを移行する方 法しかありません。トランスポータブル表領域を使用する場合は、Oracle RMANのconvertを使用し て処理する必要があります。データ量が少ない場合は、トランスポータブル表領域を使用せずに"従 来の"Oracle Data Pumpを使用すると処理が速くなる可能性があります。 さらに、エンディアンネスの問題の次は、PL/SQLのネイティブ・コンパイルが使用されている可能 性があります。使用されている場合は、コードをコンパイルしたプラットフォームのチップセット を認識するマシン・コードが特定のデータ・ディクショナリ表に保持されます。そのようなマシン・ コードを保持しているPDBをアンプラグし、そのPDBがプラグインされていたCDBが動作していたプ ラットフォームとは異なるチップセットを搭載したプラットフォームで動作しているCDBにプラグ インした場合は、PDBを動作させられなくなります。この場合の解決策は単純です。プラグインした PDBを使用できるようにする前に、そのPDBに含まれるネイティブ・コンパイル済みのすべての PL/SQLユニットを再コンパイルすればよいのです。 アンプラグ/プラグによるOracleバージョンのパッチ適用 マルチテナント・アーキテクチャでは、元々プラグインしていたCDBとは異なるOracle Databaseソ フトウェア・バージョンのCDBにPDBをプラグインできます（市販されている12.1バージョンは 12.1.0.1のみであるため、この機能を実演することはできません）。 もっとも変更の小さいパッチではOracleバイナリしか変更されません。言い換えると、定義上、この種の パッチでデータファイルの内部が変更されることはありません。つまり、ソースCDBと宛先CDBの違いが この種のパッチによるものである場合は、プラグインするPDBを変更する必要が何もないということです。 PDBのマニフェストに記述されている情報を使用して、Oracle Databaseソフトウェア・バージョンの違 いがこの種のものであることをチェックする必要はありますが、それだけで十分です。 変更度合いが大きいパッチでは、データ・ディクショナリに含まれるOracleシステムの定義が変更さ れます（これらのパッチでは通常、Oracleバイナリも変更されます）。しかし、アップグレードでは なくパッチと呼ばれるだけあって、データ・ディクショナリへのそうした変更に連鎖して他の部分が 無効になることは通常ありません。たとえば、オラクルが提供するパッケージの本体を、バグ修正の ための新しい実装を使用して再コンパイルすれば、パッケージの仕様部は引き続き有効であるため、 その依存のクローズ時にオブジェクトもすべて引き続き有効になります。 2013年6月 19ページ Oracle Multitenant Oracle Database 11g以降、ファイングレインな依存性追跡ができるようになったため、既存のサブプ ログラムの名前をオーバーロードしない新しいサブプログラムが追加され、オラクルが提供するパッ ケージの仕様部が変更された場合でも、他の部分が連鎖的に無効化されることはありません。この種 のパッチを非CDBに適用しても、ユーザーが作成したアーチファクトは変更されません。つまり、こ の種のパッチの場合であっても、プラグインするPDBを変更する必要はないということです 12。今の ところ、パッチによってなんらかの無効化が連鎖的に発生しても、PDBで必要となる補正作業は少な いと見ています。 Oracleバージョンのパッチ適用にこの新しいアンプラグ/プラグ・パラダイムをもっとも効果的に活 用するには、PDBのデータファイルの配置をそのままにできるように、ソースCDBと宛先CDBでファ イル・システムを共有する必要があります。このことを示しているのが図7です。 図7 共有ファイル・システム上にデータファイルを配置したままでの、Oracle Databaseソフトウェア・バージョンが異なる2つのCDB間でのアンプラグ/プラグ -------------------------------------------------12 "このアプローチの内部の概要"（16ページ）で説明したとおり、実装ではPDBのObj$行を使用して対応するルー トのObj$行を参照するという事実があり、PDBの行にはルートの対応行のシグネチャがエンコードされるため、 PDBの行では再計算が必要になります。そのうえ、PDBのDependency$表は完全に移入されます。Oracleシス テムのアーチファクトについてのセマンティック・コンテンツはルートの対応行と同じですが、依存関係にあ る親および子のオブジェクト番号にはローカルの値が使用されます。依存関係にある親をコンパイルしたとき のタイムスタンプや、子が依存する属性のエンコードといったファイングレインな依存性の詳細が記録されま す。CDBが異なればオブジェクト番号も異なる可能性があるため、PDBはルートのオブジェクトとの依存関係 をルートのオブジェクト番号を使用して表現できないことは見当がつきます。PDBのObj$行とルートの対応行 との間の接続はマッピングで実装されます。そして、これなしでは高速なアンプラグ/プラグは機能しません。 したがって、ソースと宛先のCDBにこの種のパッチの相違がある場合は、PDBをプラグインした後にファイン グレインな依存性の詳細を再計算することも必要になり、場合によってはPDBのDependency$表に含まれる一 部の行の再計算も必要になります。これは極めて短時間で終了する操作です。 2013年6月 20ページ Oracle Multitenant アンプラグ/プラグの各操作が影響を及ぼすのはPDBについて記述したルートのメタデータのみであるた め、これらの操作は非常に高速です。データファイルの配置がそのままであれば、PDBをクローズしてソー スCDBからアンプラグしてから、宛先CDBにプラグインしてオープンするまでの合計時間は、一般的なマ シンで数秒です。ただし、これはOracle Databaseソフトウェア・バージョンに違いがない場合です。つ まり、所要時間は、Oracleバイナリの変更に起因する相違のみの場合は同じで、ユーザーが作成したアー チファクトを無効化しないデータ・ディクショナリの変更に起因する相違である場合はわずかに長くな る、ということです。ユーザーが作成したアーチファクトになんらかの無効化を引き起こすパッチの場 合であっても、ファイングレインな依存性追跡機能があるため、プラグインするPDBで実行する必要のあ る再コンパイルの量は最小化されます。オラクルは自主的に互換性ルールを課しており、ユーザーが作 成したオブジェクトで変更前に有効だったものは、Oracleバージョンのパッチ適用（またはアップグレー ド）による変更を受けても取消し不能な無効状態に放置しないことを保証しています。変更の影響を受 けて無効化されたオブジェクトは、再コンパイルすれば必ず有効な状態に戻ります。 Oracle Databaseソフトウェア・バージョンのアップグレードでは、ユーザーが作成したアーチファ クトへの連鎖的な影響を伴う大幅なデータ・ディクショナリ変更が許可されています（アップグレー ドという用語を使用する場合は、x.1リリースからx.2リリース（例：12.1から12.2）、またはx.2リリー スからx+1.1リリース（12.2から13.1）への移行を意味します）。この種のアップグレードを非CDB に適用すると、Oracleシステム、ユーザーが作成したアーチファクトの順に、スクリプトによって処 理されます。つまり、ソースCDBと宛先CDBにこの種のアップグレードによる相違がある場合は、 Oracleシステムをスクリプトで変更した後に非CDBで実行するのと同じスクリプトによる変更を、プ ラグインするPDBでも実施する必要がある、ということです。したがって、プラグインするPDBに必 要な変更を加えるための所要時間は、非CDBで最初にOracleシステムへの必要な変更を行ってからこ れとまったく同じことを実行する場合の所要時間より必然的に短くなります。 言い換えれば、アプリケーション・バックエンドがPDBでホストされている場合、アンプラグ/プラ グ方式によるOracleバージョンのパッチ適用により発生するアプリケーションの停止時間は、同じ パッチを非CDBに適用する場合の停止時間より常に短くなります。そして、PDB内である程度の連鎖 的な無効化を引き起こすパッチの場合でも、数秒間にとどめられます。プラグインするPDB内での処 理によって、ユーザーが作成したアーチファクトが無効化されないと保証される場合、この処理は 暗黙的に実行されます。そうでない場合は、オラクルが提供するスクリプトを実行する必要がある とユーザーに通知されます。 また、パッチを適用した宛先CDBの設定コストの償却率が非常に高い点も注目です。つまり、コストの 投入は一度ですが、異なるOracle Databaseソフトウェア・バージョン間でPDBをアンプラグ/プラグす るたびに、多数のPDBの1つ1つについてOracleバージョンのパッチ適用コストを回収できるのです。 宛先CDBのOracle Databaseソフトウェア・バージョンがソースCDBより古い場合では、アンプラグ/プラ グを実行すると、非CDBでのパッチ取消しまたはダウングレードとまったく同じルールに従って処理され ます（"原則"的には、互換性のあるパラメータの値は、古いバージョンの値と等しくする必要があります。 また、現実的には、ユーザーが作成したどのアーチファクトも、新しいほうのバージョンにのみ存在す る機能にセマンティック上は依存しないこと、という要件が追加されます）。本書では、Oracle Database ソフトウェア・バージョンのパッチ取消しとダウングレードの両方を指す用語として、Oracleバージョン へのパッチ適用の取消し、を使用します。上記の説明から、Oracleバージョンのパッチ取消しについての 考慮事項はOracleバージョンのパッチ適用の場合と同一であることがわかります。 2013年6月 21ページ Oracle Multitenant この項の最後に、演習を兼ねて、多数のPDBを収容するCDB全体にOracleバージョンをパッチ適用す る場合を検討してみましょう。パッチの中でも特に影響の少ないものの場合、変更はすべてルート だけに対するものに限定されます。したがって、アプリケーション・バックエンドがn個ある環境へ のパッチ適用にかかる時間は、それぞれが専用のPDBに収容されていて、CDB全体にパッチを適用す る場合であれば、アプリケーション・バックエンドが1個あり、それが専用の非CDBに収容されてい る環境へのパッチ適用にかかる時間とほぼ同じになります。つまり、マルチテナント・アーキテク チャでは、非CDBアーキテクチャ内の1つのアプリケーション・バックエンドにOracleバージョンを パッチ適用するコストで、n個のアプリケーション・バックエンドにOracleバージョンをパッチ適用 できるのです。このアプローチは、あらゆるものをまとめて新しいバージョンに移行する必要があ り、移行後は開発やテストのためだけに使用される開発環境やテスト環境に適しています。また、 アンプラグ/プラグ・アプローチは、統合された各アプリケーション・バックエンドをそれぞれのス ケジュールに従って新しいバージョンに認定する本番環境に適しています。 "アンプラグ/プラグの代わりにOracle GoldenGateレプリケーションを使用したリモート・クローニング" の項（25 ページの）では、実質的にホット・アンプラグ/プラグとなるアプローチについて説明します。 アンプラグ/プラグによるSLA変更への対応 この新しいアンプラグ/プラグ・パラダイムは、SLAの変更にすばやく対応するうえでも非常に役立 ちます。ここでも、ソースCDBと宛先CDBではファイル・システムを共有し、PDBのデータファイル の配置をそのままにできるようにする必要があります。 したがって、通常は、同じプラットフォーム上に複数のCDBを保持し、Oracle Databaseソフトウェ ア・バージョンおよび構成を変え、さまざまなSLAに適合させられるようにします。 PDBのクローニング アンプラグしたPDBは表示されませんが、アプリケーション・バックエンドを定義するあらゆるもの を完全に表現したものであり、通常は過去に使用されていたことがあるため、割当て制限を消費す るデータが保持されています。そのようなアプリケーション・バックエンドの同一コピー（つまり クローン）が使用中に必要になった場合は、PDBをアンプラグし、オペレーティング・システムのメ ソッドを使用してすべてのファイルをコピーし、元のファイルをプラグインし直し、クローン・ファ イルをプラグインし、異なる名前で使用します。また、 異なるCDBにプラグインすることもできます13。このように検討してみると、PDBのクローン作成SQL文が どのように機能するのか推測できます。ソースPDBをアンプラグしなければ、フォアグラウンド・プロセス がソースPDBのファイルをコピーしてクローンとして接続します。このことを示しているのが図8です。 -------------------------------------------------13 厳密に言うと、これは正しくありません。PDBの作成SQL文を実行するとPDBにグローバル一意識別子が割り 当てられ、アンプラグ/プラグの操作でもこの識別子がPDBについて回ります。2つのPDBに同じグローバル一 意識別子を割り当ててはいけないことは明らかです。したがって、アンプラグしたPDBのファイルを手動でコ ピーしてはいけません。クローンが必要な場合は代わりにPDBのクローン作成SQL文を使用します（その場合 は、アンプラグしたPDBからのクローニングも可能です。詳しくは"アンプラグしたPDBからのクローニング" （24ページ）を参照してください）。また、"保険"としてのコピーが必要な場合は、Oracle RMANのバックアッ プかOracle Data Guardを使用します。 2013年6月 22ページ Oracle Multitenant 図8 フォアグラウンド・プロセスを使用したPDBのデータファイルのコピーとクローンの作成 フォアグラウンド・プロセスは、新しいグローバル一意識別子をクローンPDBに割り当てます。クロー ンには、コピー元のPDBのグローバル一意識別子が記録されます。また、クローンの系統は任意に長 くつなげることができます。 マルチテナント・アーキテクチャでは、2つのCDBがOracle Netで接続されている限り、ソースPDB と同じCDBにも、異なるCDBにも、クローンPDBを作成できます。この2つの選択肢を区別するため に、以降はローカル・クローニングという用語とリモート・クローニングという用語を使用します。 フル・コピーを使用したPDBのクローニング Oracle Databaseではファイルのコピーが実行されるため、Oracleパラレル・サーバー・プロセスを集中 させてタスクの合計時間を削減することができます。さらに、コピー対象のデータファイルにはOracle データ・ブロックが含まれており、Oracleバイナリはそれらが何であるかを把握しています。そのため、 並列度を制限する要因はデータファイルの数でも、オペレーティング・システムによって把握されてい るデータ・ブロック内におおまかに割り当てられたユニットでもありません。むしろ、一連のデータファ イルに含まれるOracleデータ・ブロックの数によって制限されるのです。この数は非常に大きいため、マ シン上に他の同時アクティビティがあるとすれば、実際にはPDBのクローン作成操作専用にすることがで きるOracleパラレル・サーバー・プロセスの数によってのみ並列度が制限されます。 マルチテナント・アーキテクチャでは、ソースPDBが静止していなくてもPDBのクローン作成操作を実 行できます。ただし、12.1.0.1ではサポートされていません（この操作を実行しようとすると、 ORA-65081： データベースまたはプラガブル・データベースは、読取り専用モードでオープンしてい ません、というエラーが発生します）。これには、Oracle RMANでのオンライン・バックアップで発生 するのと同じ課題があります。一連のデータファイルのコピーを時刻tから開始した場合、コピーを作 成している間にこれらのファイルに含まれるOracleデータ・ブロックの一部が変更されてしまうという 問題です。これを解決するには、コピー対象のブロックが時刻t以降に変更されたかどうかを把握し、 変更されている場合はUNDO情報を使用して時刻tの状態を再構築する必要があります。このOracle RMANでの手法をPDBのクローン作成操作に応用できることは明らかです。ソースPDBを静止させずに 実行するPDBのクローン作成のことをホット・クローニングと呼ぶことにします 14。 -------------------------------------------------14 このホワイト・ペーパーにホット・クローニングの話題を含めた理由は、そうしないと、ホット・クローニン グのサポートの課題はOracle RMANのオンライン・バックアップのサポートの課題と同じだと読者から指摘を 受ける可能性があるためです。このホワイト・ペーパーの作成時点では、どのOracle Databaseリリースでホッ ト・クローニングがサポートされるかわかっていません。 2013年6月 23ページ Oracle Multitenant スナップショット・コピーを使用したPDBのクローニング しばらくの間、オラクル（Sun ZFS）やNetAppなどのファイル・システム・ベンダーは、極端に大きい ファイルのコピーを数秒以下で作成する手法を公開していました。このアプローチでは、ファイルだけ でなく他のさまざまな種類の構造体にも適したCopy-on-Writeと呼ばれる一般的な概念を活用します15。 簡単に説明すると、この概念をファイルのコピーに応用した場合、実際には、ファイルの名前を保持す るとともにファイルのブロックへのポインタをリストする別のレコードを通じて、ブロックがアクセス されます。すべてのブロックをコピーする代わりにポインタのリストだけをコピーし、これに新しいファ イルの名前を付けます。ここまでで、ファイルに含まれる各ブロックはソース・ファイルのポインタ・ リストとコピー・ファイルのポインタ・リストの両方から参照されます。実質的なストレージは消費さ れていないため、コピーはほぼ一瞬です。いずれかのファイルのブロックに書込みが試行されたときだ け、そのブロックの2つ目のコピーが作成され、2つのファイルはこのブロックが異なる状態になります。 このアプローチがCopy-on-Writeと呼ばれるのは、このような考え方に由来します。 大きいファイルをこの方法でコピーしておけば、ほんの一部のブロックしか変更されなかった場合 は最終的に膨大な時間とマシン・リソースが節約されます。そのため、開発またはテストを目的に クローンを作成する場合は、このアプローチが非常によく使用されます。通常、この使用例では、 ほとんどのブロックが変更されない場合、存続期間が比較的短いうちにファイルは削除されます。 ファイル・システム・ベンダーでは、スナップショット・コピーなどの用語を使用しています。ま た、ビジネス上のメリットでは通常、シン・プロビジョニングと呼ばれます。 ユーザーはスナップショット・コピーを使用して、非CDBのRMANバックアップ・セットのシン・プ ロビジョニングされたコピーを作成し、クローニングされた非CDBをこのコピーからリストアしてい ました（クローンされた非CDBのために、新しいグローバル一意識別子を作成する必要があります）。 しかし、処理全体としては、さまざまな環境でさまざまな独立したステップを実行する必要があり、 さまざまな形態の権限が必要です。データベース管理者とストレージ管理者の職務は従来分割され ているため、通常はそれぞれ異なるパスワードを知っている複数の担当者が一致協力して作業する 必要があります。しかし、こうした作業をいつも簡単に調整できるわけではありません。 マルチテナント・アーキテクチャでは、フォアグラウンド・プロセスからストレージ・システムに 対し、専用のセキュアなプロトコルを使用してソースPDBのデータファイルをコピーするよう求める リクエストが送信されます。（CDBのデータファイル用の）ストレージ・システムの管理ユーザーの 資格証明（ユーザー名/パスワード）は特定のCDBのウォレットに記録します。 スナップショットPDBクローニングは、新しいPDBがソースPDBと同じCDBに作成される場合のみサ ポートされます。さらに、シン・プロビジョニングされたPDBが存在する間は、そのクローン・ソー スであるPDBは削除できません。スナップショット・コピーを使用して作成したPDBはアンプラグで きません。ソースPDBとクローンPDBは両方とも読取り/書込みモードでオープンできます。 12.1.0.1でスナップショットPDBクローニングをサポートするファイル・システムは、Sun ZFS、 NetApp、およびOracle ACFSです。他のファイル・システムでスナップショットPDBクローニングを 試行するとエラーが発生します（エラーはORA-17517：記憶域スナップショットを使用するデータ ベース・クローニングが失敗しました、です）。 -------------------------------------------------15 https://www.google.com.hk一般的な概念については、wikepediaの記事を参照してください （http://ja.wikipedia.org/wiki/コピーオンライト） 2013年6月 24ページ Oracle Multitenant アンプラグしたPDBからのクローニング アンプラグしたPDBは、アプリケーション・バックエンドのための非常に便利な転送媒体として使用 でき、さまざまなツール（SQL*Plus、Oracle Data Pumpなど）の実行を伴う以前の方法と完全に置 き換えることができます。このユースケースの場合は、アンプラグしたPDBを多数の異なるCDBに接 続するだけではうまくいきません。というのは、この方法で作成した各PDBには同じグローバル一意 識別子が割り当てられるためです。そのため、PDBのプラグイン・コマンドでは、アンプラグしたPDB のクローンとして新しいPDBを作成し、独自のグローバル一意識別子を割り当てることができます。 このSQL文を-- コード_6に示します。 この用法のバリエーションには、一連のPDBをアンプラグして"ゴールド・マスター"として顧客サイ トの中心点に構築し、アプリケーションのストレス・テストやアプリケーション・ロジックのデバッ グのための起点として有効活用するやり方があります。 アンプラグ/プラグの代わりにOracle GoldenGateレプリケーションを使用したリモート・クローニング ホット・クローニングがサポートされていない場合はアンプラグ/プラグを使用して作成するところで すが、ホット・クローニングがサポートされている場合はリモート・クローニングを使用して新しい PDBをCDBの中に作成できるうえ、移動対象のPDBにアプリケーション・バックエンドが収容されてい るアプリケーションの停止時間が発生しません。ホット・クローニングを開始した時点のSCNを記録し ておけば、その後、Oracle GoldenGateレプリケーションを使用してクローンPDBを同期させ、追跡を 続けることができます。絶え間なく追跡しているこの状態は、Oracle Databaseソフトウェア・バージョ ンのローリング・アップグレードに一時ロジカル・スタンバイを使用する場合の状態に似ています。 そのため、当然、クライアント側アプリケーションのカットオーバー手順は同じになります。つまり、 Oracle Databaseソフトウェア・バージョンが異なるソースCDBと宛先CDBとの間でPDBをリモート・ク ローニングする方法は、非CDBで定着している一時ロジカル・スタンバイ方式に対応しています。 PDBのクローン作成SQL文の構文 -- コード_3は基本的なPDBのクローン作成SQL文です。 -- コード_3 create pluggable database PDB_2 from PDB_1 これは、"PDB_1のクローンを作成し、新規作成されるPDBにPDB_2という名前を付けます"という意味です。 -- コード_4はリモート・クローニング用のPDBのクローン作成SQL文です。 -- コード_4 create pluggable database PDB_2 from PDB_1@CDB_02_link これは、"CDB_02_linkで表されるルートを持つCDBに収容されているPDB_1のクローンを作成し、新 規作成されるPDBにPDB_2という名前を付けます"という意味です（データベース・リンクは、クロー ニングされるPDBを指定することもできます）。 2013年6月 25ページ Oracle Multitenant データベース・リンクは、ソースCDBの場所の指定をカプセル化したものです（リスナー名、リス ナー・ポート、サービス名を指定し、これを元にデータベースとそのファイルへ導きます）。また、 ソースCDBのルートをカレント・コンテナとして持つセッションを開始するために必要な認可も指定 します。いったん場所と認可が確立されたら、最適な低レベル・プロトコルを使用し、パラレル化 してファイルが転送されます。パラレル化には、前述のOracleパラレル・サーバー・プロセスが使用 されます。データベース・リンクを経由してファイルが転送されるのではありません。 -- コード_5はスナップショット・コピーを使用するPDBのクローン作成SQL文です。 -- コード_5 create pluggable database PDB_2 from PDB_1 snapshot copy これは、"基盤となるファイル・システムのシン・プロビジョニング・アプローチを使用してPDB_1 のクローンを作成し、新規作成されるPDBにPDB_2という名前を付けます"という意味です。 -- コード_6はアンプラグしたPDBからクローニングを行うPDBのクローン作成SQL文です。 -- コード_6 create pluggable database PDB_2 as clone using '/u01/app/oracle/oradata/…/pdb_1.xml' copy これは、"アンプラグしたPDB（PDB_1）のクローンを作成し、新規作成されるPDBにPDB_2という 名前を付け、ソースとは関係なく変更できる新しいデータファイルにアンプラグしたPDBのデータ ファイルをコピーします"という意味です。 PDBの作成、プラグイン、クローン作成の3つの操作はすべて、create pluggable database SQL文の バリエーションです。そのため、それぞれのSQL文でpath_prefix句を使用できます。 PDBの作成 空のPDBを定義するデータ・ディクショナリ表をゼロから構築してObj$表およびDependency$表を 移入するのではなく、CDBを作成すると空のPDBが作成されます（ここでは、ユーザーが作成したアー チファクトを何も含まないという意味で空という言葉を使用しています）。これはシードPDBと呼ば れ、PDB$Seedという名前が付けられています。すべてのCDBには必ずシードPDBが1つ含まれ、必ず 読取り専用モードでオープンされます。これには概念上の重要性はなく、最適化するためにこのよ うな仕組みになっています。PDBの作成操作はPDBのクローン作成操作の特殊ケースとして実装され ます。シードPDBのサイズはわずか1GBほどで、一般的なマシン上でのコピーにかかる時間はほんの 数秒です。PDBの作成にスナップショットPDBクローニングを選択することはできません。 PDBの作成SQL文の構文 -- コード_7は基本的なPDBの作成SQL文です。 -- コード_7 create pluggable database PDB_1 path_prefix = '/u01/app/oracle/oradata/pdb_2_Dir' admin user PDB_1_Admin identified by p roles = (DBA, Sysoper) 2013年6月 26ページ Oracle Multitenant この意味は、"PDB_1と呼ばれるまったく新しいPDBを作成し、PDB内で作成されるディレクトリ・ オブジェクトはすべて、CDBが使用するファイル・システム内の指定したサブツリーの下に作成され るようにし、新しいPDBの管理者となるPDB_1_Adminという名前のローカル・ユーザー 16をPDBに 作成し、指定したロールのリストをこのユーザーに付与します"というものです。 PDBの削除 削除するPDBはクローズしておく必要があります 17。 PDBの削除操作には2つのユースケースがあります。1つ目は言うまでもないですが、単にPDBが不要 になった場合です。これは、特定の開発タスクのためにPDBを開始点として使用する環境や、PDBの 調査のためにクローニングと削除が繰り返される環境など、本番環境以外でよく使用されます。こ のケースを破壊的削除と呼びます。この削除は-- コード_8に示されています。 2つ目のユースケースはあまり知られていないケースです。PDBのアンプラグ操作を実行しても、PDBは ルートのメタデータに認識されたままで、PDBのデータファイルはCDBの制御ファイルにリストされたま まになります。これは、アンプラグされた時点の状態のまま、この1つのPDBだけをOracle RMANのバッ クアップを使用して記録できるようにするためです。そのため、バックアップを作成するかどうかに関 係なく、PDBのアンプラグ操作の後には必ずPDBの削除操作を実行する必要があります。バックアップを 取得しない場合はすぐに実行し、取得する場合はバックアップが正常に完了してから実行します。PDB のプラグイン操作を実行することが目的の場合は、当然、データファイルをそのままにする必要があり ます。このケースは非破壊的削除と呼びます。この削除は-- コード_9に示されています。 PDBの削除SQL文の構文 -- コード_8は破壊的なPDBの削除SQL文です。 -- コード_8 drop pluggable database PDB_1 including datafiles この意味は、"PDB_1という名前のPDBを削除し、トレースなしですべてのデータファイルを残らず 削除します"というものです。わかりきったことですが、これは注意して使用する必要があります。 -- コード_9は非破壊的なPDBの削除SQL文です。 -- コード_9 drop pluggable database PDB_1 keep datafiles これは、"PDB_1という名前のPDBは削除しますが、データファイルはすべてそのままにします"とい う意味です。 -------------------------------------------------16 ローカル・ユーザーの定義については"マルチテナント・アーキテクチャの動的側面：Oracleインスタンス、ユー ザー、およびセッション"（31ページ）を参照してください。 17 列gv$PDBs.Open_Modeが取り得る値は、MOUNTED、READONLY、READWRITEの3つです。これについては" 論理的に仮想化されるSGA"（34ページ）を参照してください。 2013年6月 27ページ Oracle Multitenant PDBの作成、クローン作成、削除、およびアンプラグ/プラグがSQL文であることが重要な理由 PDBの作成操作とPDBの削除操作は、Oracle Database Configuration Assistant（Oracle DBCA）を使用した非 CDBの作成または削除と機能的には同等です。ただし、Oracle DBCAを使用するには、ソフトウェア・イン ストールを所有する（すなわちそのソフトウェア・インストール内に作成された他のデータベースのファイ ルも所有する）オペレーティング・システム・ユーザーとして、関連するOracleホームがインストールされ ているマシンにログオンする必要があります。そのため、非常に信頼されている人以外はこうしたプロビ ジョニング・タスクを実行できません。PDBのクローン作成操作は、非CDBで言えば、Oracle RMANのバッ クアップ・セットをクローニングして結果セットから非CDBをリストアする作業を伴うことの多い、かなり 複雑な一連の手順を使用するのと機能的に同等です。この操作も、Oracleホームを所有するオペレーティン グ・システム・ユーザーとしてログオンする必要があります。PDBのアンプラグ操作とPDBのプラグイン操 作に機能的にもっとも近い非CDBの同等の操作は、Oracle Data Pumpを使用したデータベース全体のエクス ポートおよびデータベース全体のインポートです。これらの操作でも、Oracleホーム所有者としてオペレー ティング・システムに認可されなければ、ダンプ・ファイルをコピーしたり移動したりできません。 PDBのアンプラグ操作とPDBのプラグイン操作は、PDBにOracleバージョンをパッチ適用するために も使用できると説明しました。この操作も、非CDBの場合はOracleホーム所有者としてオペレーティ ング・システムに認可される必要があります。 対照的に、PDBの作成、PDBのクローン作成、PDBのアンプラグ、PDBのプラグイン、およびPDBの削除を 実装するSQL文はクライアント・マシンから実行でき、必要なのは、適切な権限を持つOracle Databaseユー ザーとして認可されることだけです。 また、 文は、 目的とする操作のセマンティック要件をそのままアトミッ クな式にしたものです。さらには、データファイルの物理的なフル・コピーまたは転送を伴う場合を除き、 SQL文は数秒で完了します。そのうえ、これにはスナップショットPDBクローニングのケースが含まれます。 PL/SQLは単純に自動化の目的で使用できます。たとえば、PDBをクローズし、PDBのアンプラグとそ れに続く非破壊的なPDBの削除を実行し、PDBのプラグインを実行してからPDBをオープンするとい う一連の操作をカプセル化できます。Oracle SQL DeveloperやOracle Enterprise Manager 18などの ツールには、PDBをプロビジョニングするSQL文の機能がそのまま公開されています。 そのため、非常に強力な新しいパラダイムとしてデータベースのプロビジョニングに使用できます。 Oracle Data Guardで保護されたCDBに対するPDBのアンプラグ/プラグおよびクローニング スタンバイ・データベースは、プライマリ・データベースでのPDBの作成操作およびPDBのクローン 作成操作に自動的に対応します。しかし、プライマリ・データベースでのPDBのプラグイン操作の場 合は、スタンバイ・データベースでデータファイルを使用できる状態にする必要があります。これ は、トランスポータブル表領域のデータファイルの処理が必要になるのと同じことです。同様に、 keep datafilesオプションを付けたPDBの削除操作をPDBのアンプラグ操作に続けて実行した後は、ア ンプラグしたPDBのデータファイルを手動でスタンバイ環境から削除する必要があります。 -------------------------------------------------18 Oracle Enterprise Managerには、12.1より前の非CDBのために非CDBのプロビジョニング機能が公開されてい ます。ただし、サーバー側エージェントとオペレーティング・システム認可用のスキームをインストールして 使用していることが条件です。これに対応するPDBの機能の実装ははるかに簡単で、すでに説明したとおり、 PDBでの操作は非CDBよりはるかに高速に実行されます。 2013年6月 28ページ Oracle Multitenant 非CDBをPDBとして導入する方法 導入アプローチには、12.1の非CDBをPDBとして直接導入する方式と、非CDBのコンテンツをOracle Data Pumpなどを使用して空のPDBに導入する方式の2つがあります。 12.1の非CDBをPDBとして直接導入する方法 Oracle Database 12cは新しいマルチテナント・アーキテクチャと古い非CDBアーキテクチャの両方 をサポートしています。12.1より前の非CDBをPDBとして直接導入することはできません。そのため、 その場で通常の方法を使用してアップグレードする必要があります。実際の直接導入は、概念的に も現実的にも非常に単純です。非CDBを停止し、アンプラグしたPDBであるかのように処理するだけ です。アンプラグしたPDBは、PDBのアンプラグ操作によって生成される外部マニフェストを所有し ています。そのため、導入する非CDBは、停止する前に読取り専用モードにし、プロシージャ DBMS_PDB.Describe()を実行する必要があります。このとき、唯一の引数としてマニフェストへのパ スを指定しますが、これはPDBのアンプラグ操作を使用するときにパスを指定する必要があるのと同 じです。 導入する非CDBを停止したら、当然、非定型のRMANバックアップを実行します。 非CDBのデータファイルと手動で作成したマニフェストは、通常どおりにアンプラグしたPDBと同様 に処理できるため、ターゲットCDBに接続してPDBとしてオープンするだけです。ただし、この後す ぐに説明しますが、RestrictedステータスをYESに設定して開く必要があります。割当て制限を消費 するデータを保持している表領域は、トランスポータブル表領域を使用したOracle Data Pumpのイ ンポートと同様に、直ちに使用できるようになります。ただし、非CDBのデータ・ディクショナリだっ たものにOracleシステムの詳しい記述が保持されています。これはもう不要ですので、削除してしま う必要があります。 Restricted ステータスをYESに設定したまま、 noncdb_to_pdb.sql スクリプト （Oracleホームの下のadmin_directoryにあります）を実行する必要があります。これで、通常どおり にPDBをクローズしてオープンできます。 この導入方式を、アップグレード後に接続する導入アプローチ、と呼ぶことにします。 非CDBのコンテンツの導入 この項で説明するアプローチは、PDB/非CDB互換性保証により必ず可能です。ユーザーが作成した アーチファクトの大半は、Oracle Data Pumpのデータベース全体のエクスポートとインポートを使 用して非CDBから新しいPDBへ移行できます。12.1では、データベース全体のエクスポートとデータ ベース全体のインポートが新たにOracle Data Pumpでサポートされるようになったため、単一のコ マンドでトランスポータブル表領域を最大限に活用できます。この機能はフル・トランスポータブ ル・エクスポート/インポートと呼ばれます。この拡張は11.2.0.3にバックポートされています。この 導入方式を、Data Pump導入アプローチ、と呼ぶことにします。ただし、XMLスキーマ、ディレク トリ、publicに対して行われた権限付与など、一部の種類のデータベース・アーチファクトはOracle Data Pumpを使用して移動することができません。これらは非定型の方式を使用して移行する必要 があります。 2013年6月 29ページ Oracle Multitenant 導入する非CDBのサイズが比較的小さく、Oracle Data Pumpですべてのコンテンツを処理できる場 合は、Data Pump導入アプローチを使用したほうが、アップグレード後に接続する導入アプローチ を使用するより速い可能性があります。さらに、統合を実施するときには、古い設備から新しい設 備へアプリケーション・バックエンドを移動することが必要になる場合がよくありますが、異なる エンディアンネス間の移行の可能性があります。"異なるオペレーティング・システム、チップセッ ト、エンディアンネス間のアンプラグ/接続"（18 ページの）で説明したとおり、この使用例ではData Pump導入アプローチが唯一のオプションです。 または、Oracle GoldenGateレプリケーションを使用して新しいPDBに移入し、ソース非CDBで継続 する変更の追跡を続けます。その後、非CDBにOracleバージョンをパッチ適用するための一時ロジカ ル・スタンバイ方式とともに使用したのと同じカットオーバー・アプローチを使用して、クライア ント側のアプリケーション・コードを古い非CDBから新しいPDBに短い一時停止で移動できます。 2013年6月 30ページ Oracle Multitenant マルチテナント・アーキテクチャの動的側面： Oracleインスタンス、ユーザー、およびセッション この項では、RACインスタンスによってオープンされるのはCDB全体であるという事実の影響につい て説明します。 ユーザー、ロールおよび権限付与の共通性 CDBでは、ローカル・ユーザーと共通ユーザーを区別します。2種類が存在するという事実は、必然 的にPDB/非CDB互換性保証に由来します。これには次の2つの要件があります。 • 同じCDBに収容されている各PDBは、ユーザーが作成した（たとえば、Scottという名前の）ユー ザーを保持できます。この場合、それらは独立していますが、たまたま同じ名前を持っています。 • SysやSystemなど、オラクルが提供するユーザーは、目的と特性を一意に定義されドキュメント化 されたすべてのコンテナに存在する必要があります。 ローカル・ユーザーとローカル・ロール "マルチテナント・アーキテクチャの水平方向にパーティション化されたデータ・ディクショナリ" （14 ページの）で説明したとおり、特定のCDBに収容されているPDBごとにScottという名前のユー ザーを保持できます。そのようなユーザーはローカル・ユーザーであり、PDBのUser$データ・ディ クショナリ表だけに定義され、そのPDB内だけでローカル・ユーザーと認識されます（したがって、 当然、各PDBのScottには互いに異なるパスワードを設定できます）。このようになっていなければ、 PDB/非CDB互換性保証は遵守できません。同様に、ローカル・ロールは特定のPDBだけに定義され ます。 ローカル・ユーザーもローカル・ロールも、ルートには作成できません。 共通ユーザーと共通ロール 一方、特定のCDB内のあるPDBを使用するセッションは、同じCDB内の他のPDBを使用するセッショ ンと同じアーチファクト一式（オラクルが提供）を参照できる必要があります。これらのアーチファ クトには当然、SysやSystemなどのユーザーとDBAやSelect_Catalog_Roleなどのロールが含まれます。 SysとSystemは共通ユーザーで、DBAとSelect_Catalog_Roleは共通ロールです。共通ユーザーの名前 とパスワードはルートで定義されますが、変更されることはないため、そのCDB内のすべてPDBでは、 現在も将来も、同じ名前とパスワードでIDが認識されます。同様に、共通ロールはルートで定義さ れ、どこででも認識されます。 Sys.DBMS_OutputやSystem.Sqlplus_Product_Profileなどのオブジェクトも、同じ理由で、すべての コンテナに一意の定義で存在する必要があります。このようなオブジェクトは共通オブジェクトと 呼ばれ、ルートで定義されます 19。ユーザーは共通オブジェクトを作成できません。 -------------------------------------------------19 共通オブジェクトはObj$の単一行でPDBのディクショナリに表示されます。CDB$RootのObj$の対応する行と は名前で一致します（Owner、Object_Name、およびNamespaceでマッチング）。このような仕組みがあるた め、Dependency$の依存関係図がCDB$Rootの共通オブジェクトとPDBのローカル・オブジェクトの両方に及 び、Dependency$のファクトがObject_IDの値を使用して記録されるとしても、CDB間でPDBのアンプラグ/プ ラグを実行した後すぐにPDBを使用できるようになります。 2013年6月 31ページ Oracle Multitenant 権限および共通ロールの共通付与 あるPDBがカレント・コンテナであるときに権限またはロールを付与した影響は、そのPDB内の SysAuth$データ・ディクショナリ表とObjAuth$データ・ディクショナリ表に表れます。そのため、付与に よる影響は付与を実行したPDB内にとどまります。これは、権限受領者が共通ユーザーまたは共通ロールの 場合も同じです。したがって、特定の共通ユーザーまたは共通ロールは、PDBごとに異なる権限を付与され る可能性があります。ただし、PDB/非CDB互換性保証では、オラクルが提供する共通ユーザー（SysやSystem など）およびオラクルが提供する共通ロール（DBAやSelect_Catalog_Roleなど）に付与されている権限一式 が、CDB内のどのPDBでも永続的にまったく同じになっていることが求められます（ここでは、ユーザーが ベスト・プラクティスに準拠し、オラクルが提供するユーザーに対して権限またはロールを付与することも 取り消すこともしないと仮定しています。このベスト・プラクティスは、ユーザーが作成した共通ユーザー および共通ロールには適用されません）。これは正式にサポートされる必要があります。そうでなければ、 権限またはロールが特定のPDBだけで取り消される可能性があり、そうなると互換性が保証されなくなりま す。正式なサポートには特殊バージョンのgrant SQL文を使用します。-- コード_10に例を示します。 -- コード_10 grant Create Session to A_Common_User container = all これは、"すべてのコンテナ権限受領者に、この項目を永続的に付与したままにする"という意味です。 権限または共通ロールを共通に付与したり取り消したりする場合は、ルートをカレント・コンテナ にする必要があります。論理上、権限受領者はどこでも認識される必要があります。つまり、権限 受領者は共通ユーザーまたは共通ロールであることが必要です。さらに、付与された項目もどこで も認識される必要があります。つまり、項目はシステム権限またはオブジェクト権限（オラクルが 提供しているため、どこでも認識されます）または共通ロールであることが必要です。 ユーザーが作成した共通ユーザーと共通ロール ユーザーが作成した共通ユーザーのユースケースには、CDB全体、または複数のPDBの管理タスクを 実行する必要のある人を認可するための手段としての用法があります。この場合、ユーザーは名前、 パスワード、および監査の面で単一エンティティである必要があります。 これは、オラクルが提供するすべてのユーザーをロックして期限切れにし、代わりにユーザーが作成 したユーザーに必要なあらゆる管理タスクを実行できるようにするという、定着している12.1より前の ベスト・プラクティスを引き継いでいます。CDBでは、このベスト・プラクティスはユーザーが作成し た共通ユーザーに依存します。このようなユーザーは、12.1より前は、通常、オブジェクトを所有しま せん。とはいえ、所有することもあります。ただし、その場合のオブジェクトは特定の管理タスクを 安全な方法で実装するプロシージャなどです。そうしたオブジェクトはアプリケーション・バックエ ンドの実装の一部と見なされません。このことを理解すれば、CDBでは、ユーザーが作成した共通ユー ザーがルートのローカル・オブジェクトを所有する可能性があると推測できます。ユーザーが作成し た共通ユーザーがPDBのローカル・オブジェクトを所有することもできます。ただし、これは推奨しま せん。PDBのローカル・オブジェクトはローカル・ユーザーが所有する必要があります。 ユーザーが作成した共通ロールについても同様の懸念があります。 ユーザーが作成した共通ユーザーまたは共通ロールの名前はC##かc##で始まる必要があります。-- コード_11は、共通ユーザーを作成するときの構文です。 -- コード_11 2013年6月 32ページ Oracle Multitenant create user c##u1 container = all identified by p container = all句は共通ロールの作成にも使用されます。 ローカル・ユーザーは共通ユーザーのスキーマでシステム権限を実行できない点に注意してください。 サービスとセッション Oracle Netを使用して非CDBに対してセッションを作成するには、5つのファクト（リスナーの場所、 リスナー・ポート、サービス名、ユーザー名、パスワード）を指定する必要があります。最初の2つ で実行中のリスナーが識別され、指定したサービスをそのリスナーがその時点でサポートしている 限り、対象となる非CDBがオープンされているRACインスタンスのいずれかに対してフォアグラウン ド・プロセスが開始されます。ここまで、フォアグラウンド・プロセスはSysとして実行されていま す。次に、User$表を問い合わせ、ユーザー名とパスワードが有効かどうか、また指定されたユーザー がCreate Session権限を持っているかどうかを確認します。それらが有効な場合は、指定されたユー ザーがセッション・ユーザーになり、クライアントからデータベース・コールを発行できるように なります。有効でない場合はフォアグラウンド・プロセスが終了し、クライアントは当然、接続さ れないままとなります。 少し付け加えることがありますが、CDB内の特定のPDBに対してセッションを作成する方法にもこの 同じ説明が適用されます。重要な点は、同じ5つのファクトを同じ方法で指定するところです。Sys として実行するフォアグラウンド・プロセスが起動するとき、カレント・コンテナはルートです。 このプロセスは、ここまでセッションの作成を試行してきたサービスのプロパティを参照できます。 12.1の新機能ですが、サービスには、認可が完了したときにセッションのカレント・コンテナとする PDBを指定するプロパティがあります（これがnullの場合は、新しいセッションのカレント・コンテ ナをルートにすることを意味します）。この時点でセッションのコンテナは指定されたものに切り 替わり、このときだけローカルのUser$表を問い合わせて、指定されたユーザー名とパスワードが有 効かどうか、また指定されたユーザーがCreate Session権限を持っているかどうかを確認します。そ の後の成功/失敗の処理は非CDBの場合と同じです。 必要なのは、指定したユーザーが、サービスのプロパティで指定したコンテナで認識されているこ とだけです。ユーザーがローカル・ユーザーか共通ユーザーかは問題ではありません。 確立されたセッションでのセッションのカレント・コンテナの変更 alter session set container SQL文は、指定したターゲットにカレント・コンテナを変更します。-- コー ド_12に例を示します。 -- コード_12 alter session set container = PDB_2 この文を発行するユーザーはターゲット・コンテナに認識されている必要があり、そこでの Set Containerシステム権限を持っている必要があります。このユーザーは当然、このSQL文が発行され るコンテナにも認識されている必要があります。つまり、共通ユーザーだけがエラーなしでこの文 を使用できるということです。このSQL文の結果が成功ならば、コンテナからコンテナへの移行が単 発で行われます。履歴は重要でないため、維持されません。 終了していないトランザクションが別のコンテナに存在している間は、コンテナ内でトランザク ションを開始できません。 alter session set container SQL文は、トップレベルのサーバー・コールとしてのみ有効です。 2013年6月 33ページ Oracle Multitenant 12.1の新機能であるDBMS_Sql.Parse()のオーバーロードにより、PL/SQLコード内でalter session set containerを厳格な"トランポリン"方式で実行できるようになりました。そのため、この方式を使用 するこのアプローチはDBMS_Sql.Parseトランポリンと呼ばれます。Container仮パラメータには、解 析 さ れ る 単 一 の SQL 文 の 場 所 を 指 定 し ま す 。 こ の 文 が 終 了 す る と 、 カ レ ン ト ・ コ ン テ ナ は DBMS_Sql.Execute()が起動されたときのコンテナに必ず自動的にリセットされます。リモートから実 行したSQL文でエラーが発生した場合も、同じことが行われます。-- コード_13に例を示します。 -- コード_13 DBMS_Sql.Parseトランポリンは、開始するコンテナがCDB$Rootの場合のみ有効です 20。 これらのルールにより、ローカル・ユーザーによって作成されたセッションは、接続時に使用した サービス名で指定したPDB以外に接続できないことが保証されます。つまり、ローカル・ユーザーに とっては、同じCDB内のPDBについてのPDB間独立モデルと、 同じオペレーティング・システム・ユーザーが所有する同じプラットフォーム上の非CDB間独立性モ デルは同じなのです 21。 CDBの管理には、非定型SQL*Plusスクリプトでalter session set containerを使用するのが便利です。 こうすると、CONNECTコマンドの繰返し使用を避けられ、パスワードの安全性を心配する必要がな くなります。DBMS_Sql.Parse()を使用するアプローチは、PL/SQLを使用して連携されるCDBの管理タ スクに便利です。 論理的に仮想化されるSGA データベース内統合を実施すると統合密度が向上します。これは、RACインスタンスごとにすべての アプリケーション・バックエンドが同じSGAを共有するためです。スキーマベースの統合を使用する と、すべてのアプリケーション・バックエンドおよびOracleシステムを反映する項目がSGAに移入さ れますが、移入されるだけで同様の効果は得られません。そういうものだと気付くのは、これについ て検討した人だけです。PDBベースの統合を使用すると、各項目（代表的なものはデータ・ブロック や子カーソルのようなライブラリ・キャッシュ構造体など）にその来歴が注釈として付けられます。 -------------------------------------------------20 21 有効でない場合は、通常のPL/SQLルールが適用されます。すなわち、コードは3種類（無名ブロック、実行者 権限ユニット、または定義者権限ユニット）のいずれかである可能性があり、カレント・ユーザーに基づいて 権限がチェックされるだけです。 この原則を補強するために、あるPDBのオブジェクトを別のPDBで発行されたSQL文から直接参照したり、別 のPDB内のオブジェクトを定義するコードの一部を直接参照したりする方法は用意されていません。PDB名の 相互解決を可能にする3部構成の名前付けスキーム（PDB名、スキーマ名、オブジェクト名）は意図的に作成し ていません。あるPDBから別のPDBのオブジェクトを参照する必要がある場合は、データベース・リンクを使 用する必要があります。 2013年6月 34ページ Oracle Multitenant つまり、SGAは論理的に仮想化されます。これは重要です。データ・ディクショナリが物理的に仮想 化されることでプラグ機能が実現され、SGAが論理的に仮想化されることでデータベース内統合の物 理法則（統合密度の向上）が維持されるからです。このことを示しているのが下の図9です。 図9 PDBとRACインスタンスとのアフィニティゼーション。右側の矢印は、各PDBと各RACインスタンスとのアフィニティゼーションを色で示しています。 特定のアプリケーション・バックエンドを操作するユーザーをサポートするセッションと特定のRAC インスタンス・セットとの間にアフィニティ関係を構築する方法を、スキーマベースの統合を使用 して実践したユーザーもいます。このユーザーは、特定のアプリケーション・バックエンド専用の セッションを開始するときは特定のサービス（1つまたは複数）を使用する、という規則を自ら課し て実行しています。 この規則はマルチテナント・アーキテクチャで正式にサポートされています。PDBのモードは、READ WRITE、READ ONLY、またはMOUNTEDに設定できます。モードはパフォーマンス・ビューの列 gv$PDBs.Open_Modeに表示されます。各RACインスタンス内の各PDBに異なるモードを明示的に設 定することもできます。MOUNTEDモードにすると、PDBはほぼアイドル状態になります。これは、 RACインスタンスではCDB全体が処理されるからに他なりません。ですから、特定のPDBだけのため に停止しようとするのは無意味です。 2013年6月 35ページ Oracle Multitenant Open_Modeはalter pluggable database SQL文を使用して設定できます。カレント・コンテナがルー トの場合はどのPDBにも設定でき、カレント・コンテナが特定のPDBの場合はそのPDBに設定できま す。互換性の関係で、SQL*PlusコマンドのSTARTUPとSHUTDOWNは、カレント・コンテナがPDBの場 合に発行できます。これらのコマンドは対応するalter pluggable database SQL文に変換されます。 Open_Modeに対向して、RestrictedステータスもNOまたはYESに設定できます。PDBのOpen_Mode とRestrictedステータスの組合せは5つあります（Open_ModeがMOUNTEDの場合、Restrictedステー タスに設定できるのはnullのみです）。alter pluggable database SQL文でキーワードforceを使用す ると、-- コード_14に示すとおり、任意の組合せから別の任意の組合せに直接移動できます。 -- コード_14 -- PDB_1の最初の状態はREAD WRITEモードです alter pluggable database PDB_1 open read only force この例では、PDB_1に接続して読取り専用以外のトランザクションに関わっているセッションはす べて中断され、トランザクションはロールバックされます。そのため、非CDBの同様のモード変更ルー ルと比べ、使い勝手が向上していると言えます。 あるRACインスタンスでSGAが変更されると、複数のSGAにキャッシュされている情報が食い違わな いようにするために、他のRACインスタンスに通知が送信されますが、マルチテナント・アーキテク チャではあまり頻繁に通知が送信されません。特定のPDBがオープンされていないRACインスタンス に対して、そのPDBがオープンされているRACインスタンスにキャッシュされている項目への変更を 通知しても意味がないためです。 そのため、マルチテナント・アーキテクチャには、アプリケーション・バックエンドとRACインスタ ンスとのアフィニティゼーションを宣言するための単純なモデルが用意されています。スキーマ ベースの統合を使用する場合は手動で連携させますが、このモデルで実装するほうが信頼性が高く、 パフォーマンスも向上します。この概念については"PDBとRACインスタンスのアフィニティゼー ション"（45 ページの）で詳しく説明します。 データ・ディクショナリ・ビューとパフォーマンス・ビュー PDB/非CDB互換性保証とは、PDBがカレント・コンテナのときにデータ・ディクショナリ・ビュー とパフォーマンス・ビューを問い合わせた場合は、そのPDB内で定義されたアーチファクトとルート 内で定義されたアーチファクトに関する情報だけが表示されることを意味します。たとえば、PDB_1 にサンプル・スキーマがインストールされていて、PDB_1がカレント・コンテナの場合は、-- コー ド_15に示す問合せを実行すると、 -- コード_15 2013年6月 36ページ Oracle Multitenant 次に示す結果が得られます。 ただし、これにはPDB_2やCDB内の他のPDBで定義されたオブジェクトは含まれません。 同様に、PDB_1がカレント・コンテナの場合にv$Sqlを問い合わせると、PDB_1がカレント・コンテ ナのときに発行したSQL文に関する情報のみが表示されます。 マルチテナント・アーキテクチャでは、カレント・コンテナがルートの場合にデータ・ディクショ ナリ・ビューとパフォーマンス・ビューを問い合わせたときの結果は新しいルールに基づいて表示 されます。結果は、現在オープンされているすべてのコンテナで出現した問題のビューの結合にな る可能性があります。ビューには12.1で新たに追加されたCon_ID列があるため、行は区別されます。 これは、CDB全体で1つのシステム・イメージをサポートする、というビジネス目標に適合します。 たとえば、ユーザーが定義したネーミング規則への違反がないかどうかを簡単に監視できます。（名 前には一重引用符、二重引用符、セミコロン、疑問符などの特殊文字を一切含めないことを規則に しているユーザーもいます）。他の用法としては、もっとも長時間にわたって実行されているSQL 文をCDB全体から見つけることを目的とするものが考えられます。 パフォーマンス・ビューにはCon_ID列が追加されているだけです。しかし、データ・ディクショナ リ・ビューの場合は、CDB_で始まる名前の新しいファミリー以外ではCon_ID列が公開されていませ ん。これらにより、DBA_データ・ディクショナリ・ビューの概念は拡張されていますが、All_およ びUser_で始まるデータ・ディクショナリ・ビューには同様の拡張が行われていません。 複数のコンテナの行を返す可能性があるビュー（すなわち、新たにCon_ID列が追加されたビュー） は、まとめて container_dataビュー と呼ばれます。カレント・コンテナがPDBの場合は、どの container_dataビューでも、Con_IDの値がそのPDBまたはCDB全体を示す行のみが表示されます。た だし、カレント・コンテナがルートの場合は、多数のコンテナの行がcontainer_dataビューに表示さ れる可能性があります。すでに説明したとおり、ルートにはローカル・ユーザーを作成できません。 そのため、Con_IDに複数の個別値を持つcontainer_dataビューから得られた結果を参照できるのは 共通ユーザーだけです。特定の共通ユーザーがcontainer_dataビューで結果を参照できるコンテナ一 式は、ユーザーの属性（Alter User SQL文を使用して設定）によって決まります。 もっとも少ない例としては、-- コード_16に示すように、たとえば指定した2つのPDBについて特定 のcontainer_dataビューを1つだけ、この属性で指定することができます。 -- コード_16 -- c##u1からCDB$Root、PDB_1、PDB_2の -- CDB_Objectsのデータだけを参照できるようにします alter user c##u2 set container_data = (cdb$root, pdb_001, pdb_002) for Sys.CDB_Objects container = current 2013年6月 37ページ Oracle Multitenant このSQL文を使用できるのはカレント・コンテナがルートの場合のみで、この属性はルートでローカ ルに設定することしかできません。また、リストには必ずCDB$Rootが含まれている必要があります。 逆に、-- コード_17に示すように、（Oracle Databaseリリースが異なっても）永続的にすべてのコ ンテナについてすべてのcontainer_dataビューを永続的に指定することもできます。オラクルが提供 するSysやSystemなどのユーザーはこの方法で構成されます。 -- コード_17 -- すべてのcontainer_dataビューのすべてのコンテナのデータを -- c##u2から永続的に参照できるようにします alter user c##u2 set container_data = all container = current 2013年6月 38ページ Oracle Multitenant CDB単位の選択肢とPDB単位の選択肢 統合するということは、急務である資本コストおよび運用コストの削減を実現させるために、個別 に管理されていたアプリケーション・バックエンドにそれまで認められていた自立性の一部を手放 さざるを得なくなるということです。この項では、CDB全体に対してのみできる選択について説明し、 残りの選択肢（PDB単位で個別に実行できる選択肢）についていくつか例をあげます。 CDB全体に対してのみできる選択 Oracle Databaseソフトウェア・バージョン、およびプラットフォームの指定 スキーマベースの統合を使用する場合と同様、集中統合の概念では、多数の個別アプリケーション・ バックエンドが同じデータベースに収容され、（RACインスタンスごとに）同じSGAと同じバックグ ラウンド・プロセス一式が共有されます。つまり、同じCDB内にあるPDBはすべて同じOracle Database ソフトウェア・バージョンになっている必要があるということです。同じCDB内にある異なるPDBを 異なるOracle Databaseソフトウェア・バージョンにすることができるかという質問は、同じ非CDBに ある異なるスキーマを異なるOracle Databaseソフトウェア・バージョンにすることができるかという 質問と同じくらいの意味しかありません。つまり、これらのデータベース内統合モデルのいずれでも、 統合されたすべてのアプリケーション・バックエンドに対して選択できるプラットフォームの種類お よびオペレーティング・システムの種類とバージョンは1つしかないということです。 Oracleバージョンのパッチ適用にアンプラグ/プラグ・パラダイムを使用すると、使用しない場合は CDB全体が特定のOracle Databaseソフトウェア・バージョンになってしまうことから発生する問題 が発生しなくなります。また、スキーマベースの統合を使用した場合は、アプリケーション・バッ クエンドと、それを収容する非CDBが稼働するプラットフォームおよびオペレーティング・システム の種類とバージョンとの関係が拘束されますが、このパラダイムによって移動性がもたらされるた めこの拘束がゆるくなります。 spfile、制御ファイル、パスワード・ファイル これらのファイルはCDB全体で共通です。つまり、PDBは文字どおり独自のspfileを所有できません。 一部のパラメータ値はalter systemを使用してPDBのスコープ内で永続的に設定でます。これについ ては、"PDBで設定できる初期化パラメータとデータベース・プロパティ"（42 ページの）で説明し ます。それらは適切に維持されますが、spfileでは実際には維持されません。また、PDBをオープン するときにpfileを指定することはできません。したがって、PDBのスコープ内でalter systemを使用 して具体的に設定されたパラメータ値のダンプが必要な場合は、それを実行するSQL問合せを記述す る必要があります。同様に、これらの値を設定するには、一連のalter system SQL文をプログラムに する必要があります。 Oracle Data Guard、RMANバックアップ、REDO、およびUNDO スキーマベースの統合を使用したユーザーは、運用コストの大幅な削減を実証しています。なぜな ら、統合前のように個々のアプリケーション・バックエンドごとに独立したタスクとしてOracle Data Guardを管理するのではなく、多数の異なるアプリケーション・バックエンドを収容する単一の非 CDBに対してOracle Data Guardを設定して運用できるからです。これは、一元管理の原理の例とし てよくあるものです。同様に、多数の異なるアプリケーション・バックエンドに使用できるOracle RMANの計画バックアップ体制を1つだけ運用することで、運用コストを削減しています。ただし、" 統合密度の最大化に向けた取組み"（5 ページの）でも触れたように、これはアプリケーション・バッ 2013年6月 39ページ Oracle Multitenant クエンドのポイント・イン・タイム・リカバリのソリューションとして一般的に使用することがで きません。この件については"PDBのための非定型のRMANバックアップ"（42 ページの）で説明し ます。 Oracle Data GuardでもRMANバックアップでもREDOログを使用します。Oracle Data Guardでは REDOをスタンバイ・サイトに絶えず適用します。RMANバックアップでは、バックアップ時刻から ロールフォワードして要求されたリストア時刻までリストアを行う場合にREDOを使用します。その ため、PDBベースの統合でもスキーマベースの統合と同じ一元管理によるコスト削減効果を得るため に、CDB全体で1つのREDOストリームを持ちます。つまり、SGAの場合と同様、REDOログは論理的 に仮想化されているのです。すなわち、各REDOログ・エントリには、そこに記録されている変更が 発生したコンテナの識別子が注釈として付けられます。REDOとUNDOはワンセットであるため、RAC インスタンスごとにCDB全体で1つのUNDO表領域を持ちます。したがって、UNDOも論理的に仮想 化されます。すなわち、ここでも、各UNDOレコードには発生元のコンテナの識別子が注釈として付 けられます。次の2点は、パフォーマンス上の影響に関する記述です。 • 第1に、この点における状況は、PDBベースの統合を使用する場合、スキーマベースの統合を使用 する場合と同じです。また、ユーザーはスキーマベースの統合ではパフォーマンスが損なわれな いことを実証しています。大局的な見地から言えば、他の要因が作用しています。特に顕著なの は、2つのデータベース内統合モデルのいずれを使用する場合も、一連のアプリケーション・バッ クエンドははるかに少ない総数のバックグラウンド・プロセスで処理されていること、また、各 アプリケーション・バックエンドが個別にサイズ指定された（そのため個別に制約をかける）独 自のSGAを持つ場合より、単一のSGAがそれらすべてに共有されている場合のほうが、アプリケー ション・バックエンドは連携してはるかに効果的にメモリを使用することです。 • 第2に、新しいREDO内索引付けスキームおよびUNDO内索引付けスキームにより、関連するPDB のレコードへのアクセスは高速化されます。さらに、REDOおよびUNDOを持つ論理的に仮想化さ れた個々の"パーティション"は独立して機能するため、同時プロセスは実際には互いを待機せず にパーティションにアクセスできます。 統合によって投資収益率を向上させようとするユーザーは通常、独自の統合候補の代表モデルを使 用して実証的な調査を独自に実施します。 キャラクタ・セット マルチテナント・アーキテクチャでは、実際にはPDBごとに独自のキャラクタ・セットを設定できま す。ただし、そうすると一元管理のメリットが損なわれます。 また、ここ数年で現れている傾向として、膨大な数のアプリケーションが国際的かつ多言語のユー ザー・ベースを持つようになっています。そして、これは、クライアント側の処理がUnicodeで実行 される割合が増加し続けていることを反映しています。つまり、データがUnicodeでデータベースに 格納されていない場合は、クライアントとデータベースの間でデータが何度も変換され、効率が悪 くなるということです。 そのため、CDB全体に対してのみキャラクタ・セットを決定できるようにしました。したがって、 CDBのキャラクタ・セットとしてはUnicode（AL32UTF8）を使用することをお薦めします。 もちろん、アプリケーション・バックエンドで特定のキャラクタ・セットが使用されているのにコ ストの関係で作成し直すことができないレガシー・アプリケーションについての問題は残ります。 それぞれ独自のキャラクタ・セットを使用して作成した複数のCDBを同じプラットフォーム上に保持 できるという事実は、ここで活かされます（これは、より一般的な原則の一例にすぎません。複数 2013年6月 40ページ Oracle Multitenant のCDBを同じプラットフォーム上に保持する理由としては、それぞれのOracle Databaseソフトウェ ア・バージョンを変えられるようにする、というのがもっともわかりやすいものです）。 CDB全体の初期化パラメータとデータベース・プロパティ v$System_Parameterビュー・ファミリーには、12.1の新しい列（IsPDB_Modifiable）があり、設定 できる値はFALSEまたはTRUEです（IsPDB_ModifiableをTRUEに設定したパラメータについては"PDB で設定できる初期化パラメータとデータベース・プロパティ"（42 ページの）で説明します）。約 200のパラメータでIsPDB_ModifiableがFALSEに設定されています。これらは具体例の一部です。 このリストは一元管理テーマにしたものです。 すでに説明したNLS_CHARACTERSETを除き、Database_Propertiesビューにリストされている他のすべ てのプロパティは、カレント・コンテナがPDBの場合はalter database SQL文を使用して設定できます。 AWRレポート CDB全体のAWRレポートを作成できます。また、このレベルで計画レポートが実行されるものと想 定しています。単一のアプリケーション・バックエンドのスコープ内で非定型のパフォーマンス調 査をできるようにするために、特定のPDBのAWRレポートを作成することもできます。 PDBごとに変えることができる選択肢 PDBのポイント・イン・タイム・リカバリ もっとも注目すべきPDB単位の自由は、同じCDB内のピアPDBの可用性を妨げずにPDBのポイント・ イン・タイム・リカバリを実行できることです。また、この能力は、スキーマベースの統合とPDB ベースの統合を差別化するもっとも大きな要因の1つです。前者には、アプリケーション・バックエ ンド単位のポイント・イン・タイム・リカバリというビジネス目標を容易に達成できる方法はあり 2013年6月 41ページ Oracle Multitenant ません。flashback pluggable databaseコマンドは、12.1ではサポートされません。 PDBのための非定型のRMANバックアップ 一元管理の原則の効果がもっともよく現れるのは、すでに説明したように、通常はOracle RMANの計 画バックアップをCDBレベルで実行したときです。しかしながら、特定のPDBに対して非定型のバッ クアップを実行するのが便利な場合もあります。これについては、PDBのアンプラグ・コマンドと （データファイルを保持したままの）PDBの削除コマンドを組み合わせて使用する方法と併せて、 "PDBの削除"（27 ページの）で説明しました。 alter system flush Shared_Pool "マルチテナント・アーキテクチャの動的側面：Oracleインスタンス、ユーザー、およびセッション" （31 ページの）で説明したとおり、ブロック・バッファ内のデータ・ブロックおよびライブラリ・ キャッシュ構造体にはコンテナ識別子が注釈として付けられます。そのため、カレント・コンテナ がPDBの場合は、alter system flush Shared_Poolの影響が直ちに及びます。 PDBで設定できる初期化パラメータとデータベース・プロパティ カレント・コンテナがPDBの場合は、v$System_ParameterビューでIsSes_ModifiableとIsSys_Modifiable が両方ともFALSE以外に設定されているすべての初期化パラメータを、alter systemを使用して設定で きます。つまり、該当するパラメータはすべてIsPDB_ModifiableがTRUEになっています。さらに、 IsSys_ModifiableがFALSEではなくIsSes_ModifiableがFALSEになっている他の一部のパラメータも、 PDBのスコープ内でalter systemを使用して設定できます。これは12.1では比較的小さいリストです： scope句（scope=memory、scope=spfile、またはscope=both）は、IsSys_Modifiableに設定可能な 他の値（IMMEDIATEおよびDEFERRED）から予測されるとおりに作用し、要求があれば値は永続化 されます。PDB/非CDB互換性保証を遵守するため、定着しているalter systemの構文はそのままにし ました。ただし、永続性メカニズムは実際にはspfileではありません。代わりに、適切なデータ・ディ クショナリ表に保持され、PDBをオープンしたときにそのようなPDB固有の値を両方とも有効化でき るようになっています。また、PDBをアンプラグ/プラグすると、値はPDBとともに移動します。 ORA-65040エラー Oracle Databaseは非常に広範囲にわたるSQL文をサポートしています。これらの中には、特殊な状 況下でデータベース全体を管理する管理者のみに使用されるものもあります。CDBの場合は、管理者 専用のこうしたSQL文のごく一部をPDBから発行することができません。発行すると、ORA-65040： プラガブル・データベース内からの操作は許可されていません、というエラーが発生します。これ は、意図的なものです。PDB/非CDB互換性保証はこの観点で解釈する必要があります。SQL文はすべ て、クライアント側のコードから自動的に発行できます。しかし、Oracle Enterprise Managerのよう に 管理ツール などと呼ばれるのではなく、 アプリケーション と呼ばれるにふさわしいクライアン ト・コードからは、ORA-65040を発生させる文は発行されません。インストールの自動化と呼ばれ るクライアント・コードであっても、ベスト・プラクティスに準じている場合は、そのような文は 2013年6月 42ページ Oracle Multitenant 発行されないはずです。 CDB内でのPDB間リソース管理 同じプラットフォーム上に収容されている異なるアプリケーション・バックエンドを使用するセッ ションは、次のコンピューティング・リソースを奪い合います。 • 同時セッション数 • CPU • Oracleパラレル・サーバー・プロセスを使用する能力 • ファイルI/O • SGAメモリの使用およびPGAの割当て能力 • ネットワークI/O これら1つ1つのリソースに対する競合を自分たちで完全に制御することに決めるユーザーもいます。 したがって、そのようなユーザーはオペレーティング・システムの仮想化を利用してアプリケーショ ン・バックエンドごとに専用の仮想マシンを構築し、その中の専用の非CDBで各アプリケーション・ バックエンドをホストします。しかし、このスキームでは一元管理による運用コストの削減効果が 完全に無意味になります。多くのユーザーは、一元管理による削減効果を最優先することで投資収 益率が最大化されることがわかったため、スキーマベースの統合を使用しています。 スキーマベースの統合のコンテキスト内でResource Managerを使用することは可能です。ただし、 それには、アクセスする目的で作成されたサービス以外を使用して各アプリケーション・バックエ ンドにアクセスしない、という規律を設け、慎重に計画したうえで人が監視する必要があります。 言うまでもなく、問題は、スキーマベースの統合を使用する場合に個々のアプリケーション・バッ クエンドの境界線を引く方法を知っているのは人間だけであり、Oracle Databaseはこれについて何 も把握していない、ということです。PDBベースの統合を使用する場合は、人がOracle Databaseに 境界線の場所を教えられる、強力で宣言的なメカニズムをPDBが備えています。すなわち、各アプリ ケーション・バックエンドは専用のPDBにインストールされ、PDBに収容されるアプリケーション・ バックエンドの数は1を超えません。 マルチテナント・アーキテクチャではResource Managerが機能拡張され、CDBに格納されているPDB 間のリソース競合を管理する計画をCDBレベルで作成できます。 12.1のCDBレベルの計画で制御されるコンピューティング・リソース 12.1では、Resource ManagerのCDBレベルの計画で次のリソースが制御されます。 • 同時セッション数 • CPU • Oracleパラレル・サーバー・プロセスを使用する能力 • ファイルI/O — ただし、Exadata上のみ ただし、次のリソースは制御されません。 • SGAメモリの使用およびPGAの割当て能力 2013年6月 43ページ Oracle Multitenant • ネットワークI/O PDBとRACインスタンスのアフィニティゼーション 22は、SGAメモリおよびPGAメモリの競合を制御 するときのおおまかなアプローチ単位として使用できます。 シェアとキャップ・モデル Resource Managerには、2つの概念（シェアとキャップ 23）に基づく業界標準モデルが実装されてい ます。このスキームでは、各競合者に1から任意の正の整数の間のシェア数を割り当てます（ただし、 おおよそ10を超えると効果がなくなる可能性があります）。通常、同時にアクティブになるのは一 部の競合者だけです。アクティブな競合者はそれぞれ、管理対象リソースのt分のnを取得します（n は特定の競合者に割り当てられたシェア数で、tは現在アクティブな競合者全体に割り当てられてい るシェアの合計です）。オプションで、任意の競合者にキャップを設定することができます。キャッ プは0から1までの範囲の割合です（ほとんどの場合、パーセント値で表されます）。cというキャッ プを設定された競合者は、シェアの計算結果が何であろうと、この割合を超える管理対象リソース を取得しません。もちろん、シェア計算の瞬間的な結果によっては、キャップを設定されたそのよ うな競合者の取得するリソースが減ることもあります。 シェアという概念の価値ははっきりしており、リソース管理には必須の条件です。キャップという 概念の価値は、競合者の数が徐々に増えて、計画していたなんらかの数に達したときにわかります。 キャップとは、誤った見込みを途中で設定することなく、最終的な計画のために確実に余裕を残す ためのものです（ユーザーはパフォーマンスが向上すると喜びます。これは、あるマシンからより 高性能なマシンにキャップなしでアプリケーションを移動したときに、それがそこで最初にホスト される唯一のアプリケーションだった場合に見られる現象と同じです。しかし、忘れっぽいのがユー ザーです。そのため、統合マシンに移動されるアプリケーションが増えるに連れ、パフォーマンス が確実に低下していることだけに気付き、それだけを思い出します。したがって、統合マシンに移 動する最初のアプリケーションのパフォーマンスは、統合が完了したときに見込まれるレベルに制 限しておくほうがよいのです）。 PDB間のリソース管理については、PDBの作成時にデフォルトでシェアが1つ割り当てられ、キャッ プは設定されません。 12.1のCDBレベルの計画によるセッション、CPU、Oracleパラレル・サーバー・プロセス、 およびファイルI/Oの管理方法 計画を設定または変更すると、その影響はすべてのカレント・セッションに即座に伝わります 24。 -------------------------------------------------22 これについては"PDBとRACインスタンスのアフィニティゼーション"（45ページ）で詳しく説明します。 23 このトピックについての学術論文で、1995年に発表されたものが次の場所にあります。 http://people.cs.umass.edu/~mcorner/courses/691J/papers/PS/waldspurger_stride/waldspurger95stride.pdf また、オペレーティング・システム仮想化ソフトウェアのベンダーが運営している開発者フォーラムの記事が 次の場所にあります。 http://communities.vmware.com/docs/DOC-7272 キャップという概念は、リソース使用率の制限と呼ばれることもあります。 24 計画の設定にはalter system set resource_manager_plan = My_Planを使用します。"PDBで設定できる初期化パ ラメータとデータベース・プロパティ"（42ページ）で説明したとおり、resource_manager_plan初期化パラメー タはコンテナ・スコープを使用して設定できます。そのため、CDBレベルの計画を設定するには、カレント・ 2013年6月 44ページ Oracle Multitenant 同時セッション数が対象となるのはキャップ設定のみであり、ここではシェアという概念に意味は ありません。実際、セッションのキャップはセッションの初期化パラメータを使用して設定します 25。 CPUとファイルI/Oは、前述したシェアとキャップのメカニズムを使用して管理されます。きめ細か いセッションのスケジューリングが100ミリ秒間隔で実行されます。 -- コード_18は、PDB_1に1つ、PDB_2に3つのシェアを割り当てるCDBレベルの計画を構成する方法 を示しています。 -- コード_18 また、-- コード_19は、CDBレベルの計画を変更し、PDB_1に2つ、PDB_2に5つのシェアを割り当て、 それぞれに20%と50%のキャップを設定する方法を示しています。 -- コード_19 Oracleパラレル・サーバー・プロセスを使用する能力は、同じシェア・モデルで管理されます。 parallel_degree_policy初期化パラメータはAUTOに設定する必要があります。そうすると、マシンが ビジー状態であり続けるほどのSQL文をパラレルに実行しても、SQL文のキューイングで並列度がダ ウングレードされることがなくなります。キャップの概念には独立した別々のパラメータ設定があり ます。DBMS_Resource_ManagerのCreate_CDB_Plan_Directiveサブプログラムでparallel_server_limit パラメータを使用する方法と、同じプロシージャのUpdate_CDB_Plan_Directive サブプログラムで new_parallel_server_limitパラメータを使用する方法です。 PDBとRACインスタンスのアフィニティゼーション "マルチテナント・アーキテクチャの動的側面：Oracleインスタンス、ユーザー、およびセッション" （31 ページの）で説明したとおり、各PDBのOpen_Modeは、各RACインスタンス内で個別に（すな わち別々に）MOUNTED、READ ONLY、またはREAD WRITEに設定できます。たとえば、8個のPDB を持つCDBが8個のOracleインスタンスを持つRACデータベースとして構成されている場合は、各 PDBをオープンできるRACインスタンスは1つだけであるため、各RACインスタンスではPDBが1つだ コンテナがルートのときにalter systemを発行する必要があります。 25 "PDBで設定できる初期化パラメータとデータベース・プロパティ"（42ページ）で説明したとおり、カレント・ コンテナがPDBの場合はalter system SQL文を使用してセッションの初期化パラメータを設定できます。 2013年6月 45ページ Oracle Multitenant けオープンされます。このスキームを使用すると、リソースの独立性を最大化することができます。 ただし、PDBベースの統合の特徴（でありスキーマベースの統合の特徴でもある）高い統合密度を実 現するSGAおよびバックグラウンド・プロセスの共有を妥協することにもなります。 PDBとRACインスタンスのアフィニティゼーションのより実際的な用法としては、200個以上のPDB を持つCDBで、たとえば（処理能力の要件の面で）上位4分の1のPDBに75%のRACインスタンスとの アフィニティ関係を構築し、残りの4分の3に25%のRACインスタンスとのアフィニティ関係を構築す る使用方法があります。 2013年6月 46ページ Oracle Multitenant CDB内の単独PDBと非CDBの比較 特定のプラットフォームをそれ専用にする必要があるほどアプリケーション・バックエンドのス ループット要件が高いとします。アプリケーション・バックエンドのインストール先は、非CDBにす ることも、CDB内の唯一のPDB（シードPDBを除く）であるPDBにすることもできます。後者の構成 を単独PDBと呼ぶことにします。これはシングルテナント構成と呼ばれることもあります。 どのような形であれ、シングルテナント構成より非CDBを選択したほうがよいのでしょうか。 答えはきっぱりと、いいえであることをお約束します。PDB/非CDB互換性保証では、機能上の違い は何もないとされています。Oracle Corporationのエンジニアが慎重にテストしたところ、この主張 が証明され、パフォーマンスの違いがないことも実証されました。 さらに興味深いのは逆の視点からの質問で、シングルテナント構成は非CDBを選択するよりよいので しょうか、というものです。 これに対する答えは、はいです。PDBの数が1を超えない場合でも、新しいマルチテナント・アーキ テクチャから次のような大きなメリットを得られます。 • アンプラグ/プラグは、機能面で第3世代のOracle Data Pumpとして使用できる。 • 新規作成した空のCDBのアンプラグ/プラグを、新しいパラダイムとしてOracleバージョンのパッ チ適用に使用できる 26。 このことに気付けば、Oracle Multitenantオプションの指定を決断し、特定のCDB内に2～252個のPDB を保持できるようにすることになるでしょう（シードPDBは、保持できる252個のPDBの1つにはカウ ントされません）。 Standard Edition、Standard Edition One、およびEnterprise Editionのいずれでも、追加コストなしで シングルテナント構成、すなわちマルチテナント・アーキテクチャを使用する選択ができます 27。 -------------------------------------------------26 ホット・クローニング（今後のリリースでサポートされるようになった場合）は次のようなアプローチに使用 できます。同じOracle Databaseソフトウェア・バージョンで"ステージング"CDBにホット・クローニングし、 作成されたときのSCNを記録します。次に、新しいバージョンのCDBにアンプラグ/プラグし、ソースPDBと同 期し、Oracle GoldenGateレプリケーションを使用して追跡します。これは、使い勝手が大幅に向上した一時 ロジカル・スタンバイを使用するのと機能的に同じになるでしょう。 27 正式な使用条件については、Oracle Database 12cのライセンス・ガイドを参照してください。 2013年6月 47ページ Oracle Multitenant まとめ 古い非CDBアーキテクチャと新しいマルチテナント・アーキテクチャの本質的な相違点として、真の データベース内仮想化を実現するのは後者であることを確認しました。これは、ルートにあるOracle システムとPDBにある顧客システムを分離する水平方向のパーティションによりデータ・ディクショ ナリに物理的に実装されます。そして、この基本的な分離により、同じCDBに多くのPDBを含むこと ができます。PDBは、統合されたアプリケーション・バックエンドを詳しく説明するための宣言的な メカニズムです。 真のデータベース内仮想化には、スキーマベースの統合の原理に起因する次の2つの欠点がありませ ん。1つは、グローバル名の競合です。これは、コストのかかる危険な変更を行ってからでなければ、 既存のアプリケーション・バックエンドを同じ非CDBに共存させられないことを意味します。もう1 つは、any権限、および同様の強力な権限、およびpublicに付与した権限が、非CDB内のすべてのア プリケーション・バックエンドに及ぶという欠点です。 プラグ機能を実現するのは、PDBとルートの物理的な分離です。そして、プラグ機能は実質的に、ア ンプラグ/プラグを使用する第3世代のOracle Data Pumpとなります。さらに、異なるOracle Database ソフトウェア・バージョン間のCDBのアンプラグ/プラグは、Oracleバージョンのパッチ適用の新し いパラダイムとなります。そのため、スキーマベースの統合により発生する次の2つの問題は、プラ グ機能によって取り除かれます。1つは、プロビジョニングの困難さ（アプリケーション・バックエ ンドの配置場所の移動、およびアプリケーション・バックエンドのクローニング）で、もう1つは、 パッチの適用が必須の状況にある場合は、この環境変更に未対応の他のアプリケーション・バック エンドに影響を与えずに、同時に1つのアプリケーション・バックエンドだけにOracleバージョンを パッチ適用することは不可能だという事実です。 また、SGAおよびバックグラウンド・プロセスの共有モデルはPDBベースの統合とスキーマベースの 統合で本質的に同じであること、そのため、古いアプローチのメリットである高い統合密度が完全 に維持されることも確認しました。さらに、SGA内（データ・ブロック経由でデータファイルに転送）、 REDO、UNDOの論理的仮想化により、CDB内でのPDB間リソース管理に新しい機能がもたらされ、 PDBのポイント・イン・タイム・リカバリが可能になりました。 最後になりますが、CDBとPDBとの関係はオペレーティング・システムと非CDBとの関係と同じと言 えるでしょう。また、PDB/非CDB互換性保証は、マルチテナント・アーキテクチャを特徴付ける新 しい事象はルートであることを意味しています。さまざまなオペレーティング・システムのプリミ ティブによって非CDBのプロビジョニング・タスクや他のメンテナンス・タスクが連携されるのと同 様に、ルートに対して実行されるSQL文によってPDBの対応するタスクが実装されます。したがって、 これはプラットフォーム非依存で移植性があることで知られ、Oracle Databaseを使用できるところ なら当然どこでも使用でき、すべてのデータベース管理者が知っているPL/SQLが、PDB上での操作 を自動化する言語だということを意味します。 そのためOracle Multitenantは、次世代のアプリケーション・バックエンド統合を代表するものです。 スキーマベースの統合を導入したユーザーが実現を目指した一元管理のメリットは、これによって 実現します。その導入に必要なのは、オプションをデプロイすることだけです。アプリケーション・ バックエンドもクライアント・コードも変更する必要はありません。 2013年6月 48ページ Oracle Multitenant 付録A： Oracle Databaseドキュメント・ライブラリでのマルチテナント・ アーキテクチャの扱い 紹介と概要は『Oracle Database概要』をご覧ください。このドキュメントには、マルチテナント・ アーキテクチャというメイン・セクションが新たに追加されています。 詳しい説明は『Oracle Database管理者ガイド』で扱っています。このドキュメントにも、マルチテ ナント環境の管理というメイン・セクションが新たに追加されています。PDB/非CDB互換性保証が あるため、当然、『Oracle Database開発ガイド』ではマルチテナント・アーキテクチャについては 簡単にしか触れていません（エディションのスコープはそれが定義されているPDBです。つまり、単 一のCDB内で多数のEBR（エディション・ベースの再定義）を同時実行できます。そのため、スキー マベースの統合を使用して複数のアプリケーション・バックエンドを12.1より前の同じデータベース （必然的に非CDBです）に実装したユーザーがこれらのバックエンドの複数に同時にオンライン・パッ チ適用を実施する必要がある場合に直面する課題が取り除かれます）。 ローカル・ユーザーと共通ユーザーとの新しい区別の扱い、カレント・コンテナに対する権限付与 の有効範囲の扱い、これがどのようにしてデータベース管理者（CDB管理者）とアプリケーション管 理者（PDB管理者）の職務の分離の正式な制御に関する新しい概念につながるのかについては、 『 Oracle Database セ キ ュ リ テ ィ ・ ガ イ ド 』 を 参 照 し て く だ さ い 。 こ の ド キ ュ メ ン ト で は 、 container_dataビューの重要な別の概念についても説明しています。 マルチテナント・アーキテクチャで導入された新しいSQL構文はほとんどありません。新しいSQL構 文はおもに、エンティティとしてのPDB上での操作を実装するためのものに限定されています。それ らの構文およびセマンティックの正式な定義は、『Oracle Database SQL言語リファレンス』を参照 してください。 新しいデータ・ディクショナリ・ビュー（DBA_PDBsなど）とパフォーマンス・ビュー（v$PDBsなど） がいくつかあります。特に、各パフォーマンス・ビューにはCon_IDという新しい列があります。これ は、パフォーマンス・ビューに表示されるファクトの来歴を表すコンテナ識別子です。同様に、デー タ・ディクショナリ・ビューの一連のフレーバー（DBA_、All_、およびUser_）は、わずかに異なる モデルを使用して新しいCDB_フレーバーで拡張されています。各CDB_ビューには新しいCon_ID列が あります。ビューに表示されるCDB_列には、container_dataビューとしてのそのステータスが反映さ れます。すべてのビューの説明は『Oracle Databaseリファレンス』を参照してください。 2013年6月 49ページ Oracle Multitenant 2013年6月 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載される内容 著者：Bryn Llewellyn は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙 示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証や条件も提供するものではありませ Oracle Corporation ん。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとし World Headquarters ます。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段に 500 Oracle Parkway よっても再作成または送信することはできません。 Redwood Shores, CA 94065 U.S.A. OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。 海外からのお問い合わせ窓口： AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。IntelおよびIntel XeonはIntel 電話：+1.650.506.7000 Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International, Inc.の商標または登録 ファクシミリ：+1.650.506.7200 oracle.com 商標です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。1010