Database Support Blog

  • Oracle Database
2014.01.28

移行前に知っておきたい、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におけるリソース制御と移行方法について解説します。


連載記事

移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.2
移行前に知っておきたい、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 Database
2024.04.08

【Oracle Database】FAQで安定運用に貢献!サポートセンターのナレッジ公開の取り組み

アシストオラクルサポートセンターが公開しているFAQは、仕様に関するQAやエラー発生時の対処方法などはもちろん、不具合情報や障害発生時の情報取得方法といった安定運用に役立つ内容も扱っています。そのFAQをどのように作成しているのか、サポートセンターの取り組みをご紹介します。

  • Oracle Cloud
  • Oracle Database
2024.02.02

OCIにおけるOracle Database 11g R2、12g R1、12g R2の新規プロビジョニング終了とその影響

Oracle Databaseのバージョン11g R2、12g.R1、12g.R2は既にすべてのメーカーサポートが終了しています。OCIのBase Database Serviceでも2024年1月中旬ころから11g R2、12g R1、12g R2での新規プロビジョニングができなくなりました。

  • Oracle Database
  • その他
2023.12.21

【Oracle Database】サポートセンターでの生成AI(Glean)活用

アシストでは全社員にAIアシスタントGleanを導入しました。サポートセンターで2ヶ月間使ってみて感じた効果やメリットをお伝えします。

ページの先頭へ戻る