Oracle Multitenant のデータベース・プロビジョニ …...Oracle Database 12c Release 1（12.1）のOracle Multitenantは、自動化しやすいシンプルなコマンド

Oracle Multitenantのデータベース・プロビジョニングおよび再配置サービス Oracle Database 12c Release 2（12.2） Oracle ホワイト・ペーパー | 2017 年 3 月

Oracle Multitenantのデータベース・プロビジョニング – Oracle Database 12c Release 2（12.2）

免責事項

下記事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。マテリアルやコード、機能の提供をコミットメント（確約）するものではなく、購買を決定する際の判断材料になさらないで下さい。オラクルの製品に関して記載されている機能の開発、リリース、および時期については、弊社の裁量により決定されます。


目次

免責事項 ........................................................................................................................................................... 1

目次 ................................................................................................................................................................... 2

Oracle Database 12.2 Multitenant のオンライン・プロビジョニング、リフレッシュ、および

再配置 ............................................................................................................................................................... 1

PDB のオンライン（ホット）クローニング ............................................................................................ 3

Multitenant 12.1 のクローニングの概要 ......................................................................................... 3

オンライン（ホット）クローニング ................................................................................................ 4

必要な構成 .............................................................................................................................................. 4

ローカル UNDO の構成と有効化 ....................................................................................... 4

アーカイブ・ログ・モードの有効化 ................................................................................. 5

共通ユーザーと権限 ............................................................................................................ 6

パブリック・データベース・リンク（オプション） ...................................................... 6

実行ワークフロー .................................................................................................................................. 7

顧客のユースケース – 継続的インテグレーションと PDB プロビジョニング ........................ 9

オンライン高速リフレッシュ同期 ........................................................................................................... 11

必要な構成 ............................................................................................................................................ 11

リフレッシュ・モード ....................................................................................................................... 11

refresh mode manual ...................................................................................................... 11

refresh mode automatic .................................................................................................. 12

実行ワークフロー ................................................................................................................................ 12

手動リフレッシュ・モード ............................................................................................. 12

自動リフレッシュ・モード ............................................................................................. 13

顧客のユースケース – ハイブリッド・クラウドのゴールド・イメージのリフレッシュ可

能クローンの操作 ................................................................................................................................ 14

Oracle Database 12.2 のオンライン再配置 ........................................................................................... 15

必要な構成 ............................................................................................................................................ 16

SQLNET リスナー構成 ........................................................................................................................ 16

単一 TNS LISTENER、共有リスナー・ネットワーク、または SCAN ........................... 16

独立した TNS リスナー .................................................................................................... 21


実行ワークフロー ................................................................................................................................ 22

共有の TNS LISTENER ネットワーク ............................................................................... 22

独立した TNS LISTENER ネットワーク ........................................................................... 24

ツームストン .................................................................................................................... 25

顧客のユースケース – ハイブリッド・クラウドでの双方向の Oracle データベース再配置

................................................................................................................................................................. 25

結論 ................................................................................................................................................................. 26

1 | Oracle Multitenantのデータベース・プロビジョニング – Oracle Database 12c Release 2（12.2）

「ハイブリッド・クラウド・コンテキストでの dbPaaS の実装数はますます増えていきます。これ

はクラウド環境とオンプレミス環境の両方で互換性、アプリケーション・アーキテクチャ設計、お

よびデータ統合に対応できるベンダーが選定されることを意味します。」

MARKET GUIDE FOR DATABASE PLATFORM AS A SERVICE

Gartner アナリスト・レポート：G00281345

2016 年 9 月 15 日

Oracle Database 12.2 Multitenantのオンライン・プロビジョニング、

リフレッシュ、および再配置

世界でもっとも多く使用されているデータベースの最新世代である Oracle Database 12c Release 2（12.2）の、ダウンロードと Oracle Cloud での利用が可能になりました。クラウド・コンピューティングにおいてスケーラビリティ、適応性、および費用対効果はお客様にとってますます大切になっており、データベースのプロビジョニングとワークロード管理における最適なソリューションは非常に重要です。12.2 で導入された主要な機能には Oracle Multitenant の機能拡張が含まれており、特に、オンライン・データベース・クローニング、データベース・クローン・リフレッシュ、およびオンライン・データベース再配置の分野が強化されています。この機能は、Oracle Cloud 環境とオンプレミス環境で使用できます。この主要な利点によって、Oracle Cloud とオンプレミスの機能精度が向上し、両環境での一貫した実行とクラウドへの簡単な移行が可能になります。これは、オンプレミスとOracle Cloud の間における、オンラインでのハイブリッドな双方向のプロビジョニング・サービスと再配置サービスによるものです。

Oracle Database 12c Release 1（12.1）の Oracle Multitenant は、自動化しやすいシンプルなコマンドライン文による完全統合型の機能豊富なデータベース・プロビジョニング・ソリューションであり、フル機能の Oracle データベースを数分でプロビジョニングできます。このプロビジョニング・メカニズムは、ビジネスに関するカスタマイズが'埋め込まれた'静的なゴールド・イメージ・データベースからのクローニングによる、自動的なプライベート・クラウド Database-as-a-Service（DBaaS）ソリューションの構築に役立ってきました。ただしテスト、開発、または分析用にアクティブ・データベースからクローニングする場合、12.1 のプロビジョニングでは、クローン操作中にソース・データベースを読取り専用にする必要がありました。Oracle Multitenant バージョン 12.2 ではこの制限が解消され、'ホット'ソース・データベースに対してすべてのクローニング操作をオンラインで実行できます。これにより、DBaaS と市場投入期間のユースケースが広がって、俊敏な統合型のデータベース・プロビジョニングが加わり、より俊敏なソフトウェア開発ライフサイクル、マイクロサービスの開発、およびアプリケーションの継続的な統合と提供を実現できます。


アクティブ・ソース・データベースからデータベースをプロビジョニングするには同期が必要ですが、クローン・イメージ・データとアクティブ・ソース・データベースの間には時間の経過とともに差異が生じ、徐々に同期状態ではなくなります。これは、テスト、開発、ビジネス分析において最新データを必要とする場合に問題となります。12.2 はこのアクティブ・ソース・データベースからの'ホット'クローニング機能に基づいて構築されており、アクティブ・ソースからクローニングされるゴールド・イメージ・データベースを手動または自動でリフレッシュする機能も含まれています。手動リフレッシュ・オプションはシンプルな DDL 文であり、自動リフレッシュの頻度は構成可能です。リフレッシュ可能なクローンには、開発、テスト、分析を最新バージョンのデータで実行できるという明らかな利点があります。このような柔軟性をクラウド運用にも拡張すると、クラウドでプロビジョニングされたデータベースと、アクティブな、オンプレミスのソース・データベースの同期状態を維持できます。この同期状態の、クラウドでプロビジョニングされたデータベースが、セルフサービスの統合型アプリケーション開発、テスト、または分析クラウド・サービスのクローン・ゴールド・イメージ・マスター・データベースとして機能するようになりました。

