Oracle Database 12c によるデータベース統合

そんな課題にお応えするのが、Oracle Database 12c の「マルチテナント・アーキテクチャ」です。

Oracle Database 12c のマルチテナント・アーキテクチャ

Oracle Database 12c では、「マルチテナント・アーキテクチャ」という新しいデータベース構成を採用しています。
マルチテナント・コンテナ・データベース（CDB）というデータベース上に、仮想的なデータベースであるプラガブル・データベース（PDB）を複数搭載することにより、より柔軟で効率的なデータベース統合を実現します。

サーバリソース徹底的に節約して、利用効率を向上！

従来のデータベースは、データベースごとにメモリやプロセスといったリソースを確保していました。
CDBでは、それらのリソースをPDB間で共有化するため、データベースごとにリソースを確保する場合よりも、サーバリソースを効率良く運用することができます。
アプリケーションやデータベースを変更することなく、CDB上で稼動させることができます。

運用管理の手間 と コストを劇的に削減しながら、性能向上！

Oracle Database 12c のマルチテナント・アーキテクチャでは、管理性が格段に向上し、運用コストの削減が可能です。

従来のデータベース環境では、データベースごとに、パッチ適用やアップグレード、バックアップなどの管理が必要でした。 Oracle Database 12c のマルチテナント・アーキテクチャでは、複数のPDBをCDBへ統合することにより、それらの適用を1度にまとめて行うことができます。

CDBへ統合した場合でも、ユーザやアプリケーションからは、単一のPDBを、通常のデータベースと同様に扱うことができます。そのため、アプリケーション側の変更も必要ありません。また、パッチ適用 / アップグレード / バックアップの適用をまとめて行うこともできますが、PDBごとに適用可否を選択することも可能です。

PDB統合による性能向上の仕組み

3種類のデータベース仮想統合環境における、CDBによるPDB統合の性能向上の仕組みをご紹介します。

データベースの統合方法に伴って、アクセスしたデータファイル内のデータを保持しておく「データベース・バッファ・キャッシュ」というメモリ領域の構造が変わってくるため、統合による性能向上はそれぞれの統合方法によって異なります。
従来のデータベース統合では、データベースごとにデータベース・バッファ・キャッシュが分割されているため、1つのデータベースに割り当てられるキャッシュ容量が小さくなっていました。
Oracle Database 12c のCDB上では、このデータベース・バッファ・キャッシュを、複数のPDBをまたいだ1つのデータベース・バッファ・キャッシュとして使用します。

容量の大きいキャッシュへ多くのデータを保持することができるPDB統合では、キャッシュヒット率が高くなり、ディスクにアクセスするよりも高速でデータを取得することができます。
全表検索（全表スキャン）などの場合でも、データをデータベース・バッファ・キャッシュに載せやすく、高速化に寄与します。

特にOracle Database 12c Enterprise Edition では、In-Memory Parallel Query が有効に動作し、その結果が性能に顕著に表れます。（2回目以降は、キャッシュから読み込み）
PDB統合は、データベース統合による運用管理性の向上だけでなく、性能向上も実現します。

容易なデータベースの追加・拡張

CDBに作成したPDBは、簡単にCDBから取り外したり、取り付けることができます。そのため、異なるCDBへ、PDBを簡単に取り付けることができます。
開発環境用のデータベースが必要になった場合も、PDBとして必要なときに必要な分だけクローンを作成することができるため、実データと同じデータベース環境で検証を行うことができます。従来は、開発用のサーバやOS、ミドルウェアやデータベースを構築する必要がありましたが、PDBでは、その必要はありません。アプリケーションの動作確認などの検証結果を早急にフィードバックしながら、短期間で高品質なアプリケーション開発を実現できるようになります。

Oracle Database 12c では、PDBを活用して簡単にデータベースの統合を実現することができるようになりましたが、他のサーバではサーバ統合を進めるにつれてハードウェアリソースが不足し、より大型のサーバに置き換える必要があります。そしてハードウェア不足によるサーバ移行に伴い、システム停止を余儀なくされ、膨大な移行費用が発生してしまいます。

SPARC M10 は、現在の企業で使われているデータベース規模を搭載するサーバとしては、ほぼ無限の拡張性を誇ります。PDBによりデータベース統合を進め、リソースが不足した場合はSPARC M10 を追加することで、リソース不足を回避できます。さらに、Building BlockによるSPARC M10 の追加では、システム停止をすることなくデータベースを拡張することができます。

リニアな拡張性

システムを無停止のまま、ほぼ無限に拡張できるUNIXサーバ SPARC M10 と、PDBによるデータベース構築が簡単にできるOracle Database 12c。この2つの組み合わせが、いかに最適であるかを確認しました。

Oracle Database 12c のPDBを、SPARC M10 上に増設していく際に、ハードウェアリソースを256コアで止めた場合と、1,024コアまで使いこなした場合の「平均レスポンス時間」と、「平均トランザクション数」を調査しました。

 ：平均トランザクション数    ：平均レスポンス時間

SPARC M10 のCPUリソースを増やしながら、Oracle Database 12c のPDBを仕様上最大の252個まで増加させた場合、システムのスループットがリニアに増加し、しかもレスポンス時間は一定に保たれていることを確認できました。
SPARC M10 は、Building Block方式やCPUコア アクティベーション等の機能により、数コアから最大1,024コアまで、1コア単位での拡張が可能なため、PBDに合わせた処理能力の増強が簡単に実現できます。

PDBによる段階的なデータベースの追加・統合を最大限に活かすことができるサーバが富士通のUNIXサーバ SPARC M10 であることがお分かりいただけたでしょうか。

ホワイトペーパー

PDBによるSPARC M10のシステムリソース追加について検証の詳細結果をホワイトペーパーにまとめました。

SPARC M10によるOracle Multitenantの活用 (1.23 MB ) （2015年7月）