移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.2

前回はOracle Database 12c（以下、12c）の目玉機能であるOracle MultitenantのUnplug/Plugとクローンにおける内部動作、処理時間について解説しました。今回はOracle Multitenantのリソース制御や現行データベースからマルチテナントに移行する方法について取り上げます。

※Oracle Multitenantの概要は「連載：徹底解説！Oracle Database 12cのすべて」の中で解説していますので、併せてご参照ください。

Oracle Multitenantはインスタンスやバックグラウンド・プロセスを共有しながらデータベース層でマルチテナントを実現する機能です。クラウドやデータベースの統合において集約率を高める効果が期待されますが、リソース制御というマルチテナントならではの考慮が必要になります。

例えば同じサーバ内でA社、B社、C社のデータベースがそれぞれ稼働している場合、A社が負荷の高い処理を実行するとB社とC社にも影響が出てしまいます。このような状況を防ぐためにCPUやメモリ、I/Oといったリソースの上限を設けたり、あるいはデータベースの重要度に合わせて優劣をつけるなどの設定が必要になります。Oracle Multitenantがどのようなリソース制御に対応しているのか、また運用に合わせてどの程度柔軟に調整できるのかを理解しておかなければ、活用シーンは見えてこないでしょう。

結論から言うと、Oracle Multitenantの機能として実装されているリソース制御は「CPU」、「I/O（Oracle Exadata Database Machineのみ）」、「パラレル実行」の3つです。メモリについてはインスタンスを共有して集約率を高めるという仕組みを採用しているため、プラガブル・データベース（PDB）単位での割り当て制御はできません。重要度の高いPDBとそうでないPDBで使用できるメモリ量に差をつけたい場合、コンテナ・データベース（CDB）を分ける必要があります。

CPUについてはPDB単位とCDB単位の両方で制御することができ、PDB単位で制御する場合には以下のように「share」と呼ばれる比率を設定します。考え方は非常にシンプルで、例えばshareが1に設定されているPDBと2に設定されているPDBがある場合、CPU使用率が1:2の比率で調整されます。もし運用中にPDBが追加されたとしても、shareの設定値に基づいて比率が再計算されるため、ユーザがその都度設定を変更する必要はありません。

このように分かりやすい仕組みで実装されているPDB単位のCPU制御ですが、気になるのはその正確性と即効性です。ソフトウェアの機能で制御しており、ハードウェア面で物理的な制限をかけているわけではないので、こちらの意図どおりにCPUが制御されるかは十分な検証が必要です。また、Oracle Multitenantでは運用中にPDBの追加や削除が発生するため、その場合に速やかな制御が行われるかも気になるところです。

そこで実際にPDB単位のCPU制御を行ってみた結果が以下のグラフです。CPUバウンドのプログラム（CPUを大量に使用するプログラム）を実行し、PDB2とPDB3をオンラインで追加した際のCPU使用率を色分けしています。PDBが増えると多少ぶれ幅が出てくるものの、ほぼshareの設定どおりにCPUを制御できています。PDBを追加した際も即時に設定が有効化されており、即効性にも優れていることが分かります。

PDB単位のCPU制御は、Oracle Database Resource Managerにより行われており、この時の待機イベントを確認すると「resmgr:cpu quantum」が大量に発生しています。これはデータベースの内部実行キューによってCPU使用率を調整中であるという動作を意味するもので、サーバで有効になっているコア数（今回の検証環境では24）を超えたセッションを待機させています。

動作としてはOSのスケジューラによく似ており、一定の短い時間（100msec）だけプロセスを実行して待機状態にし、別の実行可能なプロセスを選択して実行するという処理を繰り返します。ラウンドロビンのアルゴリズムを採用しているため、特定のプロセスだけが長時間待機してしまうことはありません。また、ロック待ちやI/O待ちが検出されるとすぐに別のプロセスが選択されるため、不要な待機は発生しないようになっています。シンプルでありながら無駄のないCPU制御ができる仕組みと言えます。

Oracle Multitenantでは、CDB単位でCPUを制御することもできます。CDBの数はできるだけ少なくすべきですが、データベースのキャラクタセットや標準ブロック・サイズが異なるケースでは、1つのCDBにPDBを集約することができません。そのため、CDBが複数稼働するというのは構成上十分にあり得ます。

CDB単位でCPUを制御する方法は2つあります。1つはインスタンス・ケージングを使用する方法です。インスタンス・ケージングはOracle Database 11g Release2（以下11gR2）で実装されたOracle Database Resource Managerの新機能であり、初期化パラメータのCPU_COUNTをインスタンスごとに設定します。先ほど説明したPDB単位のCPU制御と同様にOracle Database Resource Managerを使用しているため、データベースの内部実行キューで待機させることによってCPU使用率を調整します。