お客様の初期のご要望を反映した Multitenant 12.2 リリースのもっとも優れた機能の 1 つは、オンライン・データベース再配置です。これは、接続されているクライアントに最小限の影響しか与えず（または影響を与えず）に、アクティブ・データベースを別のホスト環境に移動する機能です。この機能では外部オペレーティング・システムの仮想化は不要であり、Oracle Multitenant 固有のデータベース内仮想化のみに依存します。このデータベース再配置では、データベース自体に関連するデータのみが移動されるため、オペレーティング・システムのイメージ・コピーが過剰になることはありません。この機能に関連するユースケースとしては、計画メンテナンスのためのオンライン・データベース再配置、アクティブ・データベースの俊敏なワークロード分散、Oracle Cloud との双方向の移行などが考えられます。いずれのケースでも、停止時間を最小限にしてビジネスの継続性を維持できます。データベース再配置は、オンプレミスで、Oracle Cloud 内のデータベース・サービス間で、またはオンプレミス・データベースと Oracle Cloud 内のデータベース・サービスの間のハイブリッド運用として実行できます。

Oracle Multitenant 12.2 は、非常にスケーラブルな、データベース内仮想化ソリューションであり、プラガブル・データベース（PDB）と呼ばれるホスト対象テナントに対して、コンテナ・データベース（CDB$ROOT）がデータベース・インフラストラクチャ（CPU 使用率、プロセス・スケジューリング、メモリ使用率、I/O およびデータベース・リソース管理など）を提供します。このようなホスト対象PDB には、関連するデータファイルが含まれる、SYSTEM、SYSAUX、USER、UNDO という固有の表領域があります。この分離レベルによって、前述のような俊敏なプロビジョニングと移植が可能となります。Oracle Multitenant 12.2 とその他の機能（データベース・ロックダウンやパフォーマンス・プロファイルなど）、Oracle Multitenant アプリケーション・コンテナ、および容易なハイブリッド・クラウド運用を組み合わせることで、費用対効果の高い堅牢な基盤を構築し、オンプレミス、Oracle Cloud、またはその両方のハイブリッド運用においてセキュアな DBaaS と SaaS を実現できます。次に、Oracle Multitenant 12.2 で実現できるプロビジョニングおよび再配置サービスと、関連するユースケースについて、技術的に説明します。


PDBのオンライン（ホット）クローニング

Multitenant 12.1のクローニングの概要

クローニングによるデータベース・プロビジョニングは、Oracle Multitenant 12.1 の最初のリリースで利用可能になりました。このバージョンでは PDB$SEED が導入されました。これは後続データベースの高速プロビジョニング専用に作成される、デフォルト・テンプレートの PDB です。このシンプルなクローニング手順によって、それまで非常に複雑であったデータベース・プロビジョニング・タスクが、'create pluggable database mydb admin user oracle identified by oracle'のようなシンプルな DDL 文になりました。12.1 のクローニング機能は PDB のクローニング機能と密接に関連しており、12.2 にも継承されています。

» 完全クローン。データファイルを完全に複製して、ソース・データベースのコピーを新しいデータベースとして作成します。このクローニング機能は、ローカルまたはリモートで使用できます。ローカルの完全クローンは、同じホスティング・コンテナ・データベース（CDB）内で実行されるクローンです。リモートの完全クローンは、同じ OS/サーバー、またはエンディアン互換性のある別の OS/サーバーのホスティング・コンテナ・データベース（CDB）間で実行されるクローンです。

» スナップショット・クローン。データファイルのスナップショット・コピーを含む、ソース・データベースのコピーとして、新しいデータベースを作成します。スナップショット・コピーでは、ソース・データベースやクローン・データベースの変更に合わせてブロックの変更を'分岐'させながら、ソース・データベースの一貫したシン・プロビジョニング・コピーを作成できる、ストレージ・ベンダーの Copy-on-Write などのテクノロジー 1 を利用しています。 Oracle Multitenant でのスナップショット・クローンは、ローカルまたはリモートで実行できます。リモート・スナップショット・クローンには、共有ストレージが必要です。たとえば、Oracle Real Application Clusters（Oracle RAC）クラスタ環境内の 2 つの CDB では、共通の Oracle Automatic Storage Management（Oracle ASM）ストレージを共有します。

» サブセット・クローン。データベース・サブセット・クローンは、完全クローンとスナップショット・クローンの両方で利用可能です。ソース・データベースのデータ・セットのサブセットのみを使用して、クローン・データベースを作成できます。

» メタデータ・クローン。データベース・メタデータ・クローンは、データベース・サブセット・クローンと同様に、完全クローンとスナップショット・クローンの両方で利用可能です。データを除く、ソース・データベース・メタデータのデータベース・クローンのみが作成されます。

» オンクローン・トリガー。データベース・トリガーがソース・データベースで定義されており、クローン・データベースが最初に開かれる前にクローン・データベースでトリガーが起動するすべてのクローン・タイプで利用可能です。これは、データ・マスキング、データ編集、またはその他の実装済みのセキュリティ機能を実行して、セキュリティ・ポリシーのすべてのトレースがクローンから削除されているクローン・イメージ内の機密データを保護するためによく使用されます。

1 汎用スナップショット・コピー機能は、スパース・ファイルをサポートしており、Oracle init.ora パラメータの clonedb=true であるファイル・シス

テムで使用できます。構成については、My Oracle Support（MOS）Note 1210656.1 を参照してください。


Multitenant 12.1 では、これらの各クローニング機能において、ソース・データベースのトランザクションを静止させるか、切断されているアーカイブ PDB からクローニングする必要がありました。Oracle Multitenant 12.2 では、これらのプロビジョニング・タスクをアクティブ・ソース・データベース上で、オンラインで'ホット'に処理できるようになりました。

オンライン（ホット）クローニング

12.1 では、共通コンテナ内のホスト対象プラガブル・データベースが、すべて同じ UNDO 表領域を共有します。そのため、アクティブ・データベースからの、独立したオンライン・データベース・プロビジョニングを実行できませんでした。12.2 では、共有 UNDO を引き続き使用できますが、プラガブル・データベース（PDB）用に構成されたローカル UNDO も使用できます。これは、オンライン（'ホット'）クローニングに必要です。ローカル UNDO は CDB$ROOT のプロパティです。ローカル UNDO が有効な場合、CDB のホスト対象テナントがすべて固有のローカル UNDO 表領域を持ちます。CDB がローカル UNDO モードの場合にのみ、PDB$SEED からクローニングするとUNDO 表領域が自動的に作成されます。共有 UNDO とローカル UNDO を同じ CDB で混在させることはできません。

必要な構成

アクティブ・データベースからのオンライン・データベース・プロビジョニングを有効にするには、次の構成が必要です。

ローカル UNDO の構成と有効化

前述のとおり、PDB$SEED からクローニングするか DBCA を使用してプラガブル・データベースを作成した場合、CDB でローカル UNDO が有効なときは、UNDO 表領域がデフォルトで作成されます。これを確認するには、sysdba として CDB$ROOT から次のコマンドを実行します。

SQL> select p.con_id, p.name, c.tablespace_name from v$pdbs p,

cdb_tablespaces c

where p.con_id=c.con_id

and tablespace_name like upper('%undo%');

CON_ID NAME TABLESPACE_NAME

5 APP1 UNDOTBS1

4 APP3 UNDOTBS1

3 APP2 UNDOTBS1

注： CDB と PDB のローカル UNDO 管理はデフォルトで AUTO であり、デフォルトのUNDO_RETENTION は 900 秒間です。PDB のコンテキストでの UNDO 表領域の管理と動作は、CDBまたは非 CDB と同じです。PDB$SEED には、デフォルト・プロビジョニング用の UNDOTBS1 表領域が含まれます。


