TOP>企業情報>コラム>技術情報>移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.1

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

Oracle Database 12c(以下、12c)の国内提供が開始されてから間もなく半年が経過します。次期システム更改に向けて検討を始めているという方も多いと思いますが、「初期リリース(Release 1)なので慎重に考えたい」というのが現場の本音ではないでしょうか。本連載では、現場目線で12cの新機能を検証し、マニュアルでは分からない新機能のオモテとウラに迫ります。

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

マルチテナントを使用する前にクリアすべき前提条件


12cで注目の機能と言えば、データベース層でマルチテナントを実現できるOracle Multitenantです。コンテナ・データベース(CDB)と呼ばれる器の中に、プラガブル・データベース(PDB)を最大252個作成でき、インスタンスやバックグラウンド・プロセスを共有することで集約率を大幅に高めることができます。

※Oracle Multitenantの概要は「連載:徹底解説!Oracle Database 12cのすべて」の中で解説していますので、併せてご参照ください。
 
プライベート・クラウドやデータベース統合といったシーンでの活用が期待される機能ですが、使用にあたってはいくつか前提条件があります。まずはこれらの前提条件をクリアしているか確認し、Oracle Multitenantがそもそも検討の土台に乗るものなのかを判断しましょう。

①エディションによる機能制限がある

Oracle Multitenantは、Enterprise Edition(以下、EE)で利用可能なオプションとして提供されています。EE以外のエディションでもCDBを作成することはできますが、PDBの数が1つまでに制限されており、実質「シングルテナント」の構成になります。プライベート・クラウドやデータベース統合を目的とするならば、EEの環境が必要です。

エディション 機能制限 PDB作成数の上限
Standard Edition One 制限あり 1
Standard Edition 制限あり 1
Enterprise Edition+オプション 制限なし 252


②組み合わせて使用できない機能がある

Oracle MulititenantはReal Application Clusters(RAC)やData Guardといった既存の機能と組み合わせて使用できますが、一部対応していなかったり使用が制限されている機能もあります。将来のリリースやパッチで解消されるかもしれませんが、初期リリースでは注意が必要です。

設定 組み合わせ可否
Heat Map(※1) 使用不可
Automatic Data Optimizaion(※1) 使用不可
フラッシュバック 機能制限あり。PDBに対しては使用不可
Enterprise Manager Database Express(※2) 各PDBに対して構成が必要。CDB全体を管理する場合、Cloud Controlが必要。


(※1)12cの新機能です。概要については「 こちらの資料 」(日本オラクル社作成)をご参照ください。
(※2)12cではEnterprise Manager Database Controlが廃止され、Database Expressに変更されました。


③マルチテナント化できないケースもある

Oracle Multitenantには、「PDB単位で設定できるもの」と「CDB単位で設定できるもの」があります。例えばデータベースのタイム・ゾーンはPDB単位で個別に設定できるため、マルチテナント化したとしても全く影響はありませんが、データベースのキャラクタ・セットや標準ブロック・サイズはCDB単位でしか設定できません。要件があまりに違うデータベースが存在する場合、マルチテナント化できないこともあります。その場合、CDBを分けるという選択肢も視野に入れる必要があります。

上記3つの前提条件をクリアできれば、Oracle Multitenantの採用を本格的に検討できる状態にあると言えます。最も大きな壁はエディションによる機能制限で、オプションという新規投資が必要になりますが、マルチテナント化によるハードウェアや管理コストの削減といったメリットも生まれます。Oracle Multitenantが集約率を高めるための機能であることを理解し、ソフトウェアだけではないトータル・コストで検討できるかが採用のポイントになります。

Unplug/Plugの処理時間と性能への影響


Oracle Multitenantには「プラガブル(着脱可能)」という発想を活かしたユニークな機能が搭載されており、以下のようにPDBを取り外して別のCDBに接続することができます。これはPDBのUnplug/Plugと呼ばれ、ハードウェアのメンテナンスやリソースの調整など別の筐体でPDBを稼働させたい場合に使用しますが、どの程度時間がかかるのか、他のPDBに影響がないのかなど気になる点もあります。

PDBのUnplug/Plug

PDBのUnplug/Plug

まず前提として、PDBのUnplug/Plugはオフラインで行う作業です。筐体間を移動するというとvMotionのようなほとんど無停止に近いものをイメージするかもしれませんが、そうではありません。必ず停止時間が発生することを考慮しておく必要があります。

Unplug/Plug時の内部動作は以下のようになっており、共有ディスクを使用しているか否かによって停止時間は大きく異なってきます。共有ディスクを使用していない場合は③のステップでファイルの転送が発生するため、ファイルのサイズに比例して停止時間が長くなりますが、共有ディスクを使用している場合はファイルのサイズに関係なく10秒ほどで処理が完了します。

