統合データベース環境の運用効率化に「マルチテナント」と「Zero Data Loss Recovery Appliance」は使えるか?:データベースクラウドに求められる3つの要件(2)(2/3 ページ)
多数のデータベースを集約したプライベートクラウドの管理において、バックアップの運用をどうするかは悩ましい課題だ。データベースの数が多ければ当然、作業が煩雑になる他、作業ミスで重要なデータを失うリスクも高まる。Oracle Database 12cの「マルチテナントアーキテクチャ」と「Zero Data Loss Recovery Appliance」ならば、この問題をスマートに解決できる。[プライベートクラウド/データベース統合][高可用性/災害対策][Oracle Database 12c]
スキーマ統合の問題を解決するOracle Database 12cのマルチテナントアーキテクチャ
このようなスキーマ統合の問題を解決する技術として、Oracle Database 12cで導入されたのが「マルチテナントアーキテクチャ」だ。マルチテナントアーキテクチャでは、データベースごとにインスタンスを立ち上げるのではなく、「コンテナデータベース(CDB:Container Database)」と呼ばれるデータベース上で複数の仮想的なデータベースとして「プラガブルデータベース(PDB:Pluggable Database)」を実行することで、それぞれのデータベースの独立性を確保しながらインスタンス統合を行うことができる。
データベースのプロビジョニングやハードウェア間の移行が容易であることも、マルチテナントアーキテクチャの特徴だ。CDB内に簡単にPDBを作成できるのはもちろん、既存のPDBをベースにして新たにPDBを作成(コピー)したり、別のCDBからPDBを移動したりできる他、既存のデータベースをCDBに取り込むといったことも可能である。
データベースを複製する際、コピー元のデータを参照することでストレージの消費を抑える「スナップショット」と呼ばれる機能も用意されている。この機能を使った場合、複製されたデータベースが持つのはオリジナルのデータへのポインタだけとなるため、短時間でデータベースをクローニングできる他、ディスク容量の削減にもつながる。
スナップショットで作成したデータベースに対して更新処理を行うことも可能であり、その場合は変更されたデータだけがオリジナルとは別に記録される。このスナップショットの機能は、開発/テスト用のデータベースを作成するといった場面で特に威力を発揮するだろう。
マルチテナントアーキテクチャがデータベース運用を効率化
データベースのアップグレードに伴う負担を軽減できることも、マルチテナントアーキテクチャの利点である。具体的には、CDB単位で複数のデータベースをまとめてアップグレードすることが可能な他、事前にバージョンアップしたCDBを用意しておくことにより、PDB単位で段階的にアップグレードすることもできる。個々のデータベースの要件を考慮した柔軟なアップグレードが可能なのだ。
バックアップとリカバリについても、CDBとPDBのどちらの単位でも実行可能だ。複数のPDBをCDB単位でまとめてバックアップし、それを一括してリストアできる他、一部のPDBだけをリストアするといったことも可能となっている。
また、マルチテナントアーキテクチャには、各データベースに対するハードウェアリソースの割り当てを効率化するための「share」という概念に基づく仕組みが組み込まれている。リソース割当量をパーセンテージで固定的に指定した場合、新たなデータベースを追加した際に再計算が必要となり、設定作業が煩雑になる。それに対して、shareでは各データベースに設定された数値(share)の総和から、割り当てるリソースを自動算出する方式をとる。
これにより、例えばそれぞれ「1 share」と「2 share」を設定した2つのデータベースがある場合、「2 share」のデータベースには約66%、「1 share」のデータベースには約33%のリソースが自動的に割り当てられる。この環境に、さらに「1 share」のデータベースを追加すると、リソースの再計算が自動的に行われ、「2 share」のデータベースへの割り当ては50%、「1 share」のデータベースへの割り当ては各25%に変更される。マルチテナントアーキテクチャでは、このshareの仕組みによって効率的なリソース管理が実現されるのだ。
データベースのクローンを手軽に作成できるというマルチテナントアーキテクチャの利点を生かした使い方として、読み書きが可能な分析用サンドボックス環境の作成が考えられる。例えば、データウェアハウスで利用しているPDBのクローンを作り、データを変更した場合の影響を調べたり、索引の付加によるクエリ実行速度の変化を確認したりするわけだ。また、インメモリデータベース機能である「Oracle Database In-Memory」と組み合わせて、クローンとして作成したデータベースを高速な分析基盤として使うといった用途も考えられる。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- サービスレベルに応じてデータベースの可用性を確保する「Oracle Maximum Availability Architecture」とは何か?
Oracle Database 12cによるプライベートクラウド環境の構築に際して課題となることの1つが、必要な「可用性」をいかにして確保するかということだ。オラクルは、サービスレベル要件に応じてデータベースシステムの可用性を確保するためのブループリントとして「Oracle Maximum Availability Architecture」を提唱している。[プライベートクラウド/データベース統合][高可用性/災害対策][Oracle Database 12c] - データベースのバックアップ・リカバリは何が正解なのか
「社内に増え続けるデータベースのバックアップをスピード化/効率化し、データを確実に守りたい。しかも、リカバリは柔軟かつ迅速に」──そんなデータベース管理者の願いをかなえる製品が登場した。Oracle Databaseに最適化された「Zero Data Loss Recovery Appliance」だ。[運用管理効率化][高可用性/災害対策][プライベートクラウド/データベース統合][Engineered System] - NTTデータ先端技術が説く「Zero Data Loss Recovery Appliance」の価値
「Zero Data Loss Recovery Applianceは、Oracle Exadataユーザーだけでなく、多数のOracle Databaseを運用する全ての企業に勧めたいバックアップ製品」──世界第1号ユーザーとして同製品を導入し、緻密な実機検証を重ねてきたNTTデータ先端技術のスペシャリストらは、そう太鼓判を押す。その理由とは?[高可用性/災害対策][運用管理効率化][Engineered System] - データベースの運用を意識したプライベートクラウド構築のアプローチはCAPEXだけでなくOPEXも削減する
「社内に散在するデータベースを整理/統合し、運用管理が容易でスピーディに使える統合データベース基盤を作りたい」という企業に適したRDBMSが「Oracle Database 12c」だ。本企画では3回にわたり、同RDBMSを用いたプライベートクラウド構築のポイント、関連ツールを用いた実践ノウハウを紹介していく。[プライベートクラウド/データベース統合][運用管理効率化][パフォーマンス改善][Oracle Database 12c][Oracle Enterprise Manager] - Oracle DBアップグレードの実践的手法〜パッチ適用、データ移行、ダウンタイム短縮の手法
データベースをプライベートクラウドの構築に最適なOracle Database 12cに移行する際には、アップグレード作業をいかに円滑に行うかが重要なポイントとなる。また、高い安定性を確保するためのパッチ適用も忘れてはならない。今回は、Oracle Databaseの最新アップグレード手法とパッチ適用のベストプラクティスを紹介する。[プライベートクラウド/データベース統合][Oracle Database 12c][Oracle Multitenant] - Oracle DBアップグレード時のSQLテストの手法を知る
データベースアップグレードでは、旧環境のSQLが新環境で期待通りに動作するか、また性能が劣化しないかをテストする作業に多くの工数が掛かる。これをアップグレードプロジェクトの最大の関門と考える読者も多いだろう。実は、この作業を大幅に早く、簡単に行えるツールがある。[プライベートクラウド/データベース統合][Oracle Database 12c][Oracle Multitenant]
提供:日本オラクル株式会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2016年2月24日