CDB でローカル UNDO が有効であることを確認するには、sysdba として CDB$ROOT で次のコマンドを実行します。

SQL> select property_name from database_properties where

property_name like upper('%local_undo%');

PROPERTY_NAME

------------------

LOCAL_UNDO_ENABLED

CDB でローカル UNDO が有効でない場合は、sysdba として CDB$ROOT で次のコマンドを実行します。

SQL> startup upgrade;

SQL> alter database local undo on;

SQL> shutdown immediate;

SQL> startup;

注：繰り返しになりますが、ローカル UNDO は CDB$ROOT のコンテキストで有効であり、そのコンテナ内のすべてのホスト対象テナントで有効です。ローカル UNDO と共有 UNDO を混在させることはできません。ローカル UNDO 表領域が含まれるもののローカル UNDO が有効でない PDB では、引き続き CDB$ROOT 内の共有 UNDO 表領域が使用されます。

アーカイブ・ログ・モードの有効化

ホット・クローン・リクエストを満たすには、アーカイブ・ログが必要な場合があります。CDB$ROOT でアーカイブ・ログ・モードを有効にするには、

sysdba として次のコマンドを実行します。

SQL> startup mount

SQL> alter database archivelog;

SQL> alter database open;

注：フラッシュ・リカバリ領域（FRA）のサイズは、ストレージ冗長性の要件に基づく 80/20 または 40/60（DATA/FRA）のルールに従って適切に設定する必要があります。


共通ユーザーと権限

データベース・プロビジョニングは、CDB$ROOT のコンテキストで共通ユーザーとして実行されます。共通ユーザーには、少なくとも次の権限が必要です。

» セッション、リソースの作成。これらの権限は共通ロールに付与できます。

» ソースとターゲットの CDB$ROOT でプラガブル・データベースを作成する権限。ソース・データベースの共通ユーザーには、プラガブル・データベースの作成権限または SYSOPER の管理権限が必要です。これらの権限は共通ロールに付与できます。

» SYSOPER container=all をターゲット CDB の共通ユーザーに付与して、共通ユーザーが PDB の作成後にこれを開けるようにします。

sysdba としてソース・データベースとターゲット・データベースで実行する共通ユーザー権限の定義は、たとえば次のようになります。

SQL> grant create session, resource to c##clone_admin container=all;

SQL> grant create pluggable database to c##clone_admin container=all;

SQL> grant sysoper to c##clone_admin container=all;

SQL> alter user c##clone_admin set container_data=ALL container=current;

SQL> grant select on cdb_pdbs to c##clone_admin;

パブリック・データベース・リンク（オプション）

異なる CDB 間でデータベースのホット・クローニングを行う場合は、ターゲット CDB からソースCDB にパブリック・データベース・リンクを作成し、両方の環境に存在する共通の特権ユーザーとして接続する必要があります。たとえば、sysdba として、ターゲット CDB$ROOT で次のコマンドを実行します。

SQL> create public database link POD1_link

connect to c##clone_admin identified by

using 'POD1';

c##clone_admin は上記で定義した権限を持ち、'POD1'は tnsnames.ora ファイルで定義した TNS 接続エイリアスを表します 2。

2 Oracle RAC 環境内のデータベース・リンクでこのようなエイリアスを使用する場合は、すべての Oracle RAC インスタンスに同じ tnsnames.ora エ

ントリが必要です。パラレル・ファイル・コピーによってすべての Oracle RAC インスタンスにスレーブ・プロセスが作成され、これらのプロセスす

べてが dblink の記述を読み取ってリモート接続を確立し、ソース PDB ファイルをコピーしようとするためです。


共有 UNDO からローカル UNDO への移行

CDB$ROOT で共有 UNDO が構成されていた PDB から、ローカル UNDO が構成されて有効になっている CDB に移行するか、またはそういった CDB で CDB 以外を PDB として使用すると、PDB が接続されたときに PDB 用の UNDO 表領域が自動的に作成され、その PDB でただちに使用されます 3。

ローカル UNDO から共有 UNDO への移行

ローカル UNDO 構成から共有 UNDO の使用に移行した方がよい場合があります。たとえば、アーカイブのためにデータベースを読取り専用に移行できる場合などです。この使用例では、PDB の切断/接続操作によって、共有 UNDO が構成されている CDB に PDB を再配置します。PDB は、CDB$ROOT の共有 UNDO 表領域が開くとこれを使用します。ローカルの UNDO 表領域は削除できます。切断された PDB マニフェストは、その PDB でローカル UNDO が構成されているかどうかを示します - <localundo>1</localundo>。

実行ワークフロー

Multitenant 12.2 にはオンラインの'ホット'クローン・プロビジョニング機能があり、単一 CDB のコンテキストでローカルに、または CDB 間でリモートに実行できます。どちらの使用例でも、ストレージが共有されており、ストレージがスパース・ファイルをサポートしていて適切に構成されている場合は 4、スナップショット・コピー構文を使用してホット・クローンをシン・プロビジョニングすることで、実行時間を短縮してストレージ消費量を減らすことができます。次の例（図 1）では、共有ストレージがないことを前提として、

2 つの CDB 間でホット・クローンを実行しています。これらの CDB は、同じデータセンターにある場合と、別々のデータセンターにある場合（オンプレミスから Oracle Cloud へのハイブリッド運用など）があります。

図 1 の例では、3 つのアプリケーション PDB が示されている本番 CDB から開始します。本番システムは T0 -> T20 で稼働します。T20 で、開発環境からのホット・クローン操作が開始されます（1.）。このリリースでは、ホット・クローン操作が、パブリック・データベース・リンク間で実行される、ターゲット CDB からの'プル'です。APP3 PDB の本番 CDB から開発 CDB へのソースDATA FILE、REDO LOG、UNDO のバルク・ブロック・コピーの開始時に、ホット・クローンのBEGIN CLONE SCN マーカーが設定されます。以下の例では、ファイル・コピーが完了すると、END CLONE SCN が T30 で設定されます。ホット・クローニングされた DEVAPP3 PDB で、'alter

pluggable database devapp3 open'が実行されます（2.）。open 文によって、リカバリ中の変更とコミットされていない UNDO トランザクションが適用されます。この際、T30 の時点（END CLONE SCN）でのトランザクション的に一貫性のあるホット・クローン・イメージDEVAPP3 がレンダリングされます。

3 Real Application Clusters デプロイメントでは、PDB のデプロイ先のインスタンスごとに、PDB あたり 1 つの UNDO 表領域が自動的に作成されます。

4 Oracle Multitenant 12.2.0.1 は、dNFS/CLONEDB が構成されている環境の ACFS、ZFS、NETAPP、EMC のファイル・システムで、スナップショッ

ト・コピー構文をサポートします。


図1：本番から開発へのホット・クローン・プロビジョニング

開発 CDB の alert.log には、BEGIN CLONE SCN から END CLONE SCN までのホット・クローンを満たすメディア・リカバリ期間が表示されます。

Applying media recovery for pdb-4099 from SCN 1512265 to SCN 1512315

…

Successful media recovery should also post to the alter.log:

…

DEVAPP3(4):Incomplete Recovery applied until change 1512315 time

12/19/2016 15:13:49

