12cのマルチテナントなら、既存データベースの段階的移行がスムーズに。柔軟なパッチ適用など運用管理でも大きなメリット：Oracle ExadataでDBaaS構築！ 知っておきたい大切なポイント（2）（1/2 ページ）

Oracle DatabaseによるDBaaS構築で課題となることの1つが、Oracle Databaseの旧バージョンで稼働する既存データベースをいかに円滑に移行するかということだ。12cの新機能であるマルチテナントアーキテクチャを使えば、この移行作業をスムーズに行い、統合後のパッチ適用なども楽に行えるようになる。その具体的なシナリオを紹介しよう。[プライベートクラウド/データベース統合][Oracle Database 12c]

[PR／＠IT]

PR

これからデータベース統合基盤を作るなら12cで始めるのが最適

日本オラクル データベース事業統括 データベースエンジニアリング本部 Database & Exadata技術部 技術レディネスグループ プリンシパルエンジニアの諏佐嘉之氏

　社内に散在するOracle Databaseを集約したデータベース統合基盤、さらにはデータベースクラウド（DBaaS：Database as a Service）を構築する際に重要な検討事項の1つとなるのが、既存のデータベースをいかに円滑に集約しつつ最新バージョンに移行し、データベース統合の目的である「効率的なリソース活用と運用管理」を実現するかということだ。単に既存データベースを1つのハードウェア上に寄せ集めることだけを考えていたのでは、これらの目的を達せられない可能性がある。

　この課題に応えるべく、「Oracle Database 12c」で導入された機構が「マルチテナントアーキテクチャ」だ。これは個々のデータベースを「プラガブルデータベース（PDB：Pluggable Database）」として仮想化し、それを「マルチテナントコンテナデータベース（CDB：Multitenant Container Database）」と呼ばれる“器”の上で動作させるという仕組みである。これからOracle Databaseの導入を考える場合、そのバージョンとして11g R2と12cが候補に挙がるだろうが、データベース統合やその後のアップグレードのやりやすさという観点からも、また次の記事で説明しているサポート期間も考慮したライフサイクル管理の観点からも、12cが最有力の選択肢になると思われる。

関連記事

• Oracle Databaseをこれから導入。11gにするか？ それとも12cか？ データベースクラウド構築時のバージョン選定の指針

効率的なデータベース統合を実現するマルチテナントアーキテクチャ

　データベース統合の手法としては、これまでインスタンス統合とスキーマ統合が主に使われてきた。このうちインスタンス統合とは、単一またはクラスタ化したハードウェアリソースの上に複数のデータベース（インスタンス）を統合するという手法だが、この手法にはデータベースの集約密度をさほど高められず、ハードウェアリソースの利用効率が上がらないという難点がある。なぜなら、各データベースは統合前とほぼ同じサイズのリソースを必要とするからだ。

　一方、スキーマ統合とは、その名の通りデータベースをスキーマレベルで集約し、インスタンスの数を削減するというアプローチである。このアプローチには、インスタンス統合よりもデータベースの集約密度が高まり、ハードウェアリソースを効率的に利用できるという利点がある。しかし、データベースやアプリケーションの改修が必要となる場合が多く、それに要するコストが大きなネックとなる。

　Oracle Database 12cは、従来の手法が抱えていたこれらの課題を、新機能のマルチテナントアーキテクチャによって解消する。同アーキテクチャでは、複数のPDB間でのリソースの共有を可能にしており、オーバーヘッドが少なく、データベースの集約密度を高めてハードウェアリソースを効率的に利用できる。また、PDBは従来のデータベースと同様にアクセスすることが可能であり、スキーマ統合のような手間もかからない。CDB単位でのバックアップが可能であるなど、個別にデータベースを運用するよりも管理工数を削減できることも大きなメリットだ。

　日本オラクルの諏佐嘉之氏（データベース事業統括 データベースエンジニアリング本部 Database & Exadata技術部 技術レディネスグループ プリンシパルエンジニア）は、マルチテナントアーキテクチャによるデータベース統合について、「インスタンス統合とスキーマ統合のメリットを掛け合わせたようなアプローチ」だと話す。このマルチテナントアーキテクチャを活用することで、既存データベースの統合だけでなく、その後の12cへの移行、さらにはパッチ適用などの運用管理がスムーズに行えるようになるのだという。

　「今日、多くの企業がOracle Database 11g R2でデータベースを運用しています。11g R2は2015年1月にPremier Supportが終了し、その3年後の2018年1月にExtended Supportが終了するため、多くの企業で今後4年以内にOracle Database 12cへアップグレードすることが見込まれています。その際、マルチテナントアーキテクチャを利用すれば、検証にかかる負担を軽減し、本番環境への移行を段階的かつスムーズに行えるのです」（諏佐氏）

　具体的には、次のようになる。まず、Oracle Recovery Manager（RMAN）などを使ってOracle Database 11gの本番環境のデータベースを複製する。この複製データベースをPDBに構成変更し、「Oracle Database 12c＋マルチテナントアーキテクチャ」構成の検証環境（ステージング環境）のCDBにプラグインするのだ。仮想的なデータベースとして扱えるPDBにしておけば、クローニングの機能を使って簡単にデータベースを複製することが可能となり、テスト用データベース環境を複数用意する際の構築にかかる手間を省ける。本番環境への移行においても、ステージング環境の構築と同様に、PDBを本番環境のCDBにプラグインするだけで済むため、スムーズに移行作業を進められるというわけだ。

　また、ステージング環境の規模を小さくできることも、マルチテナントアーキテクチャを利用したDBaaS環境のメリットだと諏佐氏は説明する。

　「従来のサイロ型システムでは、データベースごとにステージング環境を用意するケースが少なくありませんでしたが、DBaaSとしてデータベースを統合すれば、これも1つに集約できます。加えて、マルチテナントアーキテクチャであればPDB単位で各種の検証やテストが行えるので、全てのデータベースを1度に検証するためのリソースを用意する必要はありません。これにより、ステージング環境をコンパクトにできることもマルチテナントアーキテクチャの大きなメリットです」（諏佐氏）