Database Support Blog

  • Oracle Database
2014.02.10

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

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

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


Vol.2 12cのマルチテナントは本当に“使える”機能なのか?(後編)


※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制御

PDB単位のCPU制御

CPU制御の裏側では何が起きている?


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

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

各PDBにおけるCPU使用率の推移

各PDBにおけるCPU使用率の推移

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

CPU制御時のアクティブ・セッション数と待機イベント

CPU制御時のアクティブ・セッション数と待機イベント

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

CDB単位のCPU制御は2種類ある


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

CDB単位のリソース制御

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を使用するのかというところまで指定できるのです。

CDB単位のリソース制御結果と、特定CDBにおけるコア別の使用率

CDB単位のリソース制御結果と、特定CDBにおけるコア別の使用率

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

PROCESSOR_GROUP_NAMEとNUMAの組み合わせ

PROCESSOR_GROUP_NAMEとNUMAの組み合わせ

このように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以降に限られてしまいますが、今回紹介する方法の中では最も短い時間で移行を終えることができます。

300GBの非マルチテナント・データベースをPDBに移行するのに必要な時間

300GBの非マルチテナント・データベースをPDBに移行するのに必要な時間

このように、移行方法によって移行時間や難易度が大きく変わってくるため、バージョンが古く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


執筆者のご紹介

アシスト関 俊洋

関 俊洋
クラウド技術本部

2006年入社。データベース・システムの構築や運用トラブルの解決といった業務を経験し、その後新製品の検証やソリューションの立ち上げを経てエバンジェリストへ。2016年にクラウド事業を立ち上げ、現在はクラウドとデータベースの二足の草鞋を履いている。...show more

本記事をご覧いただいている方へのご案内

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


■本記事の内容について
 本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
 ・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
 ・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
  文中の社名、商品名等は各社の商標または登録商標である場合があります。

関連している記事

  • Oracle Cloud
  • Oracle Database
2024.12.02

OCIでGPUインスタンスを構築してみた

OCIで提供されている生成AIサービスとGPUインスタンスを前回の記事「生成AIにGPUが適している理由」で紹介しました。本記事では、GPUインスタンスをデプロイして、インスタンス上でLLM(大規模言語モデル)の動作環境を構築する方法をご紹介します。

  • Oracle Cloud
  • Oracle Database
2024.11.15

Oracle Cloud VMware SolutionにおけるVMware HCXとは?

前回の記事でお伝えしたとおり、OCVSを構築するとVMwareの複数の機能が利用可能です。 それらの機能の中で、今回はHCXの概要や具体的な機能、OCVSでHCXを利用するメリットなどをお伝えします!

  • Oracle Database
  • Oracle Cloud
2024.11.05

Oracle Database 23ai新機能!メモリーを有効活用する統合メモリー管理

2024年5月にOracle Cloud環境にて、先行してOracle DB 23aiがリリースされました。 Oracle Base Database ServiceにおけるOracle Database 23aiの検証結果を報告します。 今回は「統合メモリー管理」をテーマにお伝えします。

ページの先頭へ戻る