ソース PDB とターゲット PDB の差異が生じ始めるポイントである END CLONE SCN も、CDB$ROOT のコンテキストの CDB_PDBS ビュー、または（以下の SQL のように）PDB のコンテキストの DBA_PDBS に表示されます。

SQL> select pdb_name, creation_scn from dba_pdbs;

PDB_NAME CREATION_SCN

-------- -------------

DEVAPP3 1512315


上記の例で説明したとおり、2 つのシンプルな DDL 文を使用します。

SQL> create pluggable database devapp3 from app3@dblink parallel 16

SQL> alter pluggable database devapp3 open;

これで、アクティブ・データベース・ソースからクローニングされたデータベースが作成されます。データファイルは、上記のように create 文に parallel 句を含めた場合に、パラレル・スレッドで実行されるソースからの物理ブロック・コピーです。スナップショット・コピーに対応する共有ストレージを使用できる場合は、ホット・クローン操作の実行時間とストレージ消費の効率がさらに向上します。これは費用対効果の高い完全統合型の Oracle Multitenant データベース・ソリューションで、外部 OS の仮想化や追加ライセンスは不要です。

顧客のユースケース – 継続的インテグレーションとPDBプロビジョニング

Swiss Mobiliar は Oracle OpenWorld 20165において、次のユースケースのプレゼンテーションを行い、Oracle Database 12c Multitenant PDB をバックエンド・データストアとして統合した、自社の俊敏なマイクロ・サービス・アプリケーション開発への移行について紹介しました。Swiss Mobiliar ではPostgreSQL や非 CDB などのデータベース・イメージを Docker コンテナで統合してスタック・プロビジョニングすることを検討していましたが、ベア・メタルの Multitenant PDB プロビジョニングを統合ソリューションとして採用することを決定しました。その理由は環境のパフォーマンス、効率、統合のしやすさ、および扱いやすさです。Docker コンテナでアプリケーションを実行しながら、スタック全体を 10 分未満でプロビジョニングできます。Docker コンテナは、EZ 接続文字列を使って、Oracle Internet Directory（OID）経由で PDB に接続しています。このプロビジョニング・ワークフローでは、継続的インテグレーション・サーバーがアプリケーションの新しい PDB に命令を出します。PDB が作成されて、OID の接続文字列エントリが含まれる PDB の状態情報が継続的インテグレーション・サーバーに返送されます。継続的インテグレーション・サーバーは、リクエストに埋め込まれた OID エントリを使って、アプリケーションの Docker コンテナに命令を出します（プレゼンテーションのリンクの詳細については、関連する脚注を参照してください）。

5 'Agile Development, Cost Saving, and More with Oracle's Multitenancy Solutions' [CON1668], Mobiliar Versicherungen AG, Oracle Database

Adminstrator, Alain Fuhrer


図2：Oracleデータベースを含む完全自動化されたアプリケーション・デプロイメントを10分以内で完了

前述の自動化された PDB プロビジョニング・ワークフローについて詳しくは、図 3 を参照してください。継続的インテグレーションから開始される REST コールによって、SQLNET で関数が実行され、テンプレートのゴールド・イメージ PDB のクローンとして PDB を作成するジョブがスケジュールされます。PDB プロビジョニング・リポジトリ内の PDB 命令表は、PDB がプロビジョニングされると更新され、成功状態を継続的インテグレーションに返送します。その後、関連するアプリケーション Docker が作成されます 6。

図3：PDBプロビジョニング・ワークフローの詳細

このユースケースは、機能豊富な Oracle Multitenant 12.2 データベースのプロビジョニングの容易さと、自動化された完全マネージド型の俊敏な開発環境での統合のしやすさを示しています。

6 Ibid.


オンライン高速リフレッシュ同期

Oracle Multitenant 12.2 オンライン・データベース・クローニングでは、データファイル・コピーが完了して PDB が開き、END CLONE SCN が確立された時点でのクローン・イメージが作成されます。この時点でクローン・イメージとソースには差異が生じ始め、同期状態ではなくなります。クローン PDB のリフレッシュ機能がない場合は、最初のクローン・イメージ PDB を削除して再作成する必要があります。このため、データファイル、REDO、UNDO のコピーをもう 1 つ用意して、新たな END CLONE SCN の時点での新しいクローン・イメージ PDB をインスタンス化する必要があります。この同期作業は、リフレッシュ目的としては非効率です。また、ホット・クローン操作が完了すると、ソースとは再び非同期状態となります。Oracle Multitenant 12.2 では Multitenant のオンライン・データベース・クローニング機能が強化されており、ホット・クローン・ゴールド・イメージ PDB を'リフレッシュ可能な'クローン・マスターとして定義できます。最初のホット・クローン操作は、「オンライン・データベース・クローニング」の項で先ほど述べたとおりですが、12.2 では create 文にリフレッシュ・モード宣言が含まれており、ホット・クローニングされたゴールド・イメージ PDB がソース PDB と同期して動作します。

必要な構成

Oracle Multitenant 12.2 データベースの高速リフレッシュ同期に必要な構成は、先ほど定義したオンライン（ホット）データベース・クローニングの要件と同じです。create pluggable database 文に refresh mode 句を追加することで、オンライン（ホット）クローン PDB が'リフレッシュ可能'と定義されます。

リフレッシュ・モード

ソースとクローン・イメージを同期状態にしておく必要がある場合は、create 文で refresh mode宣言を使用して、クローン・イメージをリフレッシュ可能なコピーとしてプロビジョニングします。2 種類のリフレッシュ・モードを使用できます。

refresh mode manual

– refresh mode manual を使用する場合は、ユーザーがリフレッシュを開始する必要があります。

SQL> create pluggable database oedev from oe@dblink refresh mode manual;

「共通ユーザーと権限」の項で先ほど説明したとおり、CDB$ROOT の共通ユーザーとして最小権限でこの文を実行すると、アクティブな（ホット）ソース PDB である OE から、クローン・イメージPDB である OEDEV が作成されます。ここでは、データベース・リンクを経由してリモート CDB でrefresh mode manual 宣言を使用しています。これで、このクローン PDB がリフレッシュ可能なコピーとして定義されます。このクローン PDB のリフレッシュは、エンドユーザーが手動で実行する必要があります。


refresh mode automatic

- refresh mode automatic では、create pluggable database 文で宣言されている頻度に基づいて、Oracle Scheduler を使ったリフレッシュが実行されます。

SQL> create pluggable database oedev from oe@dblink refresh mode every 360 minutes;

前述のとおり、この文はターゲット CDB の CDB$ROOT から共通ユーザーとして実行されます（そのユーザーに対して適切な権限が定義されていることが前提となります）。この文によって、リフレッシュ・モード宣言 refresh mode every 360 minutes を使用して、リモート CDB にクローン・イメージ PDB である OEDEV が作成されます。


リフレッシュ可能なクローンは、ソース PDB との同期状態を定期的に維持し、他の PDB を完全コピーまたはスナップショット・コピーとして作成する際のゴールド・イメージ・クローン・マスターとして機能するためのものです。これによって、ソース PDB での複数の連続的なクローニング操作によるオーバーヘッドを解消できます。リフレッシュ操作を除き、リフレッシュ可能なゴールド・イメージ・クローン・マスターとソースの間に差異がないことが必要です。そのため、ゴールド・イメージのリフレッシュ可能クローンは、読取り専用モードでマウントされます。前述のとおり、リフレッシュ操作には manual と automatic の 2 種類があります。いずれの場合も、リフレッシュ可能なゴールド・イメージ・クローン・マスターはリフレッシュ操作中に閉じられている必要があります。リフレッシュ操作とは、REDO と UNDO の物理ブロックを適用して、END CLONE SCN の時点での、一貫性のある、リフレッシュ可能なゴールド・イメージ・クローン・マスターのトランザクション状態をレンダリングすることです（オンライン（ホット）データベース・クローニングを参照）。次の 2 つの項で、両方のリフレッシュ・モードについて説明します。

手動リフレッシュ・モード

以下の図 4 は、ソース CDB の SCN タイムラインに沿って、リフレッシュ可能クローンの初期作成と手動リフレッシュ操作の手順を示しています。手順 1 では、データベース・リンク経由で、ターゲット CDB において create pluggable database 文を実行します。この操作はターゲットからソースに対して、SCN タイムラインの T20 に実行されます。前述のオンライン・データベース・プロビジョニングと同様に、create 文では BEGIN CLONE SCN を定義し、BEGIN CLONE SCN の時点でのソース PDB の REDO、UNDO、DATA FILE をターゲット CDB にコピーします。コピーが完了すると、T30 の時点で END CLONE SCN がマークされます。PDB の open 文が実行されると、メディア・リカバリが適用され、PDB DEVAPP3 のトランザクション状態が SCN T30 の時点で一貫していることがレンダリングされます。手順 2 では、SCN T30 の時点で一貫性のあるリフレッシュ可能なクローンが読取り専用モードで開かれます。

以下の手順 3 でリフレッシュ操作が開始されます。DEVAPP3 クローンがホストされているCDB$ROOT でリフレッシュ・コマンドを実行する場合は、ゴールド・イメージのリフレッシュ可能クローンの DEVAPP3 が閉じられている必要があります。手順 4 でリフレッシュが実行されます。ここでは、新しい BEGIN CLONE SCN である T70 に基づいて、関連する REDO と UNDO のみがコピーされます。新しい END CLONE SCN が確立されます（この場合は T90 の時点）。メディア・リカバリが適用され、DEVAPP3 が新しい END CLONE SCN である T90 の時点で一貫性のあるトランザクション状態となります。手順 5 では、SCN T90 の時点でのゴールド・イメージのリフレッシュ可能クローンである DEVAPP3 が読取り専用で開かれます。


図4：ゴールド・イメージPDBクローンの手動による作成およびリフレッシュ操作

注：オンライン（ホット）データベース・クローニングの場合と同様に、BEGIN CLONE SCN とEND CLONE SCN のメディア・リカバリ期間はホスティング CDB の alert.log に記録されます。

DEVAPP1_REFRESH_AUTO(3):alter pluggable database refresh

2017-01-04T13:49:33.282989-05:00

Applying media recovery for pdb-4099 from SCN 1503528 to SCN 1504696

自動リフレッシュ・モード

ゴールド・イメージのリフレッシュ可能クローンを自動的に作成およびリフレッシュする手順は、手動の場合の手順と似ています。ただし、最初の create 文でリフレッシュ・モードの自動リフレッシュ頻度を定義する点が、手動モードとは異なります。自動リフレッシュ操作によって、create 文で定義されている頻度で、繰り返しのデータベース・スケジューラ・ジョブが作成されます。以下の図 5 は、自動リフレッシュの手順を示しています。手順 1 では、create pluggable database 文で、6 時間ごとのリフレッシュを分単位で定義しています。


図5：ゴールド・イメージPDBクローンの自動的な作成およびリフレッシュ操作

このワークフローは手動リフレッシュと同じですが、スケジュールされたデータベース・ジョブとして実行される点が異なります。スケジュールされたジョブが完了するには、ゴールド・イメージのリフレッシュ可能クローンの DEVAPP3 が閉じられている必要があります。スケジュールされたジョブは、ゴールド・イメージのリフレッシュ可能クローンをホストする CDB の CDB$ROOT から、dba_scheduler_jobs ビューを使用して監視できます。

SQL> SELECT job_name, repeat_interval, last_start_date, next_run_date

FROM dba_scheduler_jobs WHERE job_name like '%DEVAPP3%';

JOB_NAME REPEAT_INTERVAL LAST_START_DATE NEXT_RUN_DATE

--------- ---------------- -------------------- --------------

DEVAPP3_REFRESH_AUTO_3835478423_REFRESH FREQ = MINUTELY; INTERVAL = 360

04-JAN-17 01.18.03.4 04-JAN-17 07.18.03.3

注：スケジュールされたジョブは、次のように dbms_scheduler.run_job()を使用してただちに実行できます。

exec dbms_scheduler.run_job('DEVAPP3_REFRESH_AUTO_3835478423_REFRESH')

顧客のユースケース – ハイブリッド・クラウドのゴールド・イメージのリフレッシュ可

能クローンの操作

Oracle Database 12.2 は Oracle Public Cloud で使用でき、ダウンロードすることもできます。開発環境に関連する運用コストと基本コストを削減するため、顧客はこれらの環境をオンプレミスのLOB デプロイメントやプライベート・クラウド・デプロイメントからハイブリッド運用へと移行しつつあります。ハイブリッド運用とは、これらのデータベースを、オンプレミスの本番環境からOracle Database Cloud Services でプロビジョニングするというものです。以下の図 6 は、ハイブリッドのリフレッシュ可能なクローンプロビジョニング・モデルを利用した、オンプレミスからOracle Database Cloud Services へのこれらの環境の簡単な移行を示しています。ゴールド・イメー


ジのリフレッシュ可能クローンのハイブリッド機能と、埋込みの PDB ロックダウン・プロファイル、Oracle Transparent Data Encryption（Oracle TDE）、Oracle Database Vault、および Oracle Data Masking の機能を使った Oracle Database Cloud Services 固有のセキュリティを組み合わせると、従量制の完全マネージド型サービスによって、これらの環境のコストを最小限に削減できます。

図6：Oracle Public Cloudの従量制のマネージド型データベース・サービスにおける、ハイブリッド・ゴールド・イメージのリフレッシュ可能クローンの操作

オンライン（ホット）クローン操作は、データファイルのコピーをパラレルで実行できるバックグラウンド・タスクです。最初のゴールド・イメージ・クローンは、自動的にリフレッシュ可能なクローンとして作成されます。リフレッシュはスケジュールされた間隔で実行され、リフレッシュ自体は完全コピー・クローンが不要な REDO Apply です。DEVAPP1 と BI APP1 の PDB は、DEV GOLD IMAGE のリフレッシュ可能クローンから取得される完全クローン、スナップショット・クローン、またはサブセット・クローンです。これらのクローンは Oracle Public Cloud データベース・サービス内にあり、オンプレミスのソース・データベースからリフレッシュされます。

Oracle Database 12.2のオンライン再配置

Oracle Database 12.2 Multitenant リリースのもっとも優れた機能の 1 つは、接続されているクライアントに最小限の影響しか与えず（または影響を与えず）にアクティブ・データベースを別の場所に再配置できることです。データベース再配置の目的は、統合密度の向上、サーバー間のワークロード・バランシングや、オンプレミス・ワークロードをクラウドへと拡張するためであったり、計画メンテナンスが必要なためであったりなどさまざまですが、Oracle Multitenant 12.2 の再配置サービスを使用すると、非常に俊敏かつ簡単にデータベースを再配置できます。このサービスは前述のデータベースのオンライン・プロビジョニングおよびリフレッシュ・サービスに基づいて構築されており、特定の TNS ネットワーク・トポロジ用に特定のネットワーク接続処理を導入して、アプリケーション・サービスの中断を最小限に減らして（または完全になくして）います。


必要な構成

Oracle 12.2 Multitenant 再配置の構成には、オンライン・データベース・プロビジョニング用の最小限の構成が必要です。具体的には、ローカル UNDO の構成と有効化、アーカイブ・ログ・モードの構成と有効化に加え、ソース CDB とターゲット CDB の両方で必要な権限を持つ共通ユーザーを定義することと、CDB のデフォルト・サービスまたは CDB のマネージド型サービスに基づいて、ターゲットからソースへの有効なパブリック・データベース・リンクを構成することです。エンディアン形式が同じであれば、異なるオペレーティング・システム間でも再配置を実行できます 7。ユーザー操作なしで簡単に再配置するには、再配置するデータベースのオプションがターゲットCDB で使用できるオプションと同じであるか、そのサブセットである必要があります。またパッチ・バージョンが同じであり、create 文中のソース名とターゲット名が同じであることも必要です。データベース再配置を開始するため、コマンドは create pluggable database 文と構文的に似ていますが、SQLNET リスナー構成に基づく 2 つのモードを含む relocate 句が導入されています。デフォルト・モードの high availability は、ソース CDB とターゲット CDB の間の共有 SQLNET ネットワークを前提とします。一方、maximum availability では、SQLNET ネットワークが共有でなく、クライアント接続転送を明示的に処理する必要があることを示す宣言が必要です。

SQLNETリスナー構成

ここでは、データベース再配置の実行の選択に影響を与える TNS LISTENER ネットワーク・トポロジについて説明します。

単一 TNS LISTENER、共有リスナー・ネットワーク、または SCAN

再配置操作に参加するソース CDB とターゲット CDB が同じ TNS LISTENER を共有（両方の CDB が登録されている単一の共有リスナー、相互登録されて LISTENER ネットワークが形成されている複数の TNS LISTENER、Oracle Grid Infrastructure デプロイメント内の共有の SCAN8ネットワークなど）している場合、関連するデータベース・サービスはすべての TNS LISTENER で認識できます。そのため、データベースおよび関連付けられたデータベース・サービスの再配置は、ホスティングTNS LISTENER に自動的に再登録され、すべてのクライアント接続がこれに従ってリダイレクトされます。クライアント接続文字列の変更は不要です。この構成では、共通ユーザーとしてターゲットCDB$ROOT から再配置を実行するときの正しい構文は次のようになります。

SQL> create pluggable database APP1 from APP1@dblink relocate;

この構文は、データベース再配置の一環としてデータベース・サービスが自動的に登録される共有TNS ネットワークを前提としています。たとえばクラスタ環境に 2 つの CDB がある SCAN 共有ネットワークでは、次のような構成になります。

7 このリリースでは、すべてのリモート・クローンおよび再配置操作でエンディアン互換性が必要です。

8 SCAN は、Oracle Grid Infrastructure の Single Client Access Name の頭字語です。


CDB$ROOT@CDB1-SQL> show parameters listener

NAME TYPE VALUE

-------------------- ----------- -----------

listener_networks string

local_listener string

remote_listener string SCAN-1:1521

CDB$ROOT@CDB1-SQL> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED

---------- ------------- ---------- ----------

2 PDB$SEED READ ONLY NO

3 APP2 READ WRITE NO



$oracle@host1-cdb1: lsnrctl services

Service "app1" has 1 instance(s).

Instance "CDB1", status READY, has 1 handler(s) for this service...

Handler(s):

"DEDICATED" established:0 refused:0 state:ready

LOCAL SERVER


NAME TYPE VALUE

-------------------- ----------- -----------


local_listener string

remote_listener string SCAN-1:1521



---------- ------------- ---------- ----------


3 DEVAPP_REFRESH_AUTO READ ONLY NO


この構成では、2 つの（CDB1 と CDB2）がそれぞれ SCAN リスナー・ネットワーク（SCAN-1:1521）を共有しています。APP1 という PDB が CDB1 でホストされており、そのサーバー上のポート 1521 をリスニングするリスナーに登録されています。CDB1 から CDB2 に APP1 を再配置した後に、APP2 サービス登録が、新しい CDB2 インスタンスに自動的に登録されます。

CDB1 から CDB2 に PDB APP1 を再配置します。

CDB$ROOT@CDB2-SQL> create pluggable database app1 from app1@cdb1_link

relocate;

Confirm state of PDB APP1 on CDB2:



---------- ------------- ---------- ----------


3 DEVAPP_REFRESH_AUTO READ ONLY NO


Confirm the service registration with the listener on host2 for CDB2:




Handler(s):


LOCAL SERVER

上記の構成では、CDB1 と CDB2 の共有 SCAN ネットワークである EZCONNECT 文字列が SCAN アドレス@SCAN-1:1521/app1 に解決され、再配置後に暗黙的に機能します。同様に、SCAN ネットワークは構成されていないものの TNS_LISTENER が相互登録されて共通リスナー・ネットワークが形成されている場合は、再配置後にクライアント接続も解決されます。


たとえば、次のようになります。


NAME TYPE VALUE listener_networks string ((name=network1)(local_listene

r=LISTENER_CDB1)(remote_listene r=LISTENER_CDB2))

local_listener string LISTENER_CDB1 remote_listener string LISTENER_CDB2


NAME TYPE VALUE listener_networks string ((name=network1)(local_listene

r=LISTENER_CDB2)(remote_listene r=LISTENER_CDB1))

local_listener string LISTENER_CDB2 remote_listener string LISTENER_CDB1


CON_ID CON_NAME OPEN MODE RESTRICTED 2 PDB$SEED READ ONLY NO 3 APP2 READ WRITE NO 4 APP3 READ WRITE NO 5 APP1 READ WRITE NO

CDB1 と CDB2 の両方において、ローカル・リスナーとリモート・リスナーが listener_networks パラメータで構成され定義されています。また、CDB1 は PDB APP1 をホストしています。次に、LISTENER_CDB1 への PDB APP1 のサービス登録を示します。このサービスでは複数のサービス・ハンドラが（この場合は同じサブネット上の）2 つのホストにわたって登録されていることに注意してください。これらのホストは別々のポート（LISTENER_CDB1 は host1:1523、LISTENER_CDB2 はhost2:1524）をリスニングしています。リスナーの相互登録のため、型が@host1:1523/app1 または@host2:1524/app1 である EZCONNECT 文字列によって接続が解決されます。




Handler(s):


LOCAL SERVER



REMOTE SERVER

(ADDRESS=(PROTOCOL=TCP)(HOST=host1.us.oracle.com)(PORT=1523))


REMOTE SERVER


PDB APP1 が HOST2 CDB2 に再配置された後に、HOST1 CDB1 の TNS LISTENER サービスに問い合わせると、現在は CDB2 でホストされていることがわかります。




Handler(s):


LOCAL SERVER


REMOTE SERVER



REMOTE SERVER




---------- ------------- ---------- ----------



注：CDB1 と CDB2 が登録されている単一リスナーは、共有されているリスナー相互登録のユースケースの、よりシンプルなサブセットです。また、Oracle Connection Manager（Oracle CMAN）を使用すると、バックエンドの TNS LISTENER にも TNS LISTENER の相互登録を行うことができます。


独立した TNS リスナー

ソース CDB とターゲット CDB が共通の TNS LISTENER ネットワークを共有しておらず、完全に独立している場合、クライアント接続転送を処理するためには TNS ネットワーク層への通知が必要です。Oracle Database 12.2 では、転送接続アドレスを登録済みのサービス・アドレス・エントリに埋め込む、SQL*Net 機能が導入されています。この変更を有効にして、この TNS トポロジでクライアント接続転送を処理する場合、共通ユーザーとしてターゲット CDB$ROOT から実行する再配置の正しい構文は次のようになります。

create pluggable database APP1 from APP1@dblink relocate

availability max;

この relocate availability max という構文は、TNS LISTENER ネットワークが完全に独立している場合に、SQL*NET レイヤーでクライアント接続転送を処理する必要があることを示す宣言です。このようなトポロジの例を次に示します。このデータベース・リスナー構成では、両方の CDBで 1 つのローカル・リスナーのみが識別されます。


NAME TYPE VALUE

-------------------- ----------- ----------------------


local_listener string LISTENER_CDB1

remote_listener string


NAME TYPE VALUE

-------------------- ----------- ----------------------


local_listener string LISTENER_CDB2

remote_listener string

LISTENER_CDB1 へのサービス登録に反映されているとおり、PDB APP1 は HOST1 CDB1 でホストされます。





Handler(s):


LOCAL SERVER

relocate availability max 句を含む relocate コマンドを実行すると、PDB APP1 がターゲットの HOST2 CDB2 に再配置され、元のホストである CDB1 の TNS LISTENER サービス・エントリのリスナー・サービス定義が次のように更新されます。


Service “app1" has 1 instance(s).

Instance "cdb1", status READY, has 1 handler(s) for this service...

Handler(s):

"COMMON" established:0 refused:0 state:ready

FORWARD SERVER

(ADDRESS=(PROTOCOL=TCP)(HOST=host2.us.oracle.com

(PORT=1524))


共有の TNS LISTENER ネットワーク

再配置操作に参加しているソース CDB とターゲット CDB の間に共有の TNS LISTENER ネットワークがある場合、SQL*Net レイヤーは、相互登録されている TNS LISTENER に固有のクライアント接続リダイレクションを暗黙的に処理します。以下の図 7 は、この再配置操作を示しています。


図7：TNS LISTENERの相互登録を使ったオンライン・データベース再配置

APP1 PDB が、CDB1 から CDB2 にオンラインで再配置されます 9。CDB は同じサーバーに併置される場合もあれば、同じキャビネットの別のサーバーや、地理的に離れた別のサーバーに配置される場合もあります。APP1 PDB が CDB1 でアクティブな間は、REDO、UNDO、DATA FILE のコピーがバックグラウンド操作として開始されます。APP1 PDB が CDB2 で開いているとき、CDB1 上のAPP1 PDB は閉じています。APP1 PDB が開いているときは、APP1 PDB サービスが TNS LISTENERに登録され、CDB2 で使用できます。クライアントによる alter pluggable database APP1

open 文の実行時間に影響が出る可能性があります。これは、オンライン・データベース・プロビジョニングの項で説明したように、メディア・リカバリが実行され、END CLONE SCN の時点における CDB2 上の APP1 PDB のトランザクション状態が一貫している場合です。

注：ビューv$session_longops10に問い合わせることにより、すべてのオンライン・プロビジョニング操作の FILE コピーの進捗を監視できます。

CDB$ROOT@CDB2-SQL> select opname, message from v$session_longops

OPNAME MESSAGE

------------------ ------------------------------------

kpdbfCopyTaskCbk kpdbfCopyTaskCbk: /u01/app/oracle/or

adata/cdb1/CDB :904448 out of 90444

8 Blocks done

9 cdb_pdbs ビューと dba_pdbs ビューには、新しい 2 つのステータス・フラグ（RELOCATING と RELOCATED）があります。これらのステータス・

フラグは、ステータス診断や、再配置の実行に'availability max'句が使用されたかどうかの識別に便利です。

10 このビューでファイル・コピー操作に関連する OPNAME は、kpdbfCopyTaskCbk（データファイル・コピー）と kcrfremnoc（REDO ファイル・コ

ピー）です。


独立した TNS LISTENER ネットワーク

TNS LISTENER ネットワークが独立しており、relocate availability max が使用されている再配置操作では、ターゲット CDB で再配置されたデータベースが開かれるときに、ソース CDB 上の TNS LISTENER によって、再配置される PDB で定義されているすべてのサービスの登録済みサービスが更新されます。この PDB には、上記の例のように、新しいホスティング先の TNS LISTENER（ポート 1524 をリスニングする HOST2）への転送アドレスが埋め込まれています。

図 8 に示すとおり、このトポロジと再配置操作では、次の点に注意することが重要です。

» ターゲット CDB で alter pluggable database APP1 open;が実行されるまでは、ソースのホスティング CDB で、再配置中の PDB を引き続き利用できます。

» データファイル・コピーと反復的な REDO Apply はバックグラウンドで実行され、最終的な再配置操作より前に実行できます。たとえば再配置を金曜日に開始し、再配置された PDB を日曜日に開いて、その翌日からの業務に備えることができます。

» この TNS LISTENER トポロジには、relocate availability max 句が必要です。

» 再配置中の PDB が、新しいホスティング CDB で開かれると、次のようになります。

» ソース PDB の転送アドレスを定義する listener_networks が更新されます。また古いホスティング CDB の TNS LISTENER 上のリスナーPDB サービスが、この転送アドレスを使って更新されます。

» 内部的には、再配置された PDB が最初に読取り専用で開かれます。

» 読取り専用接続は、ただちに新しいホスティング TNS LISTENER に転送されます。また、新しい読取り/書込み接続は新しいホスティング CDB の TNS LISTENER に転送され、APP PDB が一貫したトランザクション状態で開かれるまで、ここで回転します。

» ソース PDB で shutdown immediate が実行され、永続的接続が終了します。

» 内部でツームストンと呼ばれるソース PDB のアーティファクトは、元のホストに残ります。

図8：TNS LISTENER接続を転送するオンライン・データベース再配置


注：Oracle Application Continuity11を使用する場合、永続的接続は終了するものの、そのトランザクションは再実行されるため、停止がマスクされ、さらにはビジネス継続性が維持されます。

ツームストン

保持されているツームストンとは、共有の SQLNET LISTENER ネットワークがなく、availability max 句が使用される場合のオンライン再配置操作に固有の PDB アーティファクトです。ツームストンによって、古いホスティング CDB 内の PDB 名前空間が保持されます。そのため、SQLNET LISTENER のサービス接続転送が削除されないと、その CDB で同じ名前の PDB を作成することはできません。つまり、ツームストンが存在する間は、元のホスティング CDB に再配置しなおすことができます。接続転送は、クライアント接続文字列が更新されるまでの一時的な状態です。クライアント接続は、Oracle Internet Directory（OID）またはその他の LDAP 機能によりネゴシエートして、クライアント接続管理を簡素化するのがベスト・プラクティスです。接続文字列が更新されて新しいホスティング CDB の SQLNET LISTENER を指すようになれば、ツームストーン・アーチファクトを削除でき、制限が解消されます。12

顧客のユースケース – ハイブリッド・クラウドでの双方向のOracleデータベース再配置

ハイブリッド・クラウドでの双方向のデータベース再配置には、さまざまなユースケースがあります。たとえば、ワークロード管理のためのクラウド拡張、パッチ適用やアップグレード（HW、OS、CDB、または PDB）、Oracle Cloud へのアプリケーション移行、オンプレミスや Oracle Cloud に配置されている品質の異なるデータベース・クラウド・サービス間のデータベース移行などです。以下の図 8 は、双方向のハイブリッド・データベースの再配置操作のユースケースを示しています 13。この場合、本番データベース、テスト・データベース、開発データベースを、クラウドに'拡張'することで、即時処理またはスケジューリングされた処理に使用できるコンピューティング・リソースを増やしたり、ワークロードを一時的にクラウドにオフロードして、オンプレミス・ワークロードへのコンピューティング・リソースの割当てを増やしたりしています。

11 Oracle Database 12c Release 2 によるアプリケーション・コンティニュイティについて詳しくは、

http://www.oracle.com/technetwork/database/database-cloud/private/application-continuity-wp-12c-1966213.pdf を参照してください。

12 接続転送は、通常の PDB と同様に、ツームストーンを削除することで停止できます。

DROP PLUGGABLE DATABASE <pdbname> INCLUDING DATAFILES 13 「Hybrid Cloud Agility Begins with a Multitenant Architecture」（https://www.youtube.com/watch?v=uP1aWuzYWmo）を参照してください。

このプレゼンテーションでは、アプリケーションにおける永続的な、位置の透過性およびオンライン・データベースの再配置サービスについて説明

しています。このソリューションによって、ソフトウェアの迅速な開発ライフサイクルと管理を低コストで実現するオプションが提供されます。

http://www.oracle.com/technetwork/database/database-cloud/private/application-continuity-wp-12c-1966213.pdf

http://www.oracle.com/technetwork/database/database-cloud/private/application-continuity-wp-12c-1966213.pdf


図8：オンプレミスおよびモバイル・デバイスからの、ハイブリッドな双方向のPDB再配置

別のユースケースとして、モバイルでのアプリケーション開発があります。この場合、リモートで作業するアプリケーション開発者が最新バージョンのアプリケーションや関連するデータベースをクラウドとの間で簡単に再配置して、テストや開発に利用できます。

結論

Oracle Multitenant はコンテナ・データベース・ソリューションであり、コンテナ・データベース（CDB）がプラガブル・データベース（PDB）と呼ばれるホスト対象テナントに対して、データベースのコンピューティング・インフラストラクチャを提供します。オペレーティング・システムの仮想化は不要です。PDB は各アプリケーションの自己完結型データベースで、SYSTEM、SYSAUX、USER、UNDO という固有の表領域と関連するデータファイルが含まれます。この自律性と、ある程度の独立性によって、このホワイト・ペーパーで説明したようなオンラインの移植性とプロビジョニング・サービスが可能になります。クライアントへの影響はほとんど（またはまったく）なく、アプリケーションの変更も不要です。Oracle Multitenant アーキテクチャでは、大まかな（または細かい）管理が可能です。たとえば 1 人の特権ユーザーが、パッチ適用、アップグレード、およびバックアップを単一エンティティとして実行して、CDB 全体とすべてのホスト対象テナントを管理できます。または、管理タスクを特権ユーザー（PDB ADMIN）に委任して、個々の PDB のコンテキスト内で管理させることもできます。Oracle Multitenant のオンライン・プロビジョニングおよび再配置サービスは完全統合型の機能であり、Oracle Cloud、顧客のオンプレミス、およびハイブリッドクラウドの運用に対応しています。

Oracle Database 12c Release 2（12.2）は Oracle Cloud で（またはダウンロードして）利用できます。この製品によって、パフォーマンスの低下なしで最適な組み合わせのエンタープライズ・テクノロジーを簡単に低コストで導入でき、投資効果もすぐに把握できます。Oracle Cloud の管理インタフェースはオンプレミスと同じであり、新しい管理スキル・セットは不要です。Oracle Multitenant 12.2 は、Oracle Database Cloud の完全マネージド型データベース・サービスを支えるデータベース・アーキテクチャです。Oracle Multitenant 12.2 の利点は、このホワイト・ペーパーで説明した双方向のデータベース・プロビジョニングや、クラウド間、オンプレミス、またはハイ


ブリッド・クラウド運用でのリフレッシュおよび再配置サービスだけではありません。以前は CDBあたり 256 個の PDB であった統合数が Oracle Multitenant 12.2 では増加し、4096 個のホスト対象PDB テナントを単一 CDB に高密度で統合できます。また、パッチ適用、アップグレード、高可用性をまとめて継続的に管理できます 14。効率的でセキュアなデータベース・プロビジョニングに関連する、Oracle Database 12c Release 2 のその他の機能としては、PDB レベルのパフォーマンスおよびロックダウン・プロファイルがあります。これはデフォルトの（またはユーザーが構成した）CPU、I/O、メモリのデータベース・リソース管理ポリシーとデータベース・ロックダウン・セキュリティ機能を、個々の PDB のコンテキストに組み込むものです。PDB がプロビジョニングされると、パフォーマンスとセキュリティのプロファイルがクローン・イメージに'埋め込まれ'て定義され、PDB が開くと有効になります。これらの各機能（ホット・クローン、リフレッシュ可能クローン、データベース再配置、CPU、I/O、メモリの細かいリソース管理によるスケーラブルなテナント密度、詳細なロックダウン・プロファイル）は、パブリック、プライベート、またはハイブリッドのクラウド・モデルにおける信頼性の高い、セキュアな、非常にスケーラブルであっても管理しやすいクラウド・デプロイメントに必須です。

14 Oracle Multitenant は Oracle RAC および Oracle Data Guard に完全に対応しており、HA を非常に簡単に管理できます。Oracle Multitenant を使用

すると、すべてのホスト対象テナントが一括管理され、CDB で構成されている HA の利点を享受できます。

Oracle Corporation, World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065, USA

海外からのお問い合わせ窓口

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

C O N N E C T W I T H U S

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

Copyright © 2017, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載され

る内容は予告なく変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による

明示的保証や法律による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証およ

び条件も提供するものではありません。オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的また

は間接的に確立される契約義務はないものとします。本文書はオラクルの書面による許可を前もって得ることなく、いかなる目的

のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。

Oracle および Java は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

Intel および Intel Xeon は Intel Corporation の商標または登録商標です。すべての SPARC 商標はライセンスに基づいて使用される

SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMD ロゴおよび AMD Opteron ロゴは、Advanced Micro

Devices の商標または登録商標です。UNIX は、The Open Group の登録商標です。0116

Oracle Multitenant のデータベース・プロビジョニング – Oracle Database 12c Release 2（12.2）

2017 年 1 月

著者：John P. McHugh、Oracle Database Multitenant Product Management

共著者：Sanket Jain、Giridhar Ravipati、Patrick Wheeler、Can Tuzla

Documents

Oracle Multitenant のデータベース・プロビジョニ …...Oracle Database 12c Release 1（12.1）のOracle Multitenantは、自動化しやすいシンプルなコマンド