Unplug/Plug時の内部動作と停止時間

Unplug/Plug時の内部動作と停止時間

このとき、Unplug/Plugの対象ではない他のPDBで実行されているトランザクションを確認してみると、全くと言って良いほど影響を受けていないことが分かります。当然ながらファイルの転送が発生するとディスクの書込みやネットワークの負荷による影響を受けますが、共有ディスクを使用している場合はUnplug/Plugを頻繁に行ったとしてもほとんど影響はありません。

Unplug/Plug中の他PDBへの影響

Unplug/Plug中の他PDBへの影響

PDBのUnplug/Plugには決まった使い方があるわけでなく、メンテナンス時の一時退避やバージョンアップにおけるExport/Importの代替など様々な活用方法が考えられます。機能の説明だけを見るとついつい期待が独り歩きしてしまいますが、停止時間が許容範囲に収まるケースでの使用を検討してください。

PDBクローンの処理時間と最適な手法


先ほど紹介したPDBのUnplug/Plugは「カット&ペースト」のような機能ですが、12cでは「コピー&ペースト」のようにPDBのクローンを作成することもできます。予め必要なデータを格納したPDBをテンプレートのようにユーザに配布したり、本番と同じデータを開発に持っていく場合に使用する機能ですが、クローン作成にどの程度時間が必要なのか理解しておかなければなりません。

PDBのクローン

PDBのクローン

PDBのクローン作成にもいくつか前提条件があります。まず、対象のPDBを読み取り専用でオープンしなければなりません。当然ながら更新系の処理は実行できなくなるため、業務に影響の出ないタイミングで実行する必要があります。また、マニュアルにはデータベース・リンクを経由して別筐体にPDBのクローンを作成できると書かれていますが、初期リリースでは不具合があり動作しないため注意が必要です。初期リリースで行えるのは、ローカルでのクローン作成のみです。

クローンの作成には、スナップショットを使う/使わないの2種類があります。スナップショットはZFS、ACFS、NetAppに対応しており、以下のように500GBのクローンが25MBになるなど容量を大幅に削減することができます。ただし、ACFSのようなCopy-On-Write(COW)方式のスナップショットを使用した場合、ソース(ポインタの参照先)となるPDBの削除やUnplugはできなくなります。

ACFSスナップショットを使用したPDBのクローン

ACFSスナップショットを使用したPDBのクローン

気になるクローン作成の処理時間ですが、スナップショットを使用しない場合は物理的なファイルのコピーを行うため、データ・ファイルのサイズに比例して処理時間は長くなります。データ・ファイルの中にいくつデータがあっても処理時間には関係ありません。

以下のグラフは100GBのPDBのクローンを作成した際の処理時間です。参考までにData PumpのExport/Importを使用した時間も計測してみましたが、パラレル度を増やしてチューニングしても中間ファイルのないPDBクローン作成のほうが高速です。ただし、Data Pumpの場合はパラレル度をユーザが指定できるのに対し、PDBのクローン作成では一切指定ができません。パラレル度はデータ・ファイル数に応じて自動決定されるため、合計が同じサイズでもデータ・ファイルの数がいくつあるかによってクローン作成の時間が変わってきます。データ・ファイルを細かく分ける設計にしておいたほうが、クローン作成は高速になります。設計に左右されず一定の時間内にクローンを作成したいのであれば、スナップショットを使用したほうが良いでしょう。

100GBのPDBをクローンするのに必要な時間

100GBのPDBをクローンするのに必要な時間

このように、12cの新機能には検証してみなければ分からない事実が数多く存在します。マーケットのメッセージやマニュアルだけではなく、もう一歩踏み込んだ内容をもとに吟味することで、現場の助けとなる新機能がどれなのか、見定めることができるはずです。

次回はOracle Multitenantにおけるリソース制御と移行方法について解説します。


執筆者紹介

関 俊洋(Toshihiro Seki)

株式会社アシスト データベース技術本部

2006年、株式会社アシスト入社。データベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やハードウェアとデータベースを組み合わせたソリューション(DODAI)の立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆・講演活動を行っている。『SQL逆引き大全363の極意』共著。

関の紹介記事はこちら

「移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ」
連載記事一覧

オンライン・セミナー続々公開中!

アシストでは、全国どこからでも好きな時間に参加できるOracle Databaseのオンライン・セミナーを開催しています。アーキテクチャの基礎からEnterprise Managerやバックアップなどの運用テクニック、12cやアプライアンスといった最新情報まで20種類以上のコンテンツを用意しています。便利なオンライン・セミナーに是非ご参加ください。

関連製品


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る