もう1つは12cから実装された初期化パラメータのPROCESSOR_GROUP_NAMEを使用する方法です。PROCESSOR_GROUP_NAMEはLinuxのcgroupやSolarisのリソース・プールをOracle Databaseに対応させるための初期化パラメータで、指定したプロセッサ・グループに定義されているCPUだけを使用するよう制御します。

この2つの機能は一見同じものに見えますが、CPUをどの層で調整するのかが大きく異なるため、使用する際は明確な使い分けが必要です。以下のグラフはCDB単位のリソース制御結果を示したものですが、インスタンス・ケージングがすべてのCPUを平均的に使用しているのに対して、PROCESSOR_GROUP_NAMEは特定のCPUのみを使用しています。つまり、12cではインスタンスが実際にどのCPUを使用するのかというところまで指定できるのです。

PROCESSOR_GROUP_NAMEの活用シーンとして考えられるのは、NUMA（Non-Uniform Memory Access）との組み合わせです。NUMAノードとCDBを関連付けることで、常にローカル・メモリ上でインスタンスを稼働させることができるようになります。遅延が懸念されるリモート・メモリへのアクセスを回避することもでき、NUMA環境に適した制御が行えます。NUMAノードの中でさらにCPUを制御したい場合は、インスタンス・ケージングやshareを使用したPDB単位の制御を併用することもできます。

このようにOracle Multitenantには様々なCPU制御の方法があるため、どれを使用するかによってOSやハードウェアの選択肢が変わってきます。

Oracle Multitenantを検討するにあたっては、非マルチテナント環境からの移行方法についても理解しておく必要があります。基本的な考え方はこれまでの一般的な移行と同じですが、バージョンによって移行方法に差異があるのと、Oracle Multitenantならではの新しい移行方法が用意されています。各方法の難易度や移行時間の違いなどを抑えた上で、どれを選択するか判断しなければなりません。

①Export/Import （Oracle Data Pump）

現在サポートされているすべてのリリース、エディションに対応した最も一般的な方法です。Oracle Database 10g（以下10g）以降であればより高速なOracle Data Pump（以下Data Pump）を使用することができます。データの抽出から投入まで、ユーザが行わなければならない作業が多岐にわたるため、容易ではありません。また、ユーザ・データを含んだ中間ファイルが必要なため移行時間も長くなります。

②トランスポータブル表領域、フル・トランスポータブル Export/Import

トランスポータブル表領域は、10g（10.1.0.3以降）で使用できる機能です。①のExport/Importのようにユーザ・データを含んだ中間ファイルを生成する必要がなく、属性情報（メタデータ）だけを抽出したあとOS上に存在するデータ・ファイルを直接コピーするだけで移行が完了します。

トランスポータブル表領域はその名のとおり特定の表領域だけを移行するための機能でしたが、11gR2（11.2.0.3以降）ではデータベース全体を移行できるフル・トランスポータブル Export/Importが新しく提供されています。この機能を使えば、11gR2のデータベース全体を直接コピーし、PDBとしてOracle Multitenant環境に移行することができます。

③DBMS_PDBパッケージ

12cの非マルチテナント・データベースをPDBに移行するためのパッケージです。②のフル・トランスポータブル Export/Importと同じくデータベース全体をPDBとして直接移行することができます。属性情報の抽出すら必要ない最もシンプルな移行方法です。

他にもOracle Golden Gateを使って非マルチテナント・データベースとPDBを同期するといった移行方法も考えられますが、標準機能で実現できる方法はこの3つです。

移行方法の選定においてまず重要となるのは、現在使用しているデータベースのバージョンとエディションです。トランスポータブル表領域とフル・トランスポータブル Export/ImportはEnterprise Editionの機能であるため、Standard Editionの場合は従来のExport/ImportかData Pumpが主な移行方法となります。Enterprise Editionの場合はどの移行方法でも選択できますが、トランスポータブル表領域やフル・トランスポータブル Export/Importによる移行をお勧めします。

以下のグラフは各移行方法によってどの程度移行時間に差が出るのかを計測した結果です。ユーザ・データを含んだ中間ファイルが必要なData Pumpに比べて、フル・トランスポータブル Export/Importでは移行時間が1/5近くまで短くなっています。DBMS_PDBパッケージは対象バージョンが12c以降に限られてしまいますが、今回紹介する方法の中では最も短い時間で移行を終えることができます。

このように、移行方法によって移行時間や難易度が大きく変わってくるため、バージョンが古くExport/Importしか使えないという場合でも、一度11gR2や12cにアップグレードしてからフル・トランスポータブル Export/ImportやDBMS_PDBパッケージを使用することも視野に入れ、最適な移行方法を検討してください。

次回は12cで実装されたILM関連の新機能について検証結果を紹介します。

・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.1
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.3
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.4
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.5
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.6
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.